AI 编码助手停留在聊天窗口时，核心问题是“它能不能给出有用建议”；一旦进入软件交付流水线，核心问题就变成“它能不能在正确的权限、上下文、沙箱、审批和审计约束下执行动作”。这就是 harness + agent 的价值：harness 不是模型外面的一层薄包装，而是让 agent 能够安全、可追踪、可评测、可回滚地参与真实工程系统的运行时底座。

Harness.io 的方向具有代表性。它把 AI agent 放进 DevOps、测试、SRE、发布治理等环节，强调 agent 在 pipeline 中继承上下文、连接器、密钥、RBAC 和审计边界。GitHub Copilot coding agent 走的是 issue 到 draft PR 的异步协作模式，依赖 GitHub Actions 临时开发环境和 PR review 流程；GitLab Duo Agent Platform 把 flows、sessions、runner 执行和代码评审放进 GitLab 生命周期；Atlassian Rovo Dev 则从 Jira work item 进入代码生成、分支和 PR，运行在云端 sandbox session 中；MCP 负责标准化 agent 与工具/数据源的连接，但并不自动提供企业级治理。

因此，企业真正要建设的不是“再接一个大模型 API”，而是一套 agent harness：agent gateway、context graph、tool registry、policy engine、sandbox runner、eval runner、audit store、rollback controller 和 human-in-the-loop workflow。模型能力会继续变化，但这层底座决定 AI 能不能从个人效率工具升级为可治理的软件交付能力。

为什么这个问题现在重要

过去两年，团队最先采用的是 IDE 补全、聊天问答、代码解释和单元测试生成。这类工具的风险相对有限，因为人类仍然在本地控制复制、保存、提交和合并。现在新的产品形态正在改变边界：

• GitHub Copilot coding agent 可以被分配 issue，研究仓库、修改代码、运行测试并创建 draft pull request。
• GitLab Duo Agent Platform 将 Developer Flow、Code Review Flow 等能力放进 GitLab 的 issue、MR、runner 和 session 体系。
• Atlassian Rovo Dev in Jira 可以从 Jira work item 直接生成代码，选择仓库，继续会话，并创建分支和 pull request。
• Harness Agents 则把 agent 放在 pipeline 内，面向构建、部署、测试、修复、优化和治理等“代码之后”的交付任务。

这意味着 agent 开始触碰真实资产：源码、制品、密钥、部署环境、配置、Jira/Confluence 知识、CI/CD pipeline、生产事件和回滚动作。只靠“请谨慎操作”的 prompt 已经不够，企业需要回答更硬的问题：

• 这个 agent 是以谁的身份行动？
• 它能读哪些上下文，不能读哪些上下文？
• 它能调用哪些工具，是否有参数级权限限制？
• 它运行在什么沙箱里，能否访问外网和生产系统？
• 它的每一步是否可审计、可复现、可回放？
• 失败后如何回滚，如何让人类接管？
• 如何评测它不是“看起来完成了”，而是真的降低了交付风险？

这就是 harness 工程的主场。

概念边界：Harness.io 与 agent harness

本文中的 harness 有两层含义。

第一层是产品层：Harness.io 是一个面向软件交付的 DevOps 平台，覆盖 CI/CD、feature flag、cloud cost、security testing、chaos engineering、service reliability、software engineering insights 等能力。其 AI 产品线把 DevOps Agent、AI Test Automation、AI SRE、Agents 等放进软件交付链路。

第二层是工程层：agent harness 是让 AI agent 在企业工程系统中可靠运行的底座。它不等同于 LangChain、MCP、IDE 插件或单个 coding agent，而是包住 agent 生命周期的治理层，负责上下文、工具、权限、沙箱、审计、评测、回滚、人工审批、成本和可观测性。

可以用一个简单公式描述：

可治理的软件交付 agent = 模型 + 工具协议 + 上下文系统 + 权限系统 + 沙箱执行 + 评测门禁 + 审计追踪 + 回滚机制 + 人类决策点

没有 harness 的 agent 很容易变成“会调用工具的聊天机器人”；有 harness 的 agent 才能进入软件交付流水线。

本文后续分析按四类证据边界处理：

类型	本文如何使用
官方已发布能力	以 Harness、GitHub、GitLab、Atlassian、MCP 官方文档为准，描述其当前公开机制。
Preview/Beta/路线图	对 Harness Agents Limited Preview、Harness Agents roadmap 等内容只作为方向判断，不当作所有企业已经可用的 GA 能力。
基于公开资料的工程推断	从 pipeline、PR/MR、session、sandbox、MCP gateway、RBAC 等机制推导企业需要的通用 agent harness 架构。
本文落地建议	checklist、指标体系、policy 示例、分阶段落地路径属于本文建议，需要结合企业现有平台改造。

国内外产品与实践调研

Harness.io：pipeline-native agent 的代表

Harness Agents 的官方定位是 pipeline-native AI agents。公开资料显示，Harness Agents 是在 pipeline 中执行 DevOps 任务的 autonomous workers，目标覆盖从 commit 到 production 的构建、部署、测试、修复和优化。其关键点不是“agent 能说什么”，而是“agent 作为 pipeline step 运行”，并继承 pipeline 的执行上下文、secrets、connectors、RBAC scope 和治理控制，同时动作可记录、可审计、可治理。

这一设计很关键。企业交付系统本来就已经有 pipeline、环境、审批、密钥、连接器、制品、部署策略和审计日志。把 agent 放进这些既有边界，比让 agent 在外部聊天窗口里遥控 CI/CD 更容易治理。

Harness AI DevOps Agent 则偏交互式和配置生成能力，支持用自然语言创建或修改 pipeline、stage，并覆盖 GitOps 资源操作。官方文档还记录了 2026 年 2 月的更新：其架构从多个子 agent 合并为统一 DevOps agent，以提升上下文保持、响应速度和 pipeline 生成准确性。这说明 Harness 的 agent 方向并不是单点 Copilot，而是在工程流程中沉淀可执行的 DevOps 自动化能力。

Harness AI Test Automation 和 AI SRE 则补足了两类关键治理能力：前者把自然语言测试、自愈测试维护和自动化测试执行纳入质量链路；后者面向 incident detection、response、resolution、root cause context 和 remediation。对 agent harness 来说，测试和 SRE 不是外围能力，而是 agent 执行后验证与回滚的重要输入。

需要注意的是，Harness Agents 产品页显示为 Limited Preview。本文把其 pipeline-native 机制作为代表性方向分析，但不把所有能力视为已全面 GA。

GitHub：issue 到 draft PR 的异步 coding agent

GitHub Copilot coding agent 的治理模型围绕 GitHub 原生协作流展开：把任务交给 Copilot，Copilot 在 GitHub 上工作，创建 draft pull request，再由人类 review。官方文档说明，coding agent 在 GitHub Actions 驱动的临时开发环境中探索代码、修改代码、运行测试和 linters。GitHub 也支持从 issue、agents panel、Copilot Chat、CLI，以及支持 MCP 的工具和 IDE 启动任务。

这个模式的优势是清晰：代码变更天然进入 PR，而不是绕过 review 直接写入主干。GitHub 把 human-in-the-loop 放在 merge 前，把 agent 的输出转换成团队熟悉的 review 对象。它也通过自定义 instructions、仓库上下文、MCP 连接和环境配置，让 agent 尽量贴近项目约定。

但这类 coding agent 的治理边界仍主要围绕代码仓库和 PR 流程。它擅长 issue -> branch -> draft PR，不等于可以直接拥有部署、回滚、生产数据访问或跨系统写权限。要进入交付流水线，还需要 pipeline 级 policy、approval、secret scope、environment protection 和 release audit。

GitLab：flows、sessions 与 runner 执行

GitLab Duo Agent Platform 的公开文档把 agents 嵌入整个 SDLC，提供 foundational flows。Developer Flow 可以从 issue 创建 draft merge request，Code Review Flow 可以在 merge request 中进行 agentic code review，sessions 则用于查看 agent/flow 的状态与执行数据。

GitLab 的一个重要特点是，它把 agent 行为和 GitLab 现有对象绑定起来：issue、MR、discussion thread、runner、session、role、feature flag、branch 规则、push rule。官方 troubleshooting 文档还提到，Agent Platform jobs 会设置 GIT_CONFIG_GLOBAL=/dev/null 和 GIT_CONFIG_NOSYSTEM=1 来加固 agent sandbox。这类细节说明，agent 运行时不是简单地“给模型一个 shell”，而是要处理 Git 配置、runner 权限、分支规则、失败诊断等工程问题。

GitLab sessions 也值得关注。对企业而言，“agent 做了什么”不能只存在聊天记录里，而应成为平台级对象，可以查看状态、执行数据、日志和失败原因。没有 session/audit 这样的可观测层，agent 的生产问题很难复盘。

Atlassian Rovo Dev：从 Jira work item 进入代码与 PR

Rovo Dev in Jira 代表另一种入口：需求管理系统中的 work item。官方文档显示，用户可以在 Jira work item 中选择仓库，让 Rovo Dev 基于任务详情生成代码；生成过程运行在安全的云端 coding session 和 dedicated sandbox 中；只有启动 session 的用户或自动化规则能访问该 sandbox；Rovo Dev 可以代表发起用户在其权限范围内对 Jira 和 Confluence 做 create/read/update/search，但不做 delete；对代码仓库的读写限制在本次 session 选择的 repository。

这套模型的价值在于，它把上下文入口前移到了 Jira/Confluence：需求、验收标准、设计说明、讨论记录、代码仓库连接都可以成为 agent 的输入。同时，Rovo Dev 不会直接 merge draft PR，而是交回团队 review 和 merge。这是典型的人类最终审批模式。

Atlassian 还提供 Rovo MCP server 和 Rovo Dev advanced agentic configuration，允许控制 MCP server、工具权限和外部 AI 工具连接域名。这说明 MCP 正在成为工具连接层，但 Atlassian 仍需要在组织管理、域名控制、工具许可和身份权限上加治理。

MCP：连接标准，不是治理系统本身

MCP 的贡献是把 agent 与外部工具/数据源之间的连接标准化。官方架构采用 host-client-server 模式：host 是 AI 应用，client 与 server 建立一对一会话，server 暴露 resources、tools、prompts 等能力。MCP 规格强调 host 控制连接权限、生命周期、安全策略、用户授权决策和上下文聚合；server 不应读取完整会话，也不能看到其他 server。

这给 agent harness 提供了一个可组合工具层：Jira、GitHub、数据库、监控、文档、内部平台都可以通过 MCP server 暴露能力。但 MCP 不是完整的企业治理方案。它可以定义工具协议、OAuth 授权、capability negotiation、resources、tools、roots、sampling，却不会自动替企业解决：

• 哪个 agent 可以调用哪个 MCP server；
• 同一个工具的哪些参数需要审批；
• 哪些生产动作必须二次确认；
• 工具调用结果如何写入企业审计；
• MCP server 是否可信，是否可能提示注入或数据外泄；
• 出错后如何回滚业务状态。

因此，MCP 更像工具总线，agent harness 才是治理控制面。

能力矩阵：谁解决了哪一层问题

能力维度	Harness Agents	GitHub Copilot coding agent	GitLab Duo Agent Platform	Atlassian Rovo Dev	MCP
主要入口	Pipeline、DevOps 任务	Issue、PR、GitHub UI、IDE、CLI、MCP	Issue、MR、IDE/UI flows、runner	Jira work item、IDE、Bitbucket/GitHub	任意支持 MCP 的 host
核心对象	Pipeline、stage、connector、secret、environment	Issue、branch、draft PR、Actions environment	Issue、MR、flow、session、runner	Work item、coding session、repository、PR	Host、client、server、tool、resource、prompt
上下文来源	Pipeline context、SDLC 连接器、密钥与治理边界	仓库、issue、instructions、Actions 环境、MCP	GitLab 项目、issue/MR、runner、session、agent config	Jira、Confluence、代码仓库、session	Server 暴露的 resources/tools/prompts
权限模型	继承 pipeline 权限、secrets、RBAC scope	GitHub 仓库权限、可分配人控制、PR review	GitLab role、runner、flow prerequisites、项目规则	发起用户权限、组织/站点开关、仓库选择	OAuth/transport auth 与 host 控制，需外部治理补强
沙箱/执行	Pipeline-native execution；Worker Agents	GitHub Actions 临时开发环境	Runner/flow execution；sandbox hardening	Dedicated cloud sandbox session	协议本身不提供统一沙箱
审计/可观测	Pipeline log、治理记录、审计	Agent session logs、PR commits/comments	Sessions、CI job trace、flow 状态	Session、PR、Jira/Confluence 操作记录	取决于 host/gateway/server 实现
质量门禁	可与测试、security、approval、release gate 组合	测试/linters + PR review	Code Review Flow、runner、MR review	生成后交回团队 review/merge	不定义质量门禁
回滚能力	可接入 pipeline rollback、GitOps、release 治理	通过 PR 不合并/回退 commit	MR/branch/pipeline 层回退	PR 不合并或回退分支	需要业务系统自行实现
适合定位	交付治理与 DevOps 自动化	代码变更自动化	GitLab 内 SDLC agent 平台	Jira 驱动的计划到代码	工具连接标准

核心工程机制拆解

1. Agent 底座：把“能行动”变成“可控地行动”

一个生产级 agent harness 至少要包含九个组件：

这个架构里，模型只是 runtime 的一部分。真正决定安全性的，是 gateway、policy、sandbox、eval、audit 和 human gate。

2. 权限：身份继承必须可解释、可收回、可审计

agent 权限不能是一个永久高权限 token。更合理的做法是任务级身份：

• 以发起人、服务账号或 pipeline identity 建立执行主体；
• 使用最小权限 token，按任务、仓库、环境、工具和时间范围发放；
• 对 destructive action、生产环境写操作、跨系统同步、删除、回滚、权限变更设置强制审批；
• 将每一次 tool call 记录为“谁发起、agent 以什么身份、调用了什么工具、参数是什么、结果是什么”。

Harness 的 pipeline-native 设计强调继承 pipeline 的 secrets、connectors 和 RBAC scope；Rovo Dev 文档强调以发起用户权限访问 Jira/Confluence，并把代码仓库访问限制在所选 repository；MCP 2025-06-18 授权规范则强调 HTTP transport 下的 OAuth 2.1、Protected Resource Metadata、Dynamic Client Registration、resource parameter、token audience validation 和禁止 token 误用。这些机制共同指向一个原则：agent 不应该绕过原有权限系统。

3. 上下文：不要把所有东西塞进 prompt，要构建 context graph

agent 需要上下文，但上下文越多，污染、泄露和误导风险越高。企业应把上下文分层：

• 任务上下文：issue、Jira work item、验收标准、评论、附件；
• 代码上下文：相关文件、依赖图、接口、测试、历史变更；
• 组织上下文：编码规范、架构原则、runbook、发布策略；
• 运行上下文：pipeline 状态、失败日志、部署环境、feature flag；
• 线上上下文：metrics、logs、traces、incident timeline、SLO；
• 风险上下文：敏感文件、生产环境、合规约束、禁用工具。

GitHub 的 repository custom instructions、GitLab Developer Flow 的 issue/MR context、Rovo Dev 的 Jira/Confluence/code context，以及 Harness 的 pipeline context 都是在做同一件事：让 agent 的输入从“用户一句话”变成“结构化工程上下文”。但 harness 必须控制上下文注入策略，不能让 agent 任意读取全量企业知识库。

4. 沙箱：agent 能运行命令，但不能随便触碰世界

coding agent 和 delivery agent 都需要执行环境。这个环境要同时满足可用性和隔离性：

• 临时工作区，任务结束后销毁；
• 依赖安装和测试命令可复现；
• 默认限制外网访问，只允许 allowlist；
• secret 按需注入，且不出现在日志、prompt 和工具返回中；
• 文件系统 root 明确，禁止越权读取；
• 对生产 API、支付、客户数据、权限管理等工具设置只读或审批模式；
• 保存命令日志、退出码、artifact 和 diff。

GitHub 使用 GitHub Actions 临时开发环境；Rovo Dev 使用 dedicated cloud sandbox；GitLab 基于 runner/flow 执行，并在 troubleshooting 文档中体现了 sandbox hardening 细节；Harness 把 agent 作为 pipeline-native worker，天然接近已有 CI/CD 隔离体系。企业自建 harness 时，应优先复用成熟 CI runner、container runtime、network policy 和 secret manager，而不是让 agent 在开发者本机或共享服务器上裸跑。

5. 审计：审计对象不是聊天记录，而是完整轨迹

软件交付中的 agent 审计至少要包含：

• 触发源：issue、pipeline、incident、人工命令或自动化规则；
• 身份链：发起人、审批人、agent identity、服务账号；
• 输入：用户指令、系统规则、上下文片段、策略版本；
• 计划：agent 生成的任务拆解和风险说明；
• 工具调用：工具名、参数、scope、返回摘要、错误；
• 代码与配置变更：diff、commit、branch、PR/MR；
• 质量结果：测试、lint、扫描、评测分；
• 人工决策：批准、驳回、修改意见；
• 交付结果：部署版本、环境、回滚点、线上指标；
• 成本与时延：模型、token、运行时长、失败重试。

GitHub 的 agent session logs、GitLab sessions、Harness pipeline logs、Rovo Dev sessions 都在向这个方向演进。企业不能只保存最终 PR，因为事故发生时需要回答的是“agent 为什么这么做”，不是“最后改了哪些文件”。

6. 评测：从 prompt eval 走向交付 eval

Agent 的评测不能停留在“回答是否像样”。进入交付流水线后，评测应覆盖四层：

评测层	目标	示例指标
任务完成	是否按需求完成	issue 验收通过率、PR 一次通过率、计划-实现一致性
工程质量	是否降低风险	测试通过率、覆盖率变化、lint/security 结果、缺陷密度
治理合规	是否遵守边界	越权工具调用数、审批绕过数、secret 泄露、策略命中
线上结果	是否真的改善交付	变更失败率、MTTR、回滚率、incident follow-up 完成率

Harness AI Test Automation、GitLab Code Review Flow、GitHub PR review 流程、Rovo Dev code review 论文和 SRE 类产品都提醒我们：agent 生成代码只是中间产物，最终要看质量、稳定性和 review 负担。评测样本也不应只来自 benchmark，要从真实历史 issue、失败 pipeline、incident、回滚记录和 postmortem 中抽取。

7. 回滚：默认把 agent 输出当作可撤销变更

Agent 的每个动作都应设计回滚路径：

• 代码变更：branch、draft PR、revert commit；
• 配置变更：GitOps commit、配置版本、差异审查；
• 数据变更：dry-run、备份、补偿任务；
• 部署变更：canary、feature flag、blue-green、rollback pipeline；
• 文档/工单变更：保留历史版本和来源链接；
• 权限变更：短期授权，到期自动失效。

这也是为什么 PR/MR、pipeline、GitOps 和 feature flag 是 agent 进入交付链路的好边界。它们天然提供差异、审批、版本和回滚点。相反，让 agent 直接调用生产 API 修改状态，除非有非常强的审计与补偿机制，否则不应作为早期落地路径。

8. Human-in-the-loop：人不应该只做橡皮图章

很多团队会把 human-in-the-loop 理解成“最后让人点一下批准”。这不够。人类参与应该出现在不同风险等级的位置：

• 低风险：文档草稿、测试生成、非生产查询，可自动执行，事后抽检；
• 中风险：代码修改、pipeline 修改、依赖升级，必须 PR/MR review；
• 高风险：生产部署、回滚、权限变更、数据修复，必须事前审批；
• 极高风险：客户数据导出、删除、财务动作、安全策略变更，默认禁止或双人审批。

人类审批点还必须有足够信息：agent plan、diff、测试结果、策略命中、风险解释、回滚方案。如果审批人只看到“是否允许 agent 继续”，那不是治理，只是风险转嫁。

管理者视角：组织、流程、指标、风险

组织上：把 agent 当作“受控执行者”，不是虚拟员工

管理者最容易犯的错，是把 agent 当成“可以自动接活的新人”。更准确的定位是受控执行者：它可以提高处理吞吐，但必须在清晰边界里工作。组织上需要定义：

• Agent owner：谁负责每个 agent 的能力、风险和成本；
• Tool owner：谁批准工具接入、scope 和参数 schema；
• Policy owner：谁维护审批规则、生产环境边界和禁用动作；
• Eval owner：谁维护评测集、golden traces 和质量指标；
• Incident owner：agent 出错时谁有权暂停、回滚和复盘。

如果没有 owner，agent 只会变成跨团队灰色自动化。

流程上：先从 PR 和 pipeline gate 落地

推荐落地顺序不是“一步到位自动部署”，而是：

1. 让 agent 生成计划和 PR，但不自动合并。
2. 让 agent 修复 CI 失败，但仍走 MR/PR review。
3. 让 agent 生成或修改 pipeline，但通过 code owner 和 platform owner 审批。
4. 让 agent 在非生产环境执行部署、回滚演练和测试。
5. 对低风险服务开放自动化 release suggestion。
6. 对生产环境只开放建议、dry-run、canary 分析和回滚预案，自动执行需逐步授权。

这个路径的好处是每一步都复用已有工程对象：PR、pipeline、environment、approval、audit log。

指标上：不要只看“节省多少人天”

Agent 的价值应通过组合指标判断：

• 效率：issue 到 PR lead time、CI 修复时间、review 周期；
• 质量：PR 一次通过率、缺陷密度、回归率、测试有效性；
• 稳定性：变更失败率、回滚率、MTTR、SLO burn；
• 治理：越权尝试、审批命中、审计完整率、策略误报/漏报；
• 体验：开发者采纳率、人工修改比例、重复任务减少量；
• 成本：token、runner、失败重试、人工 review 成本。

如果只看代码行数或任务数量，agent 很容易制造更多 review 负担和隐藏技术债。

风险上：重点盯五类事故

风险	典型场景	治理手段
越权执行	agent 调用不该调用的生产工具	task-scoped identity、policy engine、审批
上下文污染	issue 或网页内容诱导 agent 泄露 secret	上下文分级、提示注入检测、工具返回过滤
错误自动化	agent 修复 CI 但引入功能回归	eval runner、回归测试、PR review
审计缺失	出事后无法解释 agent 行为	session/audit store、tool call trace
回滚困难	agent 直接改生产状态	GitOps、dry-run、补偿任务、rollback controller

工程师/架构师视角：落地细节

Agent gateway：统一入口，不让工具各自接模型

企业内部很容易出现多个团队各自把 LLM 接到 Jira、GitHub、Slack、CI、监控平台。短期快，长期会造成权限、日志、成本、策略全部分裂。更可控的方式是建立 agent gateway：

• 统一接收任务触发；
• 标准化身份、租户、仓库、环境、风险等级；
• 给每个任务分配 budget、timeout、retry 策略；
• 调用 policy engine 判断是否允许；
• 选择 agent runtime 和模型；
• 把轨迹写入 audit store。

Gateway 不是为了集中所有业务逻辑，而是为了把治理控制面集中。

Tool registry / MCP gateway：工具必须有 schema、scope 和风险等级

无论是否采用 MCP，每个工具都应登记以下元数据：

• 名称、owner、版本、环境；
• 输入/输出 schema；
• read/write/delete/execute 分类；
• 可访问资源范围；
• 是否允许生产环境；
• 是否需要人工审批；
• 是否支持 dry-run；
• 是否支持幂等与回滚；
• 日志脱敏规则；
• 测试 mock 与 replay 能力。

MCP 可以作为工具协议，但企业仍需要 MCP gateway 来做 allowlist、domain control、token broker、参数审计、tool poisoning 防护和速率限制。

Policy engine：把治理规则从 prompt 中拿出来

不要把关键规则写成“你不能删除数据”放进 prompt。Prompt 是行为引导，不是强制控制。策略应放在外部 policy engine 中，例如：

IF action = deploy AND env = production
THEN require approval from service_owner AND sre_oncall

IF tool = database_write AND table contains customer_data
THEN deny unless change_ticket has security_approval

IF repository contains regulated_code
THEN require code_owner_review AND security_scan_passed

工程实现上可使用 OPA/Rego、云 IAM、CI/CD approval、GitHub branch protection、GitLab approval rules、Harness governance 或内部策略服务组合完成。

Eval runner：把“是否可交付”变成自动门禁

Eval runner 应连接：

• 单元测试、集成测试、E2E 测试；
• lint、typecheck、license、SAST、SCA、secret scan；
• 关键业务回归用例；
• 生成代码 diff 风险评分；
• 历史 incident regression tests；
• agent 行为规则测试，例如禁止访问未授权路径。

更进一步，可以把线上真实失败转成 eval case。比如一次 incident 的根因是“配置项缺失导致 canary 异常”，复盘后应沉淀成：当 agent 未来修改同类配置时，必须运行对应验证，并给出回滚路径。

Audit store：轨迹要能被人和机器复用

Audit store 不只是合规存档，也应服务复盘和改进。建议存储结构化事件：

{
  "task_id": "agent-task-20260524-001",
  "trigger": "jira-work-item",
  "actor": "user:alice",
  "agent_identity": "svc-agent-delivery",
  "risk_level": "medium",
  "tool_calls": [
    {
      "tool": "github.create_pull_request",
      "scope": "repo:payments/api",
      "decision": "allowed",
      "approval": "not_required"
    }
  ],
  "artifacts": ["plan.md", "diff.patch", "test-report.xml"],
  "human_decisions": ["review_requested"],
  "rollback": "revert-pr-or-disable-feature-flag"
}

这样后续才能做 agent 行为分析、成本分析、失败聚类和评测集生成。

企业落地实践

阶段 0：准入前

• 明确 agent 只在哪些仓库、项目、环境试点。
• 给每个 agent 指定 owner 和 on-call 责任人。
• 建立工具 registry，标注 read/write/delete/production 风险。
• 建立 task-scoped identity，不使用永久高权限 token。
• 定义日志、prompt、tool response 的 secret 脱敏规则。

阶段 1：代码与 PR

• 只允许 agent 创建 branch 和 draft PR，不允许直接 push protected branch。
• 强制 code owner review 和必要的安全扫描。
• 为仓库提供 instructions：架构、测试命令、编码规范、禁止事项。
• 保存 agent session、计划、工具调用和测试结果。
• 统计 PR 一次通过率、人工修改比例和回归缺陷。

阶段 2：CI/CD 与 pipeline

• 允许 agent 分析 CI 失败并提交修复 PR。
• 允许 agent 生成 pipeline 变更，但必须由 platform owner 审批。
• 在非生产环境验证 agent 触发部署和回滚演练。
• 所有 pipeline secret 通过运行时注入，不进入 prompt。
• 建立失败自动暂停机制：连续失败、越权尝试、成本超限即停用。

阶段 3：发布与生产治理

• 生产部署默认只允许 agent 生成建议和 dry-run 结果。
• canary、feature flag、rollback 必须有明确审批人和回滚点。
• SRE/服务 owner 可查看 agent 的完整执行轨迹。
• incident 后将复盘结论转成 eval case 或 policy rule。
• 定期复审 agent 权限、工具 scope、评测集和审计完整率。

小结

AI agent 进入软件交付流水线后，竞争焦点不再只是模型能力，而是治理底座。Harness.io 的 pipeline-native agent、GitHub 的 PR-first coding agent、GitLab 的 flows/sessions、Rovo Dev 的 Jira-to-code sandbox，以及 MCP 的工具连接标准，共同说明了一个趋势：未来的软件交付平台会把 agent 当成可编排、可审计、可评测、可回滚的执行单元。

企业落地时不要从“让 agent 自动干更多事”开始，而要从“哪些动作可以被安全授权、如何验证、如何审计、如何回滚”开始。只有 harness 足够扎实，AI 才能从聊天窗口进入真正的软件交付流水线。