把任务交给 Agent 时，先写明停止条件和哪些步骤要问你
Anthropic 的《Building effective agents》建议先找最简单的方案，复杂度只在需要时增加；Agent 适合需要灵活决策的场景。文中还提到，Agent 可以在检查点或遇到阻塞时暂停，等人给反馈，并应设置停止条件（如最大迭代次数）来保持控制，且自主程度越高，成本和错误累积的风险越大，要在沙箱里充分测试。把这些原则用在日常委派上，就是交代任务时同时说清停在哪、问谁。文章发表于 2024 年 12 月，作者也提示其中部分工具方面的内容已过时。
对比示例委派与边界
场景：让编码 Agent 把页面里自己写的按钮，批量换成公司组件库里的组件
较差的描述
把项目里所有自己写的按钮都换成组件库的，改完告诉我。
更好的描述
请把 [目录] 下自己写的按钮换成组件库 [库名] 的 Button。 范围：只改这个目录，不动其他目录和依赖版本。 先做：列出要改的文件清单，等我确认后再动手。 检查点：每改完 [5] 个文件，运行 [测试命令]，失败就停下并告诉我原因。 停止条件：最多修改 [20] 个文件；遇到组件库里没有对应组件的情况，不要自己写，记下来问我。 交付：给出改动文件列表和测试结果。
- 「只改这个目录」划出范围，避免它顺手改别处
- 先列清单再动手，是让人在大动作之前有一次确认
- 每 N 个文件跑一次测试，是把检查点写进任务里
- 给出最大文件数和「遇到缺组件就问」，等于写明停止条件和不许自作主张的边界
今天就试试下次把任务交给 Agent 前，用一句话补上「改到什么程度就停、哪种情况先问我」。
目标表达上下文供给任务拆解审查验证反馈迭代委派与边界判断与取舍
示例由编辑根据下方来源中的原则撰写。
要点
- 文中原则：先从最简单的方案做起，简单方案不够时才增加复杂度
- Agent 可在检查点或遇到阻塞时暂停，等待人工反馈
- 用最大迭代次数之类的停止条件保持控制，并先在沙箱里测试
为什么值得关注
这是与模型无关的委派习惯，开源权重模型驱动的编码 Agent 同样适用；对「AI 一路改下去、改了一大堆没人看」的情况尤其有效。
来源
### [把任务交给 Agent 时，先写明停止条件和哪些步骤要问你]({{URL}})
Anthropic 的《Building effective agents》建议先找最简单的方案，复杂度只在需要时增加；Agent 适合需要灵活决策的场景。文中还提到，Agent 可以在检查点或遇到阻塞时暂停，等人给反馈，并应设置停止条件（如最大迭代次数）来保持控制，且自主程度越高，成本和错误累积的风险越大，要在沙箱里充分测试。把这些原则用在日常委派上，就是交代任务时同时说清停在哪、问谁。文章发表于 2024 年 12 月，作者也提示其中部分工具方面的内容已过时。
**场景**：让编码 Agent 把页面里自己写的按钮，批量换成公司组件库里的组件
✕ 较差：把项目里所有自己写的按钮都换成组件库的，改完告诉我。
✓ 更好：请把 [目录] 下自己写的按钮换成组件库 [库名] 的 Button。
范围：只改这个目录，不动其他目录和依赖版本。
先做：列出要改的文件清单，等我确认后再动手。
检查点：每改完 [5] 个文件，运行 [测试命令]，失败就停下并告诉我原因。
停止条件：最多修改 [20] 个文件；遇到组件库里没有对应组件的情况，不要自己写，记下来问我。
交付：给出改动文件列表和测试结果。
- 「只改这个目录」划出范围，避免它顺手改别处
- 先列清单再动手，是让人在大动作之前有一次确认
- 每 N 个文件跑一次测试，是把检查点写进任务里
- 给出最大文件数和「遇到缺组件就问」，等于写明停止条件和不许自作主张的边界
- 文中原则：先从最简单的方案做起，简单方案不够时才增加复杂度
- Agent 可在检查点或遇到阻塞时暂停，等待人工反馈
- 用最大迭代次数之类的停止条件保持控制，并先在沙箱里测试
**为什么值得关注**：这是与模型无关的委派习惯，开源权重模型驱动的编码 Agent 同样适用；对「AI 一路改下去、改了一大堆没人看」的情况尤其有效。
来源：[Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)