怎样构建有效的 Agent

继续看相关机制：F24 · 任务状态不是聊天里的一句总结F33 · 超时告诉你没收到，不告诉你没发生

Agent不是“加了很多角色的Prompt”

本篇对应Building Effective Agents。判断是否需要Agent，关键是下一步能否在看到环境反馈前确定。步骤稳定时，工作流更直接；需要依据新证据选择行动时，动态Agent更有价值。两者可以组合。[S003]

原创案例：给定明确文件清单和过滤规则，普通程序即可计算结果；调查为什么真实构建没有排除文件，则需要搜索、读取和测试。不要为了使用Agent而重新实现已有确定性逻辑。

五种组织方式怎样选择

链式处理适合阶段输出明确的任务；路由适合不同类别需要不同能力；并行适合相互独立的工作；协调者—工作者适合动态拆分；评价反馈适合结果可以被有效判断并改进的任务。[S003][S125]

每种都有代价。链会传播前一步错误；路由可能分错；并行需要整合；协调会重复派工；评价器若不可靠，会把正确答案改坏。因此模式选择需要反例，而不是只看成功演示。

把概率判断与确定性执行分开

模型可以建议下一步读哪个文件；程序应检查路径是否授权。模型可以提出补丁；工具应报告是否实际应用。模型可以判断任务看似完成；测试与业务状态提供最终证据。[S047][S058]

一个最小循环不需要十种框架部件：组装输入、获得动作、验证、执行、记录观察、判断结束。随着真实问题出现，再增加检查点、并发和恢复。

怎样知道该停止

成功停止需要满足验收；非成功停止可能因为证据不足、权限受限、环境故障或预算用尽。允许明确报告未完成，比强迫所有运行都产生“成功总结”更可靠。

原创例子：测试环境缺依赖，Agent可以完成补丁和静态检查，但应说尚未完成运行验证。它不应为了让任务显得结束而编造通过日志。

一个最小对照实验

为同一组假想任务比较固定工作流、单Agent和多Agent。分别记录功能正确性、重要遗漏、调用轮次、时间与人工接管。不要只比较输出长度。

当复杂方案没有减少真实失败，就应考虑删除。反过来，如果独立调查能发现单Agent反复遗漏的边界，则有保留理由。这是工程判断，不是“简单永远最好”的教条。[S128][S143]

完成本篇后，应该能解释每个新增环节解决的具体错误，以及去掉它会怎样。