我的智能体在一个晚上提交了 3 个 PR。我 40% 的消息都是纠错。
我的 AI 驱动编程智能体在一个晚上提交了三个拉取请求（PR），但我发送的 30 条消息中有 40% 是纠错消息。
这次会话产出了一个 MCP 客户端、一个 Azure AI Agent 和一个 M365 Copilot Agent。自动化检查通过了所有三个 PR，我从未修改过一行代码。然而，对话记录却呈现了不同的情况：在总计 710 条消息中，我输入了 30 条，其中 12 条用于将智能体引导回正轨。“引导率”（steering rate）——即我发送的消息中纠错消息所占的比例——为 40%。
流水线是如何构建的
- Claude 起草了高层级的实现计划。
- DeepSeek V4-Flash 担任编排器（orchestrator），负责审查计划。
- Codex 生成实际代码。
- 编排器检查代码并开启拉取请求。
编排器的预期角色纯粹是连接性的——它应该解决组件之间的冲突，而不是亲自编写代码。在实践中，该智能体在约 40 分钟内通过三个 PR 产出了 3,500 行代码，但它也在两类重复出现的错误上栽了跟头。
两类错误
- 工作流违规 —— 编排器偶尔会接管编码步骤，忽略其“胶水”角色，转而亲自编写实现细节。
- 上下文检索失败 —— 尽管有明确指令，智能体仍选择了错误的 SDK 或版本。正确的信息就在提示词（prompt）上下文中，但模型未能在此刻将其提取出来。
这些并非推理能力的缺失，而是工作流约束方式上的工程缺陷。即使是能力更强的语言模型，仍然需要一条硬性的、不可忽视的规则，将编排器固定在其非编码职责上，并强制执行正确的 SDK 选择。
我做了哪些改变来驯服智能体
我不再假设系统会从步骤列表中推断其角色。我添加了一条直接声明：“你是一个编排器。你不负责实现。” 经过五条纠错消息后，这条指令才真正生效，之后智能体便开始遵守这一边界。
我还强化了上下文检索逻辑。当出现错误的工具时，我将其视为检索流水线中的 Bug，而非幻觉，并重写了向智能体提供 SDK 细节的提示词，使正确的版本变得不可忽视。
AI 增强开发的实践启示
- 统计你自己的消息量。 高数量的已接受 PR 可能会掩盖流程中的缺陷。你的纠错次数是衡量约束机制（harness）是否存在漏洞的前导指标。
- 明确说明角色。 智能体不会从清单中推断身份；它们需要关于“我是谁”以及“我可以做什么”的清晰、固定的指令。
- 将工具选择错误视为工程 Bug。 如果智能体忽略了指定的 SDK，问题在于上下文交付机制，而非模型的“知识”。
- 将错误转化为可复用的技能。 我让智能体根据自身的错误生成一套验证程序，将失败转化为未来的保障措施。