【Agent】从Prompt工程、Context工程到 Harness工程，让 AI 能真正完成工作

【Agent】从Prompt工程、Context工程到 Harness工程，让 AI 真正完成工作

文章目录

[【Agent】从Prompt工程、Context工程到 Harness工程，让 AI 真正完成工作](#【Agent】从Prompt工程、Context工程到 Harness工程，让 AI 真正完成工作)
- 一、三种工程视角：解决不同问题
- - [1. Prompt 工程：明确任务目标与执行要求](#1. Prompt 工程：明确任务目标与执行要求)
  - [2. Context 工程：组织可检索、可复用的任务信息](#2. Context 工程：组织可检索、可复用的任务信息)
  - [3. Harness 工程：连接知识、行动与验证反馈](#3. Harness 工程：连接知识、行动与验证反馈)
  - [4. 三种工程视角的适用范围](#4. 三种工程视角的适用范围)
- [二、Harness Engineering 的职责边界及其与 FDE 的关系](#二、Harness Engineering 的职责边界及其与 FDE 的关系)
- - [1. 通用 Agent 与业务 Harness 的关系](#1. 通用 Agent 与业务 Harness 的关系)
  - [2. 先划清结果边界与控制边界](#2. 先划清结果边界与控制边界)
  - [3. 运维 Agent 的任务委派与自主执行](#3. 运维 Agent 的任务委派与自主执行)
  - [4. 与 FDE 的关系](#4. 与 FDE 的关系)
- 三、业务闭环：如何设计业务流程
- - [1. 选择具体任务并明确完成条件](#1. 选择具体任务并明确完成条件)
  - [2. 将知识、方法与任务记录分别组织](#2. 将知识、方法与任务记录分别组织)
  - [3. 工具执行与系统约束](#3. 工具执行与系统约束)
  - [4. 灵活排查与任务状态恢复](#4. 灵活排查与任务状态恢复)
- [四、实践：处理一次 GitOps 发布故障](#四、实践：处理一次 GitOps 发布故障)
- - [1. 场景与任务目标](#1. 场景与任务目标)
  - [2. 收集证据并形成可核验的判断](#2. 收集证据并形成可核验的判断)
  - [3. 修正配置并保持 GitOps 期望状态一致](#3. 修正配置并保持 GitOps 期望状态一致)
  - [4. 验证部署状态与业务恢复结果](#4. 验证部署状态与业务恢复结果)
  - [5. 保存可追溯、可复用的任务记录](#5. 保存可追溯、可复用的任务记录)
- 五、持续迭代：让经验成为可复用的能力
- - [1. 区分任务内调整与跨任务改进](#1. 区分任务内调整与跨任务改进)
  - [2. 明确复盘结果的沉淀方式](#2. 明确复盘结果的沉淀方式)
  - [3. 在 Skill 中明确适用条件与判断方法](#3. 在 Skill 中明确适用条件与判断方法)
  - [4. 通过反例评测验证方法的适用边界](#4. 通过反例评测验证方法的适用边界)
  - [5. 从任务交付逐步扩展到持续运行](#5. 从任务交付逐步扩展到持续运行)
  - 资料说明

在 Codex 会话（session）中提供服务拓扑、部署配置、排障手册和历史故障记录，可以减少任务执行前的重复背景说明。通过合理组织这些资料，Agent 能够基于业务上下文开展分析与故障排查。

进一步的目标是建立完整的任务执行机制：Agent 接收任务后，能够自主查询状态、选择方法、调用工具并验证结果；遇到异常时调整方案，任务结束后保存记录，并将经过验证的经验沉淀为可复用的 Skill。

这也是 Harness Engineering 在业务场景中的重要方向：围绕通用 Agent 构建工作系统，使其能够持续承担明确的业务职责。本文以运维场景为例，分析 Prompt、Context 与 Harness 的关系，并通过发布故障处理案例说明任务执行、恢复验证与经验复用的完整过程。

一、三种工程视角：解决不同问题

1. Prompt 工程：明确任务目标与执行要求

**Prompt Engineering（提示词工程）**是通过设计任务指令、约束、示例和输出要求，引导模型完成特定任务的工程活动。

例如："排查这次发布失败的原因，列出证据和建议；可以查询生产状态，变更操作需要审批。"这段 Prompt 交代了目标、交付物和行动范围。

Prompt 也可以经过系统化设计，形成长期规则或操作指导。从模型输入的角度看，Prompt 本身也是上下文的一部分。因此，将其理解为"不成体系的 Context"并不准确。两者的区别主要在于工程关注点：前者侧重表达任务要求，后者侧重组织完成任务所需的信息。

如果每次任务都需要人工重新说明服务关系、补充背景和提示操作步骤，就说明大量业务知识仍依赖个人经验与临时对话，尚未形成可复用的知识资产。

2. Context 工程：组织可检索、可复用的任务信息

**Context Engineering（上下文工程）**是围绕任务，组织、检索和提供模型所需的指令、事实、工具说明及当前任务状态的工程活动。

将运维知识整理为 Agent 可按需读取的文件，是上下文建设的一种实现方式。保存服务归属、部署路径、故障手册与历史决策，有助于在新的会话中复用这些信息，减少重复沟通。

上下文工程与 RAG 都涉及获取相关信息，以支持模型完成任务。RAG 是实现上下文供给的一种方式；文件搜索、入口导航和按需读取也可以承担相应职责，向量数据库并非必要前提。

文件可访问并不意味着其内容已经进入模型上下文。目录组织还应支持资料定位、适用范围判断与版本有效性识别。与缺少索引的文档集合相比，清晰的知识入口更有利于信息检索和使用。

运维场景还需要区分长期知识与实时事实。服务拓扑可以通过资料获取，当前运行版本、Pod 状态和错误率则需要查询实际系统，并记录查询时间与数据来源。历史故障记录不能直接作为当前集群状态的证据。

3. Harness 工程：连接知识、行动与验证反馈

**Harness Engineering（驾驭工程）**是围绕智能体执行任务，设计上下文供给、工具接口、执行控制、行动权限、验证反馈和异常恢复机制，使其在约束下产生可验收结果的工程活动。

例如，Agent 读取排障手册后，需要通过工具查询日志和部署状态；提出修复方案后，需要获得相应授权；执行完成后，需要验证问题是否解决。当查询失败、执行超时或证据冲突时，系统还应支持后续决策，避免在缺少验收依据时结束任务。

任务结束后的记录、复盘与经验复用，可以进一步完善工作系统。这些能力是业务 Harness 的重要建设方向，但并非所有 Harness 都必须包含的固定模块，也不能仅通过引入框架自动获得。

4. 三种工程视角的适用范围

工程视角	主要解决的问题	运维场景中的体现
Prompt 工程	要做什么，如何表达要求	明确排查目标、交付要求和限制
Context 工程	依据什么信息工作	获取服务资料、配置、实时状态与历史经验
Harness 工程	怎样行动、纠错并确认完成	查询工具、授权执行、恢复验证、异常接管

对于由 Agent 承担运维任务的目标，Harness 覆盖的工程范围更广，将上下文供给与行动、反馈机制连接起来。可靠的 Harness 仍依赖高质量的 Context，资料组织与目录治理不会因工具能力的增加而失去价值。

对于配置解释等分析任务，清晰的 Prompt 与 Context 可能已经足够；对于涉及集群状态变更与恢复确认的任务，则需要相应的执行闭环。工具数量和执行轮次的增加，并不必然提升任务完成质量。

二、Harness Engineering 的职责边界及其与 FDE 的关系

1. 通用 Agent 与业务 Harness 的关系

按照上述定义，Codex 已提供文件操作、工具调用等通用运行机制。构建运维 Agent 时，可以在这些能力之上完善业务知识、工具连接、工作方法与验收机制。

需要明确的内容包括服务范围、可信状态来源、方法适用条件、操作权限、恢复标准与人工接管路径。这些信息和机制共同决定 Agent 能否承担相应的业务职责。

"运维 Agent"可以理解为通用智能体在特定职责、知识、工具和运行规则下形成的业务执行者。 业务能力既来自模型，也来自围绕它建设的工作环境。

工具连接是其中的关键环节。掌握监控查询方法不等于具备监控访问能力，了解回滚命令也不等于具有回滚授权。工作方法、可调用接口与身份权限需要相互匹配。

2. 先划清结果边界与控制边界

对于同一类发布告警，任务目标可以是整理证据、形成处置方案，或在授权后实施修复并确认恢复。不同目标对应不同的验收标准与执行机制。

结果边界界定系统的交付范围。交付排查报告时，需要核验结论和证据；交付恢复结果时，还需要核验目标版本、资源健康状态与业务指标。

控制边界界定系统可执行的操作及其作用范围。例如，Agent 可以读取生产日志，但仅能在 Git 中提交配置草稿；也可以发起部署，但不具备变更审批权限。这些限制体现了不同环节的职责划分。

承担结果交付职责，并不意味着能够直接控制所有环节。等待审批、等待外部处理与人工接管，都应成为可识别的任务状态。系统需要保留任务进度、阻塞原因与交接材料，而非将所有未完成情况统一标记为"执行失败"。

3. 运维 Agent 的任务委派与自主执行

可以参照职责与权限明确的运维岗位设计任务委派方式：明确目标，提供知识入口与工具，允许 Agent 在授权范围内自主选择排查方法，并依据结果验收。

这种委派方式需要相应的工程支撑：跨会话信息应保存为可读取的持久化资产；生产权限应通过身份与工具落实；执行记录应可追踪；任务恢复前应重新核对当前状态。仅依赖对话中的记忆要求，无法建立可靠的持续工作能力。

持续值守还需要告警或定时任务触发、任务调度与异常接管机制。创建会话或编写 Skill，并不等于建立持续运行的服务。

Agent 的自主性可以体现在排查路径的选择上。例如，在证据不足时继续查询依赖状态，无需对每一步只读检查进行人工确认。但日志和工单属于待分析数据，其中的内容不能作为变更系统权限的依据。

4. 与 FDE 的关系

FDE 通常指 Forward Deployed Engineer，即前线部署工程师，典型工作是进入业务现场，把模糊问题变成可落地方案。具体职责因组织而异。

比较维度	FDE	Harness Engineering
起点	业务现场的问题与约束	智能体的执行能力与可靠性
主要工作	澄清需求、接入系统、调整流程、验证价值	组织上下文、设计工具与控制、建立反馈
二者关系	可能需要为业务设计 Harness	可以成为 FDE 交付方案的一部分

在运维场景中，理解团队的发布机制、故障处置流程与变更责任分工，并将这些约束落实到 Agent 的工具和流程中，体现了二者的交集。FDE 是岗位与交付方式，Harness Engineering 是工程活动，两者不能直接等同。

三、业务闭环：如何设计业务流程

1. 选择具体任务并明确完成条件

"运维 Agent"涵盖的职责较广，更适合作为建设方向。初期应选择边界明确的任务，例如"排查 Kubernetes 发布后新容器启动失败，并在授权后修复配置、验证恢复"。

任务输入应包括目标环境、集群、命名空间、服务、异常发生时间与对应发布。完成条件则应包括：证据足以支持原因判断；授权变更已体现在预期修订中；部署与业务检查通过；未完成事项有明确的交接安排。

这些约定可以构成任务契约，但未必需要单独设计配置格式。初期可以采用明确的任务说明，结合现有系统的权限控制与验收检查建立执行规范。

需要区分"命令执行成功""资源状态健康"与"业务已经恢复"。三者对应不同层次的证据，不能相互替代。

2. 将知识、方法与任务记录分别组织

以下是一种工作区组织示例，实际实施时可结合现有仓库和目录结构调整：

text 复制代码

ops-agent/
├── AGENTS.md                         # 职责、知识入口、工作边界
├── knowledge/
│   ├── services/                     # 服务关系、负责人、部署入口
│   └── runbooks/                     # 经验证的操作手册
├── .agents/skills/
│   └── release-incident/SKILL.md      # 发布故障处理方法
├── tools/                            # 已有脚本或工具适配
├── incidents/                        # 每次任务的状态、证据与行动
└── evals/                            # 用于检验方法的案例

其中，AGENTS.md 承载项目指令；.agents/skills 是 Codex 可发现项目 Skill 的约定位置。其他目录名称仅用于说明组织方式，将脚本放入目录并不意味着已完成工具接入。

知识目录描述业务结构与运行背景，Skill 定义特定任务的处理方法，任务记录保存单次执行的状态与事实。三类信息采用不同的更新方式：服务资料随业务变化维护，Skill 经验证后更新，任务记录则随执行过程持续追加。

知识入口应保持简洁，明确职责、资料位置、需授权的操作与任务结束时的证据要求。详细资料按需读取，避免在入口集中堆积规则，增加维护成本。

3. 工具执行与系统约束

初期可以复用现有监控查询、日志检索、Kubernetes、Git 和发布工具。工具应返回足以判断下一步的信息，包括目标对象、查询时间、当前状态和明确的错误原因。

只读查询与生产变更应有不同的授权范围。变更授权需要对应具体对象和动作，例如目标集群、应用、配置差异或修订；不能把一次批准理解为长期允许任意操作。

模型适合整合证据、提出假设并选择后续检查。目标范围、授权验证与版本匹配等可通过确定性规则执行的约束，应由工具或服务端落实。

配置校验、发布检查与权限验证等确定性工作，可以继续由现有程序执行，避免在每次任务中依赖模型重新解释规则。Skill 可以指导 Agent 调用这些能力，但不能替代系统层面的强制约束。

4. 灵活排查与任务状态恢复

一个任务可以经历"收集证据、形成方案、等待授权、执行、验证、完成或交接"等阶段。阶段之间需要明确条件，但阶段内的排查路径可以由 Agent 根据反馈调整。

运行机制将工具结果返回给模型，驱动后续轮次；任务规则决定何时继续、等待或结束。一个简化的循环如下：

text 复制代码

任务触发 → 读取任务状态和相关知识 → 模型选择下一步
                                      ↓
                                   调用工具
                                      ↓
                            保存结果并检查完成条件
                                      ↓
                         继续排查 / 等待或交接 / 完成

任务进入下一轮排查时，模型可以根据反馈调整方法。任务完成需要有相应的验收证据；出现权限不足、达到任务时限，或多次操作未获得新证据等情况时，应进入等待或交接状态，避免无效循环。Codex 提供通用执行机制，业务 Harness 则需要补充任务规则与状态管理。

任务记录至少应保存目标、当前阶段、证据引用、已执行操作与后续计划。进程中断后，应先读取记录并查询实时状态，确认已有操作的生效情况，再决定如何继续执行。

工具超时仅表示未在规定时间内收到结果，不能据此判定操作未执行；重复告警也不一定对应新的故障。持续运行的系统需要识别同一任务，并在写操作前进行重复与冲突检查。单纯增加执行循环无法替代这些机制。

四、实践：处理一次 GitOps 发布故障

1. 场景与任务目标

假设 checkout-api 通过 Argo CD 部署。发布后新 Pod 反复重启，部署更新持续未完成；此时旧版本仍可能正常提供服务，不能仅根据新 Pod 异常判定整体服务不可用。

本例目标是定位启动失败原因，在批准后修正配置，并确认预期版本和服务状态。下文的环境、名称、日志及修订均为示例，真实目标必须从任务和权威系统取得。

2. 收集证据并形成可核验的判断

Agent 首先读取服务的部署入口和故障手册，再使用只读工具查询 Deployment、Pod 与异常日志。例如：

bash 复制代码

kubectl --context prod-a -n payments get deployment checkout-api -o yaml
kubectl --context prod-a -n payments get pods -l app=checkout-api
failed_pod="<已确认的异常Pod名称>"
kubectl --context prod-a -n payments logs "$failed_pod" -c app --previous --tail=100

这里假设服务使用上述标签和容器名，failed_pod 需要填入查询确认的异常 Pod 名称。--previous 用于读取上一实例的容器日志，适合已经发生重启的情况；没有上一实例时，应根据实际状态查询当前日志或事件。

查询之后，假设取得以下证据：

新 Pod 反复启动失败，旧 Pod 尚在运行。
失败日志提示缺少 PAYMENT_ENDPOINT，记录中保留日志来源和时间。
这次 Git 配置差异把变量名改成了 PAYMENTS_ENDPOINT。
对应发布版本的应用启动配置仍然要求 PAYMENT_ENDPOINT。

这些证据共同支持"配置变量名与应用要求不一致"的判断。发布时间与告警时间接近，不足以单独证明二者存在因果关系；发现变量名差异后，也需要核对实际发布版本与配置是否匹配。

在这一过程中，知识目录提供业务背景，工具获取实时事实，模型整合证据并建立关联，从而将上下文供给连接到任务执行。

3. 修正配置并保持 GitOps 期望状态一致

核对代码与配置后，如果确认变量重命名有误，Agent 可以提出以下最小修正差异：

diff 复制代码

-- name: PAYMENTS_ENDPOINT
+- name: PAYMENT_ENDPOINT

方案应说明目标环境、文件位置、适用版本和验证方法，并经既有变更流程批准。批准后将修正合入 Git，再由发布流程使集群达到预期修订。

对于 GitOps 管理的资源，变更需要与 Git 中声明的期望状态保持一致。如果仅直接修改集群，启用自动同步及自愈的 Argo CD 可能将资源恢复为 Git 中的配置。因此，处置过程必须遵守团队的 GitOps 与应急变更流程。

Skill 应指导 Agent 检查实际同步策略、期望修订与当前资源，避免仅根据历史处置结果复用直接修改集群的操作。若团队允许应急修改，还应记录运行状态与 Git 期望状态之间的偏差，并按流程完成后续协调。

4. 验证部署状态与业务恢复结果

修正生效后，需要核对 Git 和 Argo CD 的预期修订，再检查当前 Deployment 的 rollout：

bash 复制代码

kubectl --context prod-a -n payments rollout status deployment/checkout-api --timeout=120s

该检查用于确认部署更新是否完成，但仍需核对当前部署是否对应本次目标修订。如果期间发生其他发布，原任务的判断依据与授权范围可能需要重新确认。

随后检查新 Pod 的就绪状态与重启情况，并按照服务既有标准观察错误率、延迟或业务探测结果。观察窗口与通过条件应在任务中明确，不能仅依据单次正常响应判定恢复。

当相应证据成立时，本例可以形成如下结论："配置修正对应的部署已经完成，启动错误消失，约定业务检查通过。"如果部署完成但业务指标仍然异常，则应继续排查或交接，不能据此报告服务已完全恢复。

5. 保存可追溯、可复用的任务记录

任务记录应简明，并覆盖关键事实：

text 复制代码

目标：排查 checkout-api 本次发布启动失败
阶段：恢复验证完成
原因：发布配置变量名与对应版本的应用要求不一致
证据：日志、配置差异、应用要求、修订与监控记录的引用
行动：按批准差异修正 Git 配置，经发布流程生效
验证：目标部署完成，启动错误消失，约定业务检查通过
遗留：检查发布前是否已有环境变量契约校验

记录中的"完成"只能在相应证据成立后填写。保存证据引用和必要摘要即可，不必复制全部生产日志或敏感配置。

如果工具连接在执行后中断，恢复任务时应先核对 Git、发布状态和当前资源，确认修正是否已生效，再继续验证。任务记录帮助恢复进度，实时系统决定当前事实。

五、持续迭代：让经验成为可复用的能力

1. 区分任务内调整与跨任务改进

任务内调整是指在执行过程中，根据新增证据修正假设、调整检查顺序或修改方案。这类迭代依赖工具反馈、状态记录与明确的停止条件。

跨任务改进是指将有效经验保存为知识、Skill、检查脚本，或用于改进工具，供后续任务复用。这类迭代需要持久化资产与验证流程，不能依赖会话始终保留完整历史。

上述改进主要作用于外部工作系统，并不意味着模型通过权重更新学习了相关经验。单次任务成功也不足以证明相应方法具备普遍适用性。

2. 明确复盘结果的沉淀方式

本例可以从以下三个方面形成改进。

业务知识更新： 补充服务的环境变量要求及适用版本，为后续任务提供准确的业务背景。

工作方法更新： 将"启动日志、发布差异、应用要求交叉核对"整理为可复用 Skill。

确定性检查： 如果应用已有环境变量契约，可在发布检查中验证缺失项，提前发现同类问题。对于能够由程序稳定检查的规则，应优先采用确定性校验。

复盘应先识别重复失败的根因，再确定需要更新的资料、方法、工具或检查机制，避免直接将完整对话转化为 Skill。候选经验可以保存在复盘或评测区域，经过验证后再纳入可被自动调用的资产。

3. 在 Skill 中明确适用条件与判断方法

以下为候选 Skill 的简化示例，用于说明方法提炼方式，不代表完整的生产实现：

markdown 复制代码

---
name: diagnose-release-env-mismatch
description: 用于发布后容器启动失败且日志提示缺少环境变量的排查；不用于一般网络超时、容量或节点故障。
---

# 发布后环境变量缺失排查

1. 确认环境、服务、失败 Pod 与对应发布版本。
2. 取得失败容器日志，并记录来源和时间。
3. 对照发布配置差异与该版本应用的环境变量要求。
4. 只有证据匹配时，提出针对性的配置修正。
5. 遵守 GitOps 和变更授权流程，不绕过审批直接修改生产。
6. 核对目标修订、部署状态与约定业务检查，记录结果。
7. 证据不匹配时转入其他排查路径；权限不足时交接。

Skill 应重点沉淀可复用的判断过程，避免将方法绑定到固定变量名或单次命令。清晰的触发说明有助于 Agent 判断适用范围，降低 Skill 数量增加后出现误调用的风险。

4. 通过反例评测验证方法的适用边界

候选 Skill 的评测应覆盖相似症状、不同根因与执行边界，避免仅通过重放单次成功案例判断其有效性。

评测案例	应观察的行为
变量确实缺失，配置与应用要求不一致	能提出有证据的针对性修正
同样发生重启，但原因是依赖连接超时	不强行套用变量缺失结论
有修复依据，但缺少生产变更授权	保留方案，等待授权或交接
上次行动已生效，任务因断线再次恢复	先核对状态，不重复执行变更

验证通过后，应按团队流程启用并记录版本。工作方法更新不应隐含操作权限的扩大；新版本表现下降时，应支持恢复至已验证的版本。

还应通过真实任务评估新方法能否减少重复检索、人工背景补充与判断错误。能力改进需要可比较的案例或运行记录支持，复盘文档本身不能作为效果提升的依据。

5. 从任务交付逐步扩展到持续运行

初期可以从知识入口与只读排查开始，使 Agent 能够独立收集证据并形成可核验的判断。随后接入既有的变更授权与验证流程，形成特定任务的完整执行闭环。

在任务能够可靠完成或交接后，再引入告警触发、任务持久化与调度机制，支持持续运行。同时依据实际任务记录维护经过验证的 Skill，持续完善工具能力与检查机制。

在这一体系中，人负责确定目标、配置权限并承担最终责任，Agent 则在规定范围内自主开展分析与执行。可复用的知识、可信工具、可恢复的任务状态与经过验证的方法，共同支撑 Agent 持续承担业务职责。

资料说明

本文采用面向业务执行的 Harness 定义，运维案例与目录结构为设计示例。经验沉淀流程是工程建议，并非某个产品自动具备的完整能力。

OpenAI 官方文档：AGENTS.md：项目指令的发现与分层。
OpenAI 官方文档：Agent Skills：可复用工作流程与按需加载。
Kubernetes：调试运行中的 Pod与Deployment：日志查询与部署完成检查。
Argo CD：Automated Sync：自动同步与自愈行为。