Open Code实战指南：用多代理系统组建AI编码团队

从质疑到全面拥抱AI编码

11个月前，Anthropic CEO达里奥预言「三到六个月内AI会写掉90%开发者的代码」。当时很多人觉得不靠谱，包括本文作者——一位资深工程师。他当时完全不让AI写自己的代码，最多做些辅助工作。

但今天，他不仅让一组AI编码代理去做复杂任务，还把它们连同技能系统、子代理、各种配置选项都整合进了Open Code。这个拥有超过十万星的开源项目，已经成为AI编码代理领域的标杆。

什么是AI编码代理？ AI编码代理（AI Coding Agent）是基于大型语言模型（LLM）构建的自主软件开发系统，能够理解自然语言需求、生成代码、执行测试并迭代修复。与早期的代码补全工具（如GitHub Copilot的初始版本）不同，代理系统具备「工具调用」能力——它可以主动读写文件、执行终端命令、调用外部API，形成感知-决策-执行的完整闭环。这一能力飞跃的背后，是GPT-4、Claude 3等模型在函数调用（Function Calling）和上下文窗口扩展上的突破。正是这种从「被动补全」到「主动执行」的范式转变，让达里奥的预言从天方夜谭变得越来越像现实。

Open Code是什么：从业余项目到开源标杆

Open Code最初叫Terminal AI Agent，由一位开发者业余时间创建。后来知名开发者Dex和Adam加入，甚至拿下了opencode域名。终端开源工具公司Charm对项目感兴趣，想把三人都招进公司。

关键转折在于：Dex和Adam拒绝了Charm的offer。他们希望Open Code保持开源，不接受VC资金带来的商业化压力。最终他们从零重写了Open Code，而Charm那边的版本后来改名为Crush。

这一决策折射出当前AI工具领域的深层矛盾：VC资本追求商业化变现，而开发者社区更看重工具的中立性与可持续性。类似的张力在Prettier、ESLint等前端工具的历史中也曾出现——一旦核心工具被商业公司完全控制，社区就面临被「锁定」的风险。Open Code最终选择加入Anomaly这一「创业工作室」模式，而非传统VC路径，是在资金支持与社区控制权之间寻求平衡的折中方案。

如今Open Code归属于Anomaly旗下（包含SSD、OpenTof等项目），获得了Y Combinator和PayPal联合创始人马克斯·列夫琴的支持。虽然也有VC资金，但开发者保留了更多控制权。

核心架构：主代理与子代理如何协作

双层代理系统详解

Open Code的多代理系统分为两层：主代理和子代理。

主代理包括：

• Plan（规划代理）：只读只规划，负责全线方案设计，哪怕你让它执行也不行
• Builder（构建代理）：负责实际的代码编写和执行

子代理是专门处理特定任务的模块，随时可调用，在后台运行。Open Code自带两个通用子代理：一个可以执行操作，一个（Explore）主要负责代码阅读和探索。

这种分层设计在软件工程中有其理论依据。将「规划」与「执行」分离，类似于经典的「命令查询职责分离（CQRS）」模式——只读的Plan代理不会因为误操作而修改代码库，降低了不可逆错误的风险。而子代理的专职化，则对应着「单一职责原则」：任务边界越清晰，模型产生幻觉（Hallucination）的概率越低，因为它不需要在多个认知域之间频繁切换。

自定义子代理实战配置

运行opencode agent create会弹出交互式向导，让你描述代理的职责，设置权限范围，然后自动生成完整定义文件。生成的文件包含指令、方案、事例、原则、背景规范等配置项。

但要清醒认识到：这本质就是提示词注入，质量完全取决于你怎么写提示词。除了权限限制，没什么能绝对阻止它跑偏——绕过规则的情况确实会发生。

那为什么还要用子代理？两个核心原因：

1. 分工减少幻觉：任务越具体，模型越少犯错
2. 更方便追踪过程：每个子代理的工作都可以独立查看和调试

组建AI编码团队：角色分配与实战效果

作者用Open Code组建了一支完整的自动化工程小队：

• 团队负责人：统筹和分派任务，协调各代理协作
• 产品经理：只读探索，理解用户故事和需求
• 后端开发：负责核心代码实现
• 测试（QA）：同步推进自动化测试
• 代码审查员：独立审查代码质量和规范

启动后，团队负责人会收集需求并持续分派任务。你可以实时看到子代理之间的互动——负责人让产品经理澄清需求，代码审查在同步工作，测试也在推进。

实际使用几周后，大约95%的情况都能正常运作。秘诀是持续在各自的配置文件里调整子代理的提示词，确保它们符合你的工作方式。

多代理架构的代价

多代理系统并非没有缺点，其中最核心的是Token经济学问题。每个代理都需要携带系统提示、历史对话和工具定义进入上下文窗口，Token消耗呈乘数级增长。以Claude 3.5 Sonnet为例，每百万输入Token约需3美元，复杂任务中单次多代理协作可能消耗数十万Token。这也是为什么后文Skills的「按需加载」设计在工程上具有实际价值——它本质上是一种上下文窗口的资源调度策略，避免把所有能力都塞进每一次对话。

具体代价包括：

• Token消耗显著增加，指令更长意味着成本更高
• 翻看子代理输出、搞清楚改动落在哪里并不总是高效
• 大多数简单任务，单代理可能是更好的选择

Skills系统：按需加载的能力扩展机制

Skills本质是按需加载的提示词注入，区别于始终占用上下文窗口的系统提示。你不碰AWS就不加载AWS技能，需要时才调用，有效节省Token开销。

一个技能通常包含一个Markdown文件（定义名称和指令），还会引用其他文件如GitHub Actions配置或Kubernetes部署模板。好处是社区已经帮你把规范和流程整理好了，比如Jira技能会写好认证方式、API接口、查看看板的脚本。

不过要注意：技能市场上质量参差不齐，号称有近五十万个技能，这种指数式增长确实像泡沫。选技能最好跟着可信来源，仔细审查内容再使用。这与npm生态的早期扩张颇为相似——包的数量爆炸式增长，但「left-pad事件」和供应链攻击也随之而来。在AI技能场景中，一个恶意或低质量的技能文件可能直接影响代理的行为决策，风险不容小觑。

安全方案：用JWT即时令牌替代静态密钥

安全是AI编码代理最容易被忽视的问题：每个代理迟早都需要凭据——API Key、令牌、数据库密码。大多数人直接塞进环境变量就完事了，但这是迟早会出事的安全隐患。

想想这些场景：电脑被偷、密钥被提交到公开仓库、有人通过社工混进CI流水线。静态密钥会一直存在，它带来的权限也会一直存在。

解决方案是用JWT即时令牌。JWT（JSON Web Token）是一种开放标准（RFC 7519），用于在各方之间安全传递声明信息。其核心优势在于「无状态验证」和「短期有效性」：令牌本身携带过期时间（exp字段），服务端无需查询数据库即可验证合法性，验证速度极快且可水平扩展。在AI代理场景中，结合OAuth 2.0的「客户端凭证流」或专为机器身份设计的SPIFFE/SPIRE框架，可以实现代理身份的动态颁发与自动轮换——代理先发起访问请求，验证身份后发一个短期令牌，几分钟就过期，将静态密钥泄露的攻击面压缩至分钟级时间窗口。

这从根本上改变了多代理系统的安全问题——你做再多子代理和技能都更放心，否则它们揣着永久密钥到处跑，只是在制造更多攻击目标。

多平台运行：终端、Web、iPad全覆盖

Open Code不再只是终端工具，它支持多种运行方式：

• 终端TUI：推荐使用Wezterm或Ghostty，支持图片拖拽解析
• Web界面：本地端口启动，配合Ngrok对外暴露，iPad也能用
• Neovim插件：在编辑器中直接调用代理
• 原生应用（测试版）：内置终端，体验接近IDE
• GitHub集成：在PR评