为什么 Agent 需要工程约束，而不仅是更强的提示词

问题不在「够不够聪明」

当我们把任务交给 Agent 时，最常见的失败模式并不是模型「不够聪明」，而是：

• 目标含糊，成功标准不可验证
• 工具权限过大，副作用不可控
• 中间状态不可见，出错后难回滚
• 同一次任务无法稳定复现

把这些问题全部塞回提示词里，短期看起来有效，长期会把系统推入不可维护的状态。

提示词解决什么，不解决什么

提示词擅长：

1. 表达意图与风格
2. 给出步骤骨架
3. 约定输出格式

提示词不擅长单独承担：

1. 权限边界（能调用什么、不能改什么）
2. 资源预算（Token、时间、重试次数）
3. 可观测性（日志、轨迹、失败分类）
4. 契约校验（输入输出 schema、测试门禁）

提示词是策略层的一部分，不是完整的控制系统。

工程约束的最小集合

我在实践中倾向至少落地四类约束：

1. 目标约束

用可验证的完成条件替代「尽量做好」：

• 要产出哪些文件
• 哪些检查必须通过
• 哪些行为明确禁止

2. 工具约束

给工具分层：只读探测、受限写入、高风险操作。高风险操作需要额外确认或人工闸门。

3. 过程约束

限制循环次数、上下文窗口膨胀与重复尝试。失败应进入分类，而不是无限重试。

4. 证据约束

每次关键决策留下可追溯证据：命令、结果摘要、变更范围。没有证据的「完成」不可信。

一个可操作的检查清单

在启动 Agent 任务前，可以快速自问：

问题	若答案是否
成功标准是否可自动验证？	先补验收条件
工具是否最小权限？	收窄写权限
失败是否有明确退出条件？	加预算与熔断
结果是否可复现？	固化输入与步骤

小结

更强的模型会提高上限，但不会自动带来可靠性。Agent 要从演示走向生产，关键转折点是：把约束写进系统，而不是只写进提示词。

下一篇文章会拆开 Skills、Tools、Hooks 与 Harness 各自解决的问题，以及它们如何组成可控工作流。