Harness Worker Agents 和 Code Agent 有什么不同：pipeline 工位、IDE 助手与 MCP 边界

Harness 对比 进阶 进阶 预计 16 分钟 发布于 2026/6/1 核验于 2026/6/4

Harness Worker Agents 和 Code Agent 都在 Harness AI 语境里出现，但它们不该被混成一个概念。用户搜索 “Harness Worker Agents vs Code Agent” 时，真正想解决的是选型问题：我应该把 AI 放进 pipeline，还是放进 IDE 和代码工作流？

更直白地说：Worker Agents 更像 pipeline 里的 AI 工位，Code Agent / VS Code Extension 更像面向开发者桌面的 AI 助手和调试入口。两者可以协作，但入口、产物、权限和失败处理方式完全不同。

核心区别

两者都需要治理，但治理重点不一样。

什么时候选 Worker Agents

如果你的问题发生在软件交付流程里，优先看 Worker Agents。官方文档把它描述为在 Harness pipelines 内运行的 AI automation units，核心由 instructions、model connector、可选 MCP servers 和 configurable inputs 组成。

• pipeline 失败后需要分析原因。
• 想把需求拆成 spec 和执行计划。
• 想在 CI/CD 中增加 AI 分析节点。
• 想让多个 Agent 按顺序处理流程任务。
• 想把 AI 的输出作为 pipeline 产物、output variables 或审批条件。
• 想让触发器、pipeline expression、Slack 通知和后续 step 共同消费 Agent 输出。

这里的重点不是“写代码”，而是让软件交付流程更清楚、更可复盘。

Worker Agents 的治理重点

Worker Agents 的风险来自它们离交付流程更近。官方资料强调，Agent step 在 pipeline YAML 中引用 agentName: <name>@<version>，而 instructions、inputs、outputs、environment variables、container image 等定义保存在 Worker Agent Catalog。这个分层很重要：pipeline 引用的是版本化 Agent，不应该把 prompt、secret 和治理逻辑散落到每条 pipeline 里。

接入前要确认：

什么时候更像 Code Agent

如果你的问题更贴近代码本身，才更像 Code Agent：

• 修改某个函数或模块。
• 生成测试。
• 解释代码结构。
• 根据 issue 生成补丁。
• 在仓库内完成小范围开发任务。
• 在 VS Code 里查看 pipeline 日志、审批、AI-assisted debugging 或代码上下文。

Code Agent 的成功标准最终要落到测试、代码审查和可维护性上。

Code Agent / VS Code Extension 的治理重点

Code Agent 或 IDE 扩展的风险来自 workspace 和开发者权限。它可能能看到代码库上下文、生成补丁、解释日志，甚至辅助审批或调试，但它不应该绕过代码 review、测试和仓库权限。

接入前要确认：

• 当前 workspace 是否包含敏感代码或客户数据。
• AI 建议是否必须由开发者显式采纳。
• 生成测试和补丁后，是否有本地测试、CI 和 review。
• VS Code 扩展使用的 PAT 或登录身份是否具备过大平台权限。
• IDE 内 pipeline approval 是否仍保留人工确认。

MCP 在中间的角色

MCP 不是 Worker Agents 和 Code Agent 之外的第三个“万能 Agent”。它更像连接层：

所以选型时不要问“Worker Agents、Code Agent、MCP 选哪个”。更准确的问题是：AI 的主要工作地点在哪里，MCP 是否只是它访问外部资源的通道？

低风险试点建议

Worker Agents 第一阶段：

• 只读分析 pipeline 失败。
• 根据需求生成 spec 草稿。
• 生成执行计划，不直接部署。
• 输出风险等级和建议，让下游审批 step 判断是否继续。
• 只接入一个项目或少量 pipeline，不把 account 级资源全部暴露。

Code Agent 第一阶段：

• 生成测试建议。
• 修复非关键路径的小 bug。
• 输出补丁草稿，由人 review。
• 解释日志或错误堆栈，但不直接改生产配置。
• 把所有代码变更放进正常 PR 流程。

两个方向都不要一开始就自动合并或自动部署。

一个实用决策表

常见误解

第一个误解，是把 Worker Agents 当成“会写代码的通用机器人”。它们当然可以参与代码相关流程，但核心优势是 pipeline-native、可版本化、可审查、可输出给下游流程。

第二个误解，是把 Code Agent 当成“可以直接部署的 pipeline Agent”。IDE 助手的强项是代码和开发者上下文，不是替代部署审批。

第三个误解，是把 MCP 接入当成治理完成。MCP 只是让工具能访问资源，真正的边界仍然来自 RBAC、toolsets、scoped token、确认机制、日志和回滚。

完成检查

• 你能用一句话区分 Worker Agents 和 Code Agent。
• 你知道你的场景发生在 pipeline 还是代码仓库里。
• 你知道 MCP 是连接层，不是替代 Worker Agents 或 Code Agent 的产品层。
• 你已经选择了低风险试点，并写清楚审批和回滚。
• 你没有把两者都理解成“万能自动开发工具”。

下一步内链

• 如果你的重点是 Worker Agents 的低风险落地，继续看 Harness Worker Agents 教程。
• 如果你要接外部 AI 工具，继续看 Harness MCP Server 教程。
• 如果你还在做 Harness 词义消歧，回到 coding agent harness 工具观察。