我们实际上如何使用 AI Agents 发布复杂系统
Source: Dev.to
第1部分：为什么旧的操作手册不再适用
我认识的每位创始人都有同样的故事。你估算两周，结果六周才交付。那本来“简单”的支付集成，最终变成了三周的边缘案例追踪——这些问题没人提前告诉你。
经历过，做过，太多次了。
多年来，我们只能接受：复杂性 = 时间。想要构建稳固的东西？放慢脚步。需要快速迭代？偷工减料并祈祷生产环境不出问题。
但大约在 2025 年，一切都变了。这也是我写这篇文章的原因。
AI 代理已经不再是花哨的自动补全。如果你把它们设置得当（而且我指的是要真正严格约束它们），它们可以构建真正可运行的系统。不是代码片段，也不是模板代码，而是带有通过测试的真实业务逻辑。
关键不在于仅仅使用 AI，而是以一种在面对复杂需求时也不会崩溃的方式使用它。我把这称为 contract‑first 开发：在写任何代码之前，先锁定你要构建的内容。
为什么仅仅与 AI 聊天无法扩展
我见过团队在这上面浪费了数周时间。
他们打开 ChatGPT 或 Claude，输入 “写一个处理支付的函数”，复制粘贴返回的代码，然后继续。看起来还行。接着再要另一段代码。再来一段。
三周后，结账流程在任何真实负载下都崩溃。业务逻辑散落在十几份文件中。里面有一半没有测试。而那个 “简单函数”已经伸出触手，牵扯到所有地方。
看，不能只和 AI 聊天就指望得到生产质量的代码。事情不是这么运作的。
What does work: 先把所有内容全部定义清楚——系统能做什么，不能做什么，错误如何处理，数据是什么样子。先把这些锁定下来。然后让 AI 在这些边界内部填充实现。
人类设定边界，AI 在其中完成工作。
把它看作一个团队，而不是单个人
大多数人把“使用 AI 编码”想象成一次对话、一个代理、一个输出。这很快就会限制你的发挥。实际上可行的方式更像是拥有多个专家，只是它们以机器速度工作。
各部分如何协同
- Planner – 确定要构建的内容。
- Implementer – 编写代码。
- Reviewer – 捕捉问题。
- Tester – 证明其有效。
每个阶段将具体产物交给下一个阶段，对之前的内容不作任何假设。
什么时候真的需要它？
如果你只是在一个文件里编写一个函数，一个代理就足够了。一旦你在构建包含多个活动部件的系统，就需要不同的代理来处理不同的任务。否则，你会得到一个试图做太多事情却都做不好的代理。
快速示例
构建订单服务：
- Planner 说：“把它拆分为 API 规范、领域模型、数据库层、事务处理器、测试套件。”
- Agent A 生成 OpenAPI 规范。
- Reviewer 根据你的安全规则进行检查。
- Agent B 实现实际代码。
- Tester 根据规范编写测试。
- Final review 合并前的最终审查。
每一步都会产生具体的产出。没有任何代理需要猜测前一步的工作内容。
首先锁定合同
那么实际有效的做法是什么？
- 在任何实现之前生成严格的 API 规范——REST 使用 OpenAPI，gRPC 使用 Protobuf。这些将成为代理必须遵循的规则。
- 架构师的职责：审查领域模型，确保关系（例如
User↔Subscription）合理并能解决业务问题。 - 代理的职责：根据模型填充繁琐的细节——错误响应、边缘情况、数据类型——这些对人类来说枯燥，却容易出错。
从第一天起就设计系统以应对复杂性，而不是等到出现问题时再后期补丁。
要点
先锁定合约。然后让代理填充代码。
接下来
- 第 2 部分: 设置上下文、验证层以及处理失败。
- 第 3 部分: 何时介入、常见错误以及有效工具。
这是“使用 AI 代理构建复杂系统”系列的第 1 部分。