很多人听到 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 的区别
| 维度 | 聊天 Agent | Worker Agents |
|---|---|---|
| 入口 | 对话、消息、IDE | pipeline、CI/CD、平台流程 |
| 任务形态 | 临时问答、辅助判断 | 流程节点、顺序执行、自动化步骤 |
| 成功标准 | 回答是否有帮助 | pipeline 是否推进、产物是否可审查 |
| 风险边界 | 工具权限和上下文 | repo、pipeline、secrets、部署权限 |
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 拆成三段：
- Analyzer：只读分析，生成风险和上下文。
- Planner：把需求或错误拆成可执行计划。
- Executor：在受限范围内生成草稿变更。
这比“一个 Agent 从头做到尾”更适合工程团队复盘和治理。
官方示例里甚至把这三段进一步串成顺序流水线，并允许你在 Plan Generator 和 Implementation 之间插入 Approval step。这个设计非常值得照抄，因为它把“AI 能做”与“团队愿意让它做”分开了。
什么时候该停在 spec / plan，不要走到 implementation
下面这些情况，更适合先停在前两段：
- 需求本身还在频繁改。
- 仓库测试不稳定，自动实现难以验收。
- 团队还没定义 acceptance criteria。
- 还没准备好让 Agent 直接往 PR 分支提交。
这时 Worker Agents 的价值主要是结构化需求、拆任务、补上下文，而不是立刻产出代码。
运行权限要看三层
| 层级 | 你要确认什么 |
|---|---|
| Pipeline 权限 | 谁能创建、编辑、执行这条 pipeline |
| Connector 权限 | 谁能改模型连接器和 MCP 连接器 |
| Runtime 权限 | Agent 容器在云上还是自有集群，能出网到哪里 |
官方文档把 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 平台”。
一个在流程里，一个在入口处，治理方式完全不同。
一条更现实的上线顺序
- 先做失败总结或 spec 生成。
- 再做 plan 生成和结构化建议。
- 插入人工审批。
- 最后才让 Implementation Agent 产出草稿代码。
- 生产部署仍保留原有门禁，不因为接了 Agent 就跳过。
完成检查
- 你能区分 Worker Agents 和聊天 Agent。
- 你知道它跑在 Harness Cloud 还是自有基础设施。
- 你知道哪些任务适合只读分析，哪些任务必须审批。
- 你已经为试点场景写出输入、输出、门禁和回滚。
- 你不会把 pipeline-native Agent 当成万能自动部署按钮。