AutoDev 10：从会做事的 Agent 到可运行的工程

故事开始时，我们只有一位聪明同事和一张任务单。现在房间里多了控制器、状态保管员、 门卫、审计员、SCM 翻译、CI 观察员和镜像搬运工。有人可能会问：为了让 Agent 写代码， 值得请这么多人吗？

如果它只写一段供人复制的建议，不值得。如果它要自动修改仓库并触碰远端系统，这些角色 不是排场，而是责任。

复杂 Agent 工程的十条护栏

十条可以迁移的方法

  1. 先画责任边界。 平台提供运行设施，业务控制器定义领域流程，不重复造半套 Runtime。
  2. 分开推理与副作用。 Agent 提案，确定性程序校验并执行授权动作。
  3. 用契约连接两边。 Schema 约束结构，最小上下文减少歧义和敏感信息暴露。
  4. 用阶段组织长流程。 每阶段定义输入、输出、允许副作用和终止语义。
  5. 让证据绑定 revision。 代码一变，旧验证、旧审批和旧 CI 都不能继续顶班。
  6. 所有副作用都考虑重放。 能幂等就幂等，不能幂等就写清观察与恢复规则。
  7. 把外部内容视为不可信。 Webhook、Issue、仓库文件、模型输出和 CI 日志一视同仁。
  8. 隔离 Provider 细节。 工作流面对领域对象，GitHub/GitLab 差异留在适配层。
  9. 环境要可追溯。 Image 固定工具，Workspace 放代码，Volume 放状态，Secret 单独注入。
  10. 测试失败、取消与重放。 成功路径只能证明演示顺利，异常路径才检验工程结构。

复杂的真正含义

AutoDev 的代码比简单示例多，不是因为 Agent 需要更多仪式，而是因为它拥有更多可能的 后果。复杂工程的目标也不是消灭不确定性——模型、网络、CI 和人都不会配合得如此彻底—— 而是把不确定性关在明确边界内，让每次决定都有证据，每个副作用都能追踪，每次失败都有 去处。

回到 Agent Compose

早期示例展示了怎样让 Agent 对话、动态组队、通过事件交接，以及被不同方式触发。 AutoDev 把这些基础能力带进一条真实的后台工作流：由 agent-compose 管理入口、调度、 Sandbox、Workspace、Runtime、Secret 与生命周期；由 AutoDev 管理自动开发的策略、状态、 Git、SCM、CI 和证据。

这也是整组文章最想藏在笑话后面的严肃结论：

好的 Agent 工程，不是让模型看起来无所不能，而是让整个系统清楚地知道，模型能做什么、 不能做什么，以及它做完以后谁来验收。

至此，阿智可以继续聪明，老闸可以继续不解风情，而值班同学终于可以在凌晨两点看到一条 比“它不行了”更有用的记录。