1
先写固定 workflow，再开放一个不确定环节给 agent 循环。
如果整条链路都开放给模型，你很难知道它到底在哪一步出错。先把确定路径写死，再把需要判断、搜索、debug、迭代的一段交给 agent。
例子：研究任务可以固定信息源和报告格式，只让 agent 判断哪些材料重要、哪里需要补查。
AI Agent Workflow Playbook
不要把 Agent 当聊天框。
把它当成一个需要 流程、权限、反馈、验收和复盘 的工作系统。真正厉害的 AI 使用方式，不是写更花的 prompt，而是设计更可靠的人机协作机制。
System View
从固定流程到可控 Agent
成熟的 agent 系统不是把整条链路都交给模型，而是先固定确定步骤，再只把最不确定、最需要判断的一段开放给模型循环。
主线：先稳定，再开放；先边界，再自动化。
Inline SVG / no external assets
Seven Practices
7 条落地实践
这些不是 prompt 技巧，而是把 AI agent 放进真实工作流时需要的工程约束。
2
工具说明要像新人 onboarding 文档一样清楚。
工具名和参数不是给机器看的暗号，而是 agent 完成工作的操作手册。说明什么时候用、字段含义、失败返回、调用后检查什么、什么时候停下来。
差：
search(query)。好：说明搜索范围、时间窗口、重试条件和停止条件。
3
每个 agent loop 都必须有反馈信号。
Agent 能变好，是因为它能看到行动后的结果。测试、日志、编译错误、搜索结果、人工审核和业务指标，都是让循环不跑偏的信号。
Coding agent 表现好，是因为类型错误、测试失败、lint 和 CI 都会立刻告诉它哪里错了。
4
权限边界写在 prompt 之前。
先定义 agent 能读什么、能写什么、什么必须审批、什么永远不能碰、失败后谁兜底。否则 prompt 再漂亮，也只是一个有权限的黑盒。
销售 agent 可以草拟邮件和更新跟进状态，但报价、承诺交付时间、对外发送必须审批。
5
Coding 场景优先强化测试、类型、lint、CI 和错误输出。
不要只优化 prompt。让代码库更机器可读，agent 才能稳定修正自己。类型、测试和错误信息越清楚，模型越容易走到正确路径。
一改错，typecheck 报；一破坏行为，测试挂；一不符合风格，lint 提醒。
6
多 agent 不等于更强。
并行前先解决状态共享、任务拆分、交接格式、冲突处理、最终验收和失败回滚。否则只是把混乱并行化。
适合拆分：一个 agent 调研竞品，一个整理用户访谈，一个分析价格页，主 agent 负责合并和验收。
7
真正的壁垒不是模型，而是 workflow、eval、日志、权限和团队习惯。
模型会越来越强，也会轮流领先。组织真正沉淀下来的是任务模板、评估集、失败案例、工具文档、审批规则、复盘日志和团队 review 方式。
好 prompt 变成 skill，失败案例变成 eval，高风险操作变成审批规则，常见任务变成 workflow 模板。
Readiness Checklist
Agent 落地检查清单
如果这些问题答不上来，说明还不适合把任务交给长期运行的 agent。
任务边界
这件事是否有明确输入、输出、完成标准和失败标准？
固定步骤
哪些步骤可以写死？哪些步骤真的需要模型判断和循环？
工具文档
Agent 是否知道每个工具什么时候用、怎么用、用完检查什么？
权限控制
能读、能写、需审批、禁止触碰的范围是否写清楚并能被系统执行？
反馈信号
每一轮行动后，agent 能否获得测试、日志、搜索结果或人工反馈？
Eval 验收
是否有固定样例或指标，判断结果准确性、稳定性和越权风险？
日志复盘
出了问题后，能否知道 agent 看了什么、做了什么、为什么这么做？
停止条件
连续失败、信息不足、风险过高或权限不够时，agent 是否会停下来等人？
团队沉淀
好流程、坏案例和审核经验是否会变成可复用资产，而不是散落在聊天记录里？
Cloudflare Pages 部署
这是一个纯静态页面。部署时选择目录 ai-agent-workflow-pages，Build command 留空，Output directory 使用根目录或 .。