Harness Worker Agents：pipeline-native AI Agent 和聊天 Agent 有什么不同

Harness 应用 进阶 进阶 预计 14 分钟 发布于 2026/5/23 核验于 2026/6/3

很多人听到 Harness Worker Agents，会下意识把它想成“DevOps 里的聊天机器人”。这个理解太浅。

更准确的理解是：Worker Agents 是 pipeline-native 的 AI 工位。它们不是等你在聊天窗口里问一句，而是可以进入软件交付流程，完成分析、计划、执行和回写。

Harness 最新官方文档把这个定位说得更明确：Worker Agents 是能被放进 CI、CD、IaCM、STO、SCS 或 Custom stage 里的 AI 自动化单元。它由 prompt、模型连接器和可选 MCP Server 组合成一个可复用 step，而不是一个“随便聊聊”的入口。

和聊天 Agent 的区别

Worker Agents 的价值在于它能贴近真实工程流程，但也因为贴近流程，权限治理更重要。

先理解它到底跑在哪里

官方文档给了一个很重要的边界：Worker Agents 在 Docker 容器里执行，并且运行在隔离 VM 中。你可以把它跑在 Harness Cloud，也可以跑在自有 Kubernetes 集群上。

这意味着你在评估的不只是“模型能不能做”，还包括：

• 数据和网络要经过哪条基础设施。
• secrets 和 scoped token 怎么下发。
• 是用 Harness Cloud，还是自己承担集群与网络边界。

如果团队对数据驻留和出网限制很敏感，这一段比 prompt 本身更先决定能不能试点。

适合试点的场景

第一阶段建议选择低风险、可审查的场景：

• 分析 PR 里的变更风险。
• 根据 Features.md 或需求文档生成 spec。
• 把 spec 拆成 coding plan。
• 给失败 pipeline 生成排查摘要。
• 生成草稿提交或建议，而不是直接合并。

这些场景的共同点是：Agent 负责把信息结构化，最终动作仍有人工或 pipeline 门禁。

其中最值得借鉴的是官方给出的 spec-driven development 路线：先分析需求文件生成 Spec.md，再生成 Plan.md，最后才进入实现步骤。这个顺序的核心，不是追求自动写代码，而是让产物变得可审查。

暂缓自动化的场景

下面这些不要一开始就交给 Worker Agents：

• 直接修改生产 pipeline。
• 自动触发生产部署。
• 自动改 secrets、权限或策略。
• 在没有测试覆盖时自动合并代码。
• 无日志、无审批、无回滚的写操作。

DevOps Agent 做得越深，越不能靠“相信模型”来上线。

尤其不要忽略两种“看上去没出事，实际风险很大”的动作：

• 直接往 PR source branch 回写产物或代码。
• 在没有审批门禁时顺着 pipeline 自动进入部署面。

一个更稳的 pipeline 设计

可以把 Worker Agents 拆成三段：

1. Analyzer：只读分析，生成风险和上下文。
2. Planner：把需求或错误拆成可执行计划。
3. Executor：在受限范围内生成草稿变更。

这比“一个 Agent 从头做到尾”更适合工程团队复盘和治理。

官方示例里甚至把这三段进一步串成顺序流水线，并允许你在 Plan Generator 和 Implementation 之间插入 Approval step。这个设计非常值得照抄，因为它把“AI 能做”与“团队愿意让它做”分开了。

什么时候该停在 spec / plan，不要走到 implementation

下面这些情况，更适合先停在前两段：

• 需求本身还在频繁改。
• 仓库测试不稳定，自动实现难以验收。
• 团队还没定义 acceptance criteria。
• 还没准备好让 Agent 直接往 PR 分支提交。

这时 Worker Agents 的价值主要是结构化需求、拆任务、补上下文，而不是立刻产出代码。

运行权限要看三层

官方文档把 pipeline、connector 权限都列成前置条件，这说明 Worker Agents 从第一天起就是平台能力，不是单机玩具。

官方示例真正值得学的，不是“自动实现”，而是状态管理

在 spec-driven development 示例里，Implementation Agent 会跟踪任务状态，并把进度写进 sidecar status file。这个细节很关键：

• 任务不会因为一次失败就失去上下文。
• 你可以限制每轮最多执行多少任务。
• 下次重跑时，Agent 能知道哪些已完成、哪些 blocked。

这比“每次从头让模型看一遍 PR 然后重做”稳定得多。

和 Harness MCP Server 的关系

Worker Agents 更像 Harness 平台内部的 pipeline AI 能力；MCP Server 更像把 Harness 能力开放给外部 AI 工具。

如果你想把 AI 放进 CI/CD 流程，先看 Worker Agents。
如果你想让 Cursor、Claude Desktop、Windsurf 或 VS Code 访问 Harness 平台，再看 MCP Server。

再说得更直接一点：

• Worker Agents 解决“让 pipeline 里多一个 AI 工位”。
• MCP Server 解决“让外部 AI 客户端摸到 Harness 平台”。

一个在流程里，一个在入口处，治理方式完全不同。

一条更现实的上线顺序

1. 先做失败总结或 spec 生成。
2. 再做 plan 生成和结构化建议。
3. 插入人工审批。
4. 最后才让 Implementation Agent 产出草稿代码。
5. 生产部署仍保留原有门禁，不因为接了 Agent 就跳过。

完成检查

• 你能区分 Worker Agents 和聊天 Agent。
• 你知道它跑在 Harness Cloud 还是自有基础设施。
• 你知道哪些任务适合只读分析，哪些任务必须审批。
• 你已经为试点场景写出输入、输出、门禁和回滚。
• 你不会把 pipeline-native Agent 当成万能自动部署按钮。