这篇教程只验证 Harness UI 内的 DevOps Agent，不把 Worker Agent、VS Code Extension 或 Code Quality Autofix 混进同一条测试链。你会先在测试 Pipeline 中运行一个固定失败命令，再核对 AI 是否指向正确 execution、step、命令和 exit code；只有 diff 可审查、重跑成功且可以回滚，才算通过。
固定金丝雀是 DEVOPS-ERROR-761。它不是凭据，只用来证明分析没有串到其他日志。
**核验边界：**本站核读了 2026-09-10 的官方文档并静态检查下载材料，没有 Harness 账号内的操作记录。页面中的按钮名来自当前文档，实际入口受租户、导航版本、模块和 RBAC 影响；验收表默认全部“未验证”。
下载三份材料
不要在材料中写 PAT、API Key、Secret 值、完整客户日志或生产资源名称。
这次实验的唯一成功定义
| 阶段 | 步骤 | 证据 |
|---|---|---|
| 入口与基线 | D01–D04 | Harness AI scope、入口选择、失败命令、原始 execution / log / audit |
| 分析 | D05–D07 | Analyze Error 结果、逐项证据对照、信息不足负例 |
| 修改 | D08–D11 | before/after YAML、拒绝路径、测试项目 Accept、成功重跑 |
| 治理 | D12–D14 | RBAC 负例、恢复前一版本、停用与审计收口 |
“AI 建议看起来合理”不在成功定义里。
D01：确认 Harness AI 的启用范围
当前官方步骤是：在 Harness UI 进入 Account Settings → General → Default Settings → Harness AI 并启用设置；如果开启 Allow Overrides，组织或项目可能覆盖账户设置。
记录：
- Account / Org / Project 的脱敏 identifier；
- 三层 Harness AI 设置的实际值与继承关系；
- 操作者能否修改设置；
- 测试项目可用的模块；
- DevOps Agent 入口是否可见。
DevOps Agent 不需要单独从外部市场安装，且当前文档说明它只在 Harness UI 中提供。入口不可见时先核对设置、模块和 RBAC，不要安装名称相似的 IDE 扩展代替。
**D01 通过条件：**能够说明最终生效的是账户、组织还是项目设置，并保存不含秘密值的证据。
D02：确认任务应该进入 DevOps Agent
当前 DevOps Agent 能力覆盖 Pipeline step / stage / Pipeline 创建编辑、multi-module Pipeline、OPA Rego、Error Analyzer、Pipeline Summarizer、资源管理和 GitOps 操作。不同任务风险差异很大。
| 任务 | 本次入口 | 是否进入本实验 |
|---|---|---|
| 人在 UI 中分析一次失败 | DevOps Agent / Analyze Error | 是 |
| 每次 Pipeline 运行自动分析 | Worker Agent | 否，转到 W01–W14 |
| 自动从 CI 失败生成代码 PR | Code Quality Autofix | 否，单独验证仓库与 PR |
| IDE 内看日志与审批 | VS Code Extension | 否 |
| 外部客户端读取 Harness 资源 | MCP Server | 否 |
**D02 通过条件：**运行卡中只选择“UI Error Analyzer + YAML 修复”，明确不创建 Service、Environment、Connector、Secret、策略或 GitOps 资源。
D03：在测试 Pipeline 创建可控 exit 17
新建或复制一条不会部署、不会访问客户数据的测试 Pipeline。在单独的 Run step 中使用下载脚本内容：
#!/bin/sh
set -eu
printf '%s\n' 'DEVOPS-ERROR-761: controlled failure' >&2
exit 17运行前保存：
- Pipeline identifier 与配置版本；
- stage / step identifier；
- 失败命令的精确字节或 SHA-256；
- 分支与 commit SHA（若关联代码库）；
- 预期首个错误
DEVOPS-ERROR-761； - 预期 exit code
17。
执行一次并确认 Pipeline 失败。如果 step 被条件跳过、shell 没有执行，或失败来自别的依赖，这次 execution 不能作为样本。
D04：在使用 AI 前冻结原始证据
记录失败 execution ID、开始/结束时间、触发者、输入、stage、step、实际命令、exit code 和首个相关日志。再打开当前文档所述的 audit trail，保存失败前最近一次 Pipeline 修改的时间和操作者。
对日志做最小脱敏，不要把完整私人日志复制到共享表。原始证据要回答：
execution 是否是本次测试？
运行的是哪个 Pipeline 配置版本？
首个失败 step 和命令是什么？
日志是否包含且只包含预期 canary？
实际 exit code 是否为 17？**硬失败：**五项任一不一致，停止分析，重新建立干净样本。
D05：运行 Analyze Error 并保存完整输出
进入失败 execution，选择 Analyze Error。当前官方文档说明结果显示在 Change Impact Correlation panel，可包含最近修改、外部依赖状态、历史相似失败、根因、优先级建议、影响和风险。
记录：
- 分析对应的 execution ID；
- 面板中识别的 stage / step / command；
- Change Impact 项及其时间、作者证据；
- Dependency status 的实际来源；
- Historical pattern 的相似度与可访问样本；
- Root cause、recommendation、priority、justification；
- 页面显示的 model / feature 信息（若有）。
不存在的面板字段写“未提供”，不能用官方能力列表填成实际结果。
D06：把每条判断回连到原始证据
用下面的规则逐项审查：
| AI 判断 | 必须回连的证据 | 本样本正确方向 |
|---|---|---|
| 首个失败位置 | execution step log | 固定 Run step |
| 失败命令 | 实际 command | exit 17 |
| 根因 | canary + exit status | 人为可控失败，不是业务代码 |
| 最近修改 | audit trail | 与本次配置版本一致 |
| 外部依赖 | 实际依赖检查 | 本命令不需要外部依赖 |
| 建议 | 目标任务合同 | 只修复测试命令，不扩大范围 |
若模型把后续连带错误当成首因、声称某个不存在的服务异常，或引用另一 execution，标为失败。
**D06 通过条件：**根因能回到 canary 和 exit 17，未知项明确，未把历史相似度当作当前事实。
D07：验证信息不足时不会补造
不要删除真实日志。另建一个测试版本，让 step 只执行 exit 17，不输出 canary，再运行并 Analyze Error。
正确结果应承认日志不足，并建议查看实际命令或补充可观测性。若它仍声称找到了 DEVOPS-ERROR-761、某个依赖失败或具体业务根因，说明分析跨运行串线或产生了无依据结论。
保存这条负例 execution，随后恢复 D03 的固定样本。
D08：生成 YAML 修复，但先停在预览
回到 D03 的失败分析面板，选择当前文档中的 Help me fix the pipeline yaml。预览应包含 Problem identified、Solution applied、before/after YAML 和 Updated Step YAML。
本实验的批准目标是把可控失败 step 改为：
#!/bin/sh
set -eu
printf '%s\n' 'DEVOPS-ERROR-761: repaired baseline'
exit 0这不是通用修复建议，而是本实验预先定义的期望。审查 diff：
- 只改测试 step 的 command；
- 保留 step identifier 和其他 Pipeline 结构；
- 不新增或替换 Connector、Secret、Service、Environment、Infrastructure 或 Trigger；
- 不删除真实测试、弱化断言或跳过 stage；
- 当前 Harness 编辑器 schema validation 通过。
**硬失败：**预览影响其他字段、无法显示 diff 或无法通过 schema 时，不点 Accept。
D09：先验证 Reject / 关闭路径
第一次预览选择关闭或拒绝，不接受修改。重新打开 Pipeline，确认配置版本、命令和 SHA-256 与 D03 相同；audit trail 不应出现已应用的 YAML 修改。
这一步证明“查看 AI 建议”与“修改资源”是两件事。若关闭预览仍改变了 Pipeline，停止实验并按变更事件处理。
D10：只在测试项目接受一份可审查 diff
恢复到同一失败 execution，再生成一次修复。确认 diff 与 D08 的批准目标一致，并保存回滚所需的前一版本。然后才在测试项目选择 Accept。
接受后立即检查：
- Pipeline 当前 YAML 的实际值；
- 新配置版本或 Git commit；
- audit trail 的操作者、时间和变更；
- 没有额外资源被创建或 Secret 被改动；
- 页面 toast 不能代替上述四项证据。
**D10 通过条件：**实际保存的 YAML 与预览 diff 一致，审计记录可追溯到本次操作者。
D11：重跑并区分“配置已改”与“修复已验证”
从修改后的配置发起新 execution。记录旧/新 execution、旧/新配置版本、触发者和输入。
通过条件：
- 新 step 日志包含
DEVOPS-ERROR-761: repaired baseline。 - 实际 exit code 为 0。
- 整条测试 Pipeline 为成功终态。
- 没有其他 step 被跳过或删除来换取成功。
- 若关联 Git，验证的 commit SHA 是准备保留的版本。
旧 execution 仍应保持失败记录。不要用新结果覆盖原始问题证据。
D12：验证 RBAC 拒绝
使用只允许查看 execution、不能编辑 Pipeline 的测试角色重复以下动作：
- 打开失败 execution 和日志；
- 请求 Analyze Error；
- 打开 YAML 修复预览；
- 尝试 Accept。
记录每一步实际允许或拒绝的结果。查看分析不应自动等于修改权限；Accept 必须受 Harness RBAC 约束。若只读身份能保存 Pipeline 修改，立即撤销身份并检查角色、资源组和继承权限。
不要为“让测试通过”给只读身份补写权限。本步骤的目标就是观察拒绝。
D13：恢复前一版本并再次运行
使用 D10 保存的恢复点，把 Pipeline 恢复到原始 exit 17 配置。确认：
- diff 只撤销本次 AI 修改；
- audit trail 记录回滚；
- 新的回滚验证 execution 再次以 exit 17 失败；
- canary 与原始失败一致；
- 没有连带恢复其他人的修改。
然后按团队决定保留测试 Pipeline 为暂停状态或删除专门创建的测试资源。删除动作应由账号所有者按组织流程执行，本教程只要求记录最终状态。
D14：停用、清理与形成推广决策
收口以下项目：
- Harness AI 的 Account / Org / Project 设置恢复试验前值。
- 临时编辑角色、资源组和授权已撤销。
- 测试 Trigger 已暂停，测试 Pipeline 不会误部署。
- 下载和共享记录不含凭据或完整私人日志。
- 失败、修复、重跑、权限负例和回滚 execution 均可追溯。
是否推广不能只看一次成功。至少记录人工定位时间、使用 Agent 后定位时间、无依据建议数量、YAML 人工修改量和返工时间；用多次同类故障比较，再决定保留 UI 辅助、转 Worker Agent，还是不采用。
常见问题按证据层排查
| 现象 | 先查 | 不要推断 |
|---|---|---|
| DevOps Agent 不可见 | 三层 Harness AI 设置、模块、RBAC | 浏览器刷新一定能解决 |
| Analyze Error 没有结果 | execution 状态、日志、功能可用性 | 没有根因 |
| 根因详细但不含 canary | execution 对应关系、证据引用 | 文字详细就是准确 |
| YAML 预览无法接受 | 编辑权限、schema、Git Experience / 资源来源 | 建议一定可应用 |
| Accept 后重跑仍失败 | 实际保存 YAML、配置版本、输入、首个新错误 | 原分析完全无价值 |
| 只读身份能修改 | 角色、资源组、继承和 audit trail | AI 自动获得特殊权限 |
最终门禁
- D01–D14 每项都有配置或 execution 证据，硬失败为零。
- 原始失败能以 canary、step、command 和 exit 17 重现。
- Analyze Error 的根因逐项回连原始日志和 audit trail。
- 信息不足负例没有补造 canary、依赖或业务根因。
- Reject 不改配置，Accept 的实际 YAML 与预览一致。
- 新 execution 以 exit 0 成功，回滚 execution 重新以 exit 17 失败。
- 只读身份不能接受修改，临时权限和设置已恢复。
- 记录中没有凭据、完整私人日志或生产资源信息。
需要把已验证任务放进每次 Pipeline 运行，继续 Worker Agents W01–W14；需要从 Cursor、Claude 或 VS Code 访问 Harness 资源，进入 MCP Server M01–M14；需要先理解模型、工具、状态和连接层，完成 Agent Harness H01–H12。