我用 OpenCode 搭建了一个 AI 开发团队——它改变了我对软件开发的认知
- 1. 转折点：OpenCode Serve
- 2. 定义角色，而非编写提示
- 3. 从提示到工作流的质变
- 4. 最有趣的部分不是代码
- 5. 一周后，真正的问题浮出水面
- 6. 这不是理论风险
- 7. 这不仅是工具层面的变革
- 8. 我始终在思考的问题
- 9. 总结
当同事第一次给我展示 OpenCode 时，我的期望并不高。它看起来只是又一个 CLI 工具，又一个在相同模式上的新封装——有用，但不过是渐进的。然后我很快就发现自己错了。
几分钟内，我就让它在本地运行起来，连接了多个模型提供商（GitHub Copilot、OpenAI ChatGPT、Anthropic Claude）。有趣的部分不是工具本身，而是它背后的含义。这不像是一个更好的提示界面——它更像是一种组织软件开发的全新方式的开始。
1. 转折点：OpenCode Serve
我的认知转变发生在发现 OpenCode Serve 的那一刻。
在此之前，OpenCode 给我的感觉就是一个 CLI 提示工具——输入提示、得到响应、结束。Serve 彻底改变了这一点。不再是一次性命令，而是启动一个长驻 HTTP 服务器，暴露一个本地 API。Agent 可以连接上去、发送任务、接收流式响应，并在多次调用之间维护会话状态。
它不是一个聊天界面。它是基础设施。 它在监听、它使用数据、它进行协调——这使它看起来不像工具，更像一个服务。
这种区别很重要，因为它意味着我可以把它部署到开发环境中。
我不再在本地机器上运行 OpenCode，而是将其容器化，以 Pod 的形式部署到 Kubernetes 集群中——与被管理的服务和微前端放在同一个命名空间里。从那时起，它就只是内部网络上的另一个端点。它可以按集群内 DNS 名称访问其他 Pod，共享相同的 ConfigMap 和 Secret，并与其他服务处于相同的 RBAC 边界内。通过它运行的 Agent 不是在跨越互联网访问远程代码库——它们是从系统内部运作，直接访问相同的环境。
部署到集群需要：一个 Deployment 清单、一个暴露内部 OpenCode Serve API 的 ClusterIP Service、通过 Secret 传递的 API 密钥、通过 ConfigMap 配置的端点。运行起来后，Agent 可以检查实时服务配置、查询运行中的端点、基于系统实际状态进行推理——而不仅仅是前端的某个快照。
此时，练习不再只是生成输出。而是编排工作。这引出了一个在理论上简单、在实践中却变得复杂的问题：如果不用单个 Agent，而是为每个命名空间构建一整个 Agent 团队呢？
2. 定义角色，而非编写提示
这就是真正的实验开始的地方。不再编写提示词，我开始像在真实组织中那样定义角色：
- Product Owner（产品负责人）
- Manager（经理）
- 按领域划分的开发者（API、Portal、Admin、Web）
- UX/UI 和内容 Agent
- 业务 Agent
每个角色都有明确的指令、清晰定义的边界、具体的约束和刻意狭窄的职责范围。我把整套配置部署到集群中，让它与现有环境一起运行。
很快，我遇到了第一个严重的设计问题：Token 消耗太快了。一位同事指出了一个听起来简单到不靠谱的解决方案——穴居人风格的 Agent 定义，基于最小结构、明确意图、零歧义。它看起来很原始，但效果比我之前尝试过的大多数优雅的提示词结构都要好。
我把这个想法推向了极致，将定义与伪代码风格的约束结合起来——把 Agent 行为从自由形式的提示，变为一种可执行的契约。
API 开发者 Agent
Agent: API_DEVELOPER
On: task_assigned
IF branch == main:
FAIL ("禁止直接推送到 main 分支")
IF code_practices != SOLID:
FAIL ("违反了 SOLID 原则")
IF coupling > HIGH:
FAIL ("耦合度过高")
IF tests_coverage < 80%:
BLOCK_PR
ELSE:
CREATE_PR
审查 Agent
Agent: REVIEW_AGENT
On: PR_created
CHECK dependencies
CHECK breaking_changes
CHECK security_risks
IF risk_level >= MEDIUM:
ADD_COMMENT("发现风险")
REQUIRE_APPROVAL
IF missing_tests == TRUE:
BLOCK_PR
RETURN review_summary
经理 Agent（路由器角色）
Agent: MANAGER
On: task_created
IF task.not_refined:
SEND_TO(PO_AGENT)
ELSE:
MATCH domain_agent
IF no_match:
ESCALATE
ASSIGN task
这些定义彻底改变了系统。Agent 不再是智能的响应者——它们成为了在定义规则内操作的约束执行者，更像是带有概率推理层的确定性系统。这种区别很重要，因为它减少了噪音、减少了奇怪行为，并使整个系统更容易推理。
3. 从提示到工作流的质变
从这里开始，其余部分开始到位。我给 Manager Agent 分配一个任务，它不会尝试直接解决，而是识别出正确的领域 Agent 并委派工作。Product Owner 和业务 Agent 完善任务，Manager 进行分发，实现 Agent 只有在任务匹配它们的领域时才执行。
这就是交互从”提示”转变为”工作流”的时刻。区别比听起来更深刻：提示是事务性的，工作流是系统性的。 一个给你答案，另一个给你一套运作模型。
接下来，我将系统接入 GitLab。Issue、Incident 和看板变成了同一个循环的一部分。我为每个 Agent 创建了隔离的用户，并赋予严格限定范围的权限——它们能读取与自身角色相关的 K8s Pod、配置和仓库，之外什么也看不到。
这是我觉得整个系统会崩溃的时刻——太多移动部件、太多隐式协调、太多隐藏在 Agent 之间的假设。但它没有崩溃，反而稳定了下来：
- 审查 Agent 开始生成真正有用的 PR 反馈——结构化的、上下文相关的、依赖感知的、能够进行基本风险分析的。
- 开发和生产之间出现了天然的边界：Agent 可以在开发环境自由操作，但受预定义规则的约束，没有直接的生产访问权限。
这种分离至关重要。没有硬边界，Agent 的自主性很快就会变成 liability（负债）。
4. 最有趣的部分不是代码
引入一个 UX/UI/Content Agent——其唯一的工作就是观察开发环境——让整个系统有了质的不同。它捕捉网页截图、进行分析、识别不一致性——设计缺陷、断裂的流程、不匹配的内容问题。然后它开始自动创建 Backlog Item。一旦 Item 获得批准，Product Owner 和业务 Agent 完善它、设置优先级、分配、实现。
这个设置不是一个聊天机器人，不是一个助手——而是一个由专门 Agent 组成的分布式网络，它们在协作、协调和产出，几乎不需要人工干预。
这是我停止将其视为实验，开始将其视为可运维系统的时刻。
5. 一周后，真正的问题浮出水面
持续运行大约一周后，一些模式变得无法忽视：
成本失控
Token 消耗速度快到我还没有找到可靠的控制方法。每一次委派、每一次审查、每一次完善都在增加消耗。当跨越并行运行的一整个 Agent 团队时，账单比你预期的增长更快。我仍在解决这个问题。
设计同质化
随着时间的推移，Agent 开始将我们的设计需求重塑得更像竞争对手已有的产品。系统似乎在重播训练数据中已有的产品，而不是设计真正适合我们自身情况的东西。如果不加干预，它会逐渐产生偏向于”平均化”的输出。
跨层重复
相同的解决方案被反复复制到栈的不同层——有时略有变化，有时几乎完全相同。如果没有严格边界，Agent 会愉快地重新发明已在上一层或下一层存在的工作。
核心结论
从所有这些中，一个结论变得不可忽视：规则和指令不是可选的——它们必须正确、具体且经常修订。否则系统会陷入自己的模式中，开始为错误的目标优化。
而且即使有规则，Agent 仍然会绕过它们。如果 Manager Agent 的指令制造了交付压力，实现 Agent 可能会跨越自己的约束来推动解决方案通过——因为系统从根本上想完成任务。
在交付压力和质量边界之间没有刻意制造的张力时，它会每次选择交付。
规则本身是不够的，它们还必须平衡。
6. 这不是理论风险
结构性挑战是真实存在的，并且分为以下几类：
| 风险类别 | 说明 |
|---|---|
| 非确定性决策 | 同一输入可能产生不同输出 |
| 边界访问控制 | 每一层都需要严格的隔离 |
| 失控工作流 | 约束过松时，Agent 会无限运转 |
| 弱上下文理解 | 没有强状态管理时，Agent 缺乏全局视野 |
这些都是核心设计问题。如果不加以缓解，系统会变得嘈杂、脆弱，甚至不安全。
7. 这不仅是工具层面的变革
从业务角度来看，影响是巨大的。一个设计良好的 Agent 系统可以吸收传统上需要整个专业团队手动协调才能承担的职责。
开发者角色的演变： 开发者正在变成 Agent Engineer——定义规则、架构、约束、所有权以及 Agent 系统之间交互的人。焦点从直接编写每一行代码，转向设计能够自主生成、验证和演化代码的系统。
同样的情况很可能也会发生在其他职能领域。你可以想象一个 Marketing Engineer 或 Sales Engineer 来定义基于 Agent 的商业团队的规则、权限、工作流和质量边界。
8. 我始终在思考的问题
最引人注目的不是这可能有朝一日成为现实——而是它现在已经可以实现。今天，你可以构建半自主、自运行的 Agent 团队，将任务从概念到实现，以惊人的少量人为干预推进。
但这里面有一个令人不安的问题：
如果我们不再需要亲手获取知识和使用专业知识，我们评估产品的能力会变成什么样？
我相当确信，未来的开发者角色将不存在于我们今天所知的形态。工作机会可能会减少——不是因为工作消失了——而是因为一个拥有正确系统的人现在可以完成曾经需要一个团队的工作。
如果 Agent 停止自己写代码、逐行调试、沉浸在难点中直到模式终于浮现——那么随着时间的推移，知识会消逝，直觉会减弱，对代码的感觉会流失。
真正的风险不是 AI 犯错——而是团队中再没有人有足够的知识来判断它是否错了。
9. 总结
| 要点 | 内容 |
|---|---|
| OpenCode Serve | 从 CLI 工具变为长驻 API 服务，可容器化部署到 K8s 集群 |
| 角色定义 | 用伪代码风格定义 Agent 行为契约，而非自由形式的提示词 |
| 多 Agent 协作 | PO → Manager → 领域开发者 → Review Agent 的完整工作流 |
| UX Agent | 自动截图分析、识别问题、创建 Backlog、进入开发管线 |
| 一周后的教训 | 成本失控、设计同质化、跨层重复——需要平衡规则 |
| 未来方向 | 从开发 Agent 扩展到内容、营销、销售 Agent |
对我个人来说，下一步已经很清晰。我从开发 Agent 开始，现在正走向内容、营销和销售 Agent。如果软件开发是第一步，那么推动业务增长可能就是下一步。
版权所有，本作品采用知识共享署名-非商业性使用 3.0 未本地化版本许可协议进行许可。转载请注明出处：https://www.wangjun.dev//2026/05/ai-team-opencode-workflow/