我如何在 Rocket.new 构建 AI Agent Systems（内部视角）

Source: Dev.to

我已经从事开发者工具的构建五年。

在 DhiWise 的前三年里，我们只做了一件事的自动化：把 Figma 设计转换为可投产的代码。选择一个框架（Flutter、Kotlin、React），上传你的设计，即可得到干净的代码。这就是整个产品。

随后，一切都改变了。

改变我构建方式的转折点

2023 年我们推出了 WiseGPT——一个上下文感知的 AI 编码助手，能够接入 VS Code 并理解你的本地代码库。无需提示工程，只需描述你想要的内容，它就会生成符合实际项目结构的代码。

这也是我第一次在生产环境中真正接触 AI 代理系统。不是演示，也不是原型，而是为真实开发者服务、可规模化的真实代理。

到 2025 年，公司更名为 Rocket.new，产品也变得更大：一个 AI‑first 的应用构建器，能够根据纯英文提示生成完整、全栈、可投产的应用。我是负责背后代理系统的工程师之一。

AI 代理系统在生产环境中的真实样子

很多教程只展示一次 LLM 调用：发送提示，得到响应。这不是代理系统，而是自动补全。

在 Rocket.new，像“帮我构建一个带等待名单表单的 SaaS 落地页”这样的单一用户提示会触发一条由多个专用代理协同工作的流水线：

• Research agent – 分析请求并确定需要哪些组件。
• Design agent – 做 UI/UX 决策。
• Code generation agent – 编写前端、后端和数据库逻辑。
• Validation agent – 在输出交付给用户之前检查错误。

这些代理并非严格顺序执行，而是在可能的情况下并行运行，通过共享的上下文层进行决策协同，并以异步方式将状态交接给彼此。

最难的问题：上下文工程

最大的技术挑战不是 LLM 调用本身，而是 上下文工程——决定每个代理完成任务所需的信息，并确保这些信息在正确的时间以正确的格式可用。

• 上下文太多会让模型混乱。
• 上下文太少会导致错误假设。

关键在于构建能够在每一步向每个代理路由恰当上下文的流水线。这也是我在 Rocket.new 大部分时间所做的工作。

我在构建过程中的收获

1. 混合架构胜过纯 LLM 系统
   将基于工具的决策（确定性规则）与基于 LLM 的推理相结合，能够得到既可靠又灵活的系统。纯 LLM 系统容易漂移；混合系统则可控。

2. 错误级联是最大的敌人
   当一个代理出现小错误时，后续代理会继承并在此基础上继续构建。等到第三个代理时，输出可能已经完全错误。解决方案是设置代理之间的验证关卡，而不是仅在最后进行验证。

3. 延迟比准确性更重要（起步阶段）
   更快、稍逊完美的答案胜过慢速、完美的答案。用户等待时会失去信任。先为速度构建，然后逐步提升准确性。

平台目前已服务 40 万+ 开发者，覆盖 180 多个国家，并生成了 50 万+ 可投产的应用。

如果你也在构建 AI 代理系统并想交流经验，我随时欢迎。

Find my other technical writing at .