Harness 工程：给跑得快的 AI 建一圈围栏

Harness Engineering：从概率智能到可靠系统

图 1：模型提供能力上限，Harness 决定这份能力能否可靠进入真实工作。

前记：上周参加了公司内部组织的关于 AI 驱动软件开发的培训，虽然只有一天时间，来自某大厂的讲师还是把「如何通过多智能体协同的方式，把 Harness Engineering 体系化落地」讲得七七八八。对于处在运维部门的工具开发来说，这套体系化的东西有点重，但我还是觉得收获很大——起码明白了大厂是怎么把 Harness 真正落到 AI Coding 里去的。

Harness 这个概念提出来已经好几个月了，我一直没细研究，只知道 Claude Code 是践行 Harness 的典范，自己也一直在用 cc。趁着这次机会，我把 Harness 到底是什么、除了 coding 之外对其他领域有没有帮助，好好深扒了一遍。本文就是我这一轮调研和学习的整理总结。

顺带一个体感：同样的大模型，Claude Code 用起来比 Opencode 好太多了。

一、Prompt、Context、Harness：一层套一层的三个圈

先把三个词的关系理顺，它们不是并列的三个流派，而是一层套一层的三个圈：

• Prompt Engineering 关注的是「我该怎么对模型说」，本质上是在优化单次调用里的指令表达；
• Context Engineering 往外扩了一层，关注的不再是 prompt 本身，而是模型在当前时刻「能看到什么信息」——历史对话、检索结果、工具返回、任务状态、工作记忆都被纳入进来，prompt 只是 context 的一个组成部分；
• Harness Engineering 又再往外扩了一层，它关心的已经不是「输入给得对不对」，而是模型在真实执行过程中，是否被一个完整系统持续约束、观测、纠偏和收敛。所以 context 也只是 harness 中的一部分。

很多技术趋势看上去像观点之争，实际上是任务复杂度逼出来的：

• 当任务简单时，Prompt 就够了；
• 当任务复杂到上下文不够用时，Context 成为核心；
• 当任务变成需要持续执行、长链路、低容错时，Harness 几乎不可避免。

Prompt、Context 与 Harness 的嵌套关系

图 2：Prompt 解决“怎么说”，Context 解决“看见什么”，Harness 解决“在什么系统里行动”。

二、Harness 的内核：把不确定的模型，关进确定的系统

一句话概括：把一个非确定性的模型，放进一个尽量可控、可观测、可复盘的系统。 这就是 harness engineering。凡是任务复杂度超过单个上下文窗口能稳定承载的场景，都开始需要类似 harness 的设计。

Harness 的来源和隐喻

Harness 这个词本身也很有意思。它最早在英语里和盔甲有关，后来变成马具，再后来发展出「驾驭某种力量为我所用」的意思。人类先是试图控制战场上的危险，后来控制马，再后来控制水力、蒸汽、电力。每一次都是同一种动作：

遇到一种比自己更强、更快、更不可预测的力量，然后想办法把它变成可用的生产力。

现在轮到 AI。所以 harness 这个词流行起来不是偶然，它暴露了 AI 工程师面对新一代智能体时的真实心理：这东西太能干了，我得想办法让它在正确的轨道里能干。不是因为大家突然喜欢一个新词，而是因为模型已经强到值得给它建围栏了。

围栏是给跑得快的马用的。跑不起来的马，不需要围栏。 早期模型的主要问题是跑不远、跑不稳，你还没来得及担心它失控，它自己已经卡住了。但当模型能连续跑半小时、几个小时，甚至跨多个上下文窗口接力完成任务时——它能创造的价值变大了，能犯的错误也变多了。

这时真正的问题不再是「让它更聪明」，而是：

• 它应该看见什么？
• 它能调用什么工具？
• 它不能碰什么？
• 它做完之后怎么知道自己错没错？
• 它连续失败几次之后，什么时候该交还给人？

这些问题加在一起，就是 harness engineering。

三个概念的干净切分

Harness 是模型之外的一整套运行环境。它决定 AI 能看到什么、能做什么、不能做什么、做完后如何验证、出错后如何修正、什么时候交还给人。

这个定义看起来有点长，但它能把三个概念干净地区分开：

• Prompt 是你对 AI 说什么。
• Context 是 AI 当下看见什么。
• Harness 是 AI 被放进了一个什么样的行动系统。

有人把这件事概括成一个非常简单的公式：

Agent = Model + Harness

这个公式听起来像口号，但有一组硬数据能把它钉死。MBZUAI 的 VILA-Lab 拆过 Claude Code v2.1.88 的源码（1,884 个文件、约 51 万行 TypeScript），结论是：只有 1.6% 是 AI 决策逻辑，其余 98.4% 都是运行时基础设施——权限门、上下文管理、工具路由、恢复逻辑。换句话说，你以为在用一个「聪明的模型」，实际上绝大部分工程量花在了模型外面那圈围栏上。

更直接的证据是「同一个模型、只换 harness」的对照：固定模型不动，仅迭代改进 harness，deepagents-cli 在 Terminal-Bench 2.0 上从 52.8 分提升到 66.5 分（+13.7），排名从 30 名开外冲到第 5；SWE-bench Pro 上同一个 Claude Opus 模型套三套不同 Agent 系统，得分能差出 5 个点。有分析甚至认为 harness 相比裸模型对输出质量约有 2 倍影响。一句话：模型是天花板，harness 是够到天花板的那把梯子。

顺着这个思路，可以把一个完整的 harness 分层拆解成四层：

1. 指令层：给 AI 一张地图，不是一本手册；
2. 上下文层：AI 只能理解它看得见的东西；
3. 边界层：先设计「爆炸半径」，再谈自由度；
4. 反馈层：AI 需要感受到现实，才知道自己错没错。

长任务的「换班交接」

长任务跑到第三小时，AI 失忆怎么办？Anthropic 的方案不是简单换更大窗口，而是设计了一个更像「换班交接」的 harness：先由一个初始化智能体把任务拆清楚，写出需求、任务列表和进度文件；后面的编码智能体每次只推进一小部分，并且留下清楚的交接记录。新会话不是去读一大段压缩过的聊天记录，而是读结构化的进度文件。

这个设计很像人类工程师接手项目：先看 README，读任务列表，看 git 历史，再继续干。

长任务的核心不是记住所有历史，而是留下足够清楚的交接物。

三、AI Coding：一线大厂如何把 Harness 体系化落地

这也是公司组织培训的核心内容，讲的是某一线大厂关于体系化落地 Harness 的具体实践。它的整条主线可以概括为：

Spec 目标契约 → 代码知识地图 → 多智能体执行 → 质量独立验收 → Memory 沉淀防线

用一句话记住这五者的关系：Spec 是目标契约，知识地图是空间坐标，多智能体是执行组织，质量体系是裁判系统，Memory 是进化机制。

AI Coding 的 Harness 交付闭环

图 3：五个模块不是功能清单，而是一条从目标定义到经验反哺的闭环。

1. Spec 规约：把自然语言需求变成可执行契约

普通需求描述容易目标含糊、边界遗漏、实现与验收口径不一致。Spec 的作用，是把「用户想要什么」改写成 AI、开发、审查、测试共同使用的行为契约。培训材料用的是接近 OpenSpec 的表达：Requirement 用 SHALL 描述必须具备的行为，Scenario 用 Given-When-Then 描述条件-动作-结果，再配 Success Criteria 和 Spec Delta（ADDED / MODIFIED / REMOVED）。

TEXT

Requirement R-001：系统 SHALL 支持商品排序。
Scenario S-001：
  GIVEN 用户位于商品首页
  WHEN  用户选择「价格从低到高」
  THEN  商品列表按价格升序排列

关键不是格式，而是可验证性：行为明确（只描述外部可观察行为）、边界完整（正常/异常/默认值/权限/极端条件都写到）、验收可映射（每条 Scenario 能直接变成单测或 E2E）、变更可追溯（需求、设计、审查、测试始终用同一组 R-xxx/S-xxx 编号）。.harness/specs/ 是系统当前能力的 Source of Truth，新任务先读主 Spec，交付后再把 Delta 合入主 Spec，形成持续更新的能力基线。

2. 代码知识地图：给 Agent 一张经过工程提炼的系统地图

只让 Agent 自己读源码是不够的——源码提供局部事实，但不天然表达模块边界、职责划分、数据流、调用链和「某类改动通常要同步哪些位置」。Agent 直接搜代码，容易找到「相似位置」，却漏掉真正的跨层影响。

所以要额外维护一份架构级认知：overview（技术栈/目录/关键命令）、后端架构、前端架构、依赖说明、dev-recipes（新增 API/页面/字段的常见改动配方）。而且按角色加载、而不是全量灌入：BA 只读 overview 保持业务视角，SA 读架构 + 依赖做影响分析，Dev 再加 dev-recipes，TE 原则上不读知识地图、以免被实现思路污染。按需加载既省上下文，也是一种职责隔离。

3. 多智能体协同：专业分工、上下文隔离、相互制衡

拆分 Agent 不是为了人数多，而是为了三件事：专注（每个 Agent 只带本阶段需要的上下文）、制衡（生成者、审查者、验收者相互独立）、可追责（每阶段有明确输入、输出、阻塞条件和产物文件）。培训里落地成七个角色：

整条流程由状态机驱动，而不是靠 Agent 自己说「我做完了」：

TEXT

/harness-propose   BA → SA → RR → 人工审批①
/harness-apply     Dev → Hook → CR → TE → Hook/门禁 → 人工审批②
/harness-archive   Spec Merge → Memory Merge → 证据归档 → board DONE

协同铁律里我印象最深的一条：写代码的人不能判自己合格，判合格的人不能顺手改代码。 下游发现上游有问题，只能 BLOCK/REJECT，不得偷偷改上游制品。

4. 质量管控：从「相信 Agent」转为「相信证据」

质量体系针对的是四类结构性缺陷：规则遗忘（上下文变长后漏读要求）、约束规避（用「特殊情况」绕流程）、自审失效（生成者天然认为自己对）、虚报完成（没真跑验证就宣布做完）。对应四层防线，越往下约束越硬：

Rule 可能被忽略，Skill 可能被跳步，但脚本退出码和 Hook 结果不能靠语言解释绕过。质量结论必须可复核——合法证据是命令输出、测试报告、脚本退出码、baseline 差异、浏览器截图，单独写一句「tests passed」没有任何证明力。

5. Memory：让一次失败变成永久防线

Rules/Skills/Workflow/Scripts 是初始化时设计的静态防线，Memory 是运行中持续增长的动态层。它记录的不是流水账，而是跨任务仍然有价值的工程经验：CR 打回后修好的可复用问题、TE 发现并修复的实现级缺陷、连续踩了两次以上的环境/流程陷阱。每条建议写成五段式——症状、根因、修复、防复发措施、复发检测。

Memory 的价值不在「写了」，而在防线是否落地。真正成熟的 Memory 最终会往外流：可机械检查的经验下沉为测试或 verify 检查项，可重复执行的流程下沉为 Skill，稳定的团队红线上升为 Rule，架构事实回写代码知识地图。这才形成「踩坑一次，系统升级一次」。

培训里最值得强调的三个结论：①Harness 的本质是把概率性智能包进确定性工程流程；②约束不是自主性的反面，而是自主性的前提；③可靠交付必须形成闭环——需求能映射测试、代码能映射架构、结论能映射证据、失败能映射新防线。

四、从写代码到管生产：Harness 在智能运维的迁移

Harness 并不只属于写代码。研究、客服、数据分析、运维、交易，都是它的用武之地。

先说一个非编码的例子：Anthropic 的 Research（深度研究）功能。它要做的是拆问题、查资料、比较来源、生成带引用的报告。做法是用一个主智能体拆解问题，再创建多个子智能体并行搜索——每个子智能体都有明确目标、输出格式、工具范围和任务边界，独立探索后把结果压缩成摘要交回主智能体。主智能体拿到的是干净摘要，而不是一堆原始网页。这再次说明：子智能体的价值不只是分工，更是上下文隔离。

而这里最重要的，不是「智能体很聪明」，而是流程被拆成了两类节点：智能体节点负责需要判断和生成的部分，确定性节点负责检查、提交、测试、拦截。这就是企业级 harness 的关键——

自由度只留给真正需要推理的地方，其他地方交给确定性系统。

从 AI Coding 迁移到智能运维：我最关心的部分

作为运维部门的工具开发，我特别研究了 Harness 往 AIOps / SRE 迁移的问题。结论是：智能运维里的 Harness 价值，不是让大模型「更会排障」，而是为 Agent 建立一套可控的生产运行体系，让它能在真实基础设施上安全地取信息、下判断、提动作，并接受持续验证、止损、回滚和审计。它天然分成两层：

• Agent Harness：约束 AI 如何推理、调用工具、管理上下文、协作和执行；
• Operations Harness：约束真实生产变更如何预检、审批、发布、观测、止损、回滚和留痕；
• 而在两者之间，还有一层容易被忽略的诊断 Harness——它约束的是「怎么把开放式模型推理，变成可解释、可评估、可持续改进的诊断过程」。快手的 RCA Agent 实践就是这一层的典型（下面细讲），它的当前重点是辅助诊断，还没有直接去动生产变更。

三层结合，才是可用的智能运维系统。而且必须承认——智能运维比 AI Coding 更需要 harness，因为两者的风险根本不是一个量级：

智能运维中的三层 Harness

图 4：Agent Harness 管 AI 怎么工作，诊断 Harness 管结论怎么可信，Operations Harness 管生产怎么安全变化。

一个关键差别：Coding 里「测试通过」是强信号，运维里「告警消失」却可能来自采集故障、阈值变化或流量下降，并不必然说明服务恢复。所以不能把「测试通过」直接换成「告警消失」，也不能默认所有生产动作都能安全回滚。

迁移的核心是「换零件」，不是换范式

AI Coding 那套 harness 的每个部件，在运维里都有对应物：

落地时几个我觉得最能抓住要点的机制：

权限必须分级。 原则是「模型决定尝试什么，权限层决定是否允许，工具层决定如何安全执行」。L0/L1 只读可自动执行；L2 生成建议但必须留痕；L3 dry-run、可逆动作；L4 生产写操作默认需人工审批；L5 删除、数据变更、跨区域切换要强审批甚至禁止 Agent 执行。

角色隔离照搬 Coding 那套。 Triage / Diagnosis / Remediation Planner / Executor / Verifier / Audit / Incident Commander——提出方案的 Agent 不该同时审批方案，执行动作的 Agent 不该独立判定自己成功。已知故障走 SOP，未知故障才用 ReAct 式开放探索，二者共存。

验证要多层，判定只留四种。 反馈信号弱，就得从动作验证、状态验证、服务验证、用户 SLO、回归验证、时间验证多个角度交叉确认；而最终结论统一收敛成四个动作：Continue / Pause / Rollback / Escalate。所有结论都必须有可复核证据。

一个落地样本：快手 RCA Agent 的「诊断 Harness」

上面都是方法论，正好看到快手《复杂业务场景下 RCA Agent 的探索实践》，把「诊断 Harness」这一层讲得很具体，我挑几个最受启发的点。

RCA Agent 的诊断 Harness 架构

图 5：先用告警画像降噪和路由，再以业务资产、证据分级、多 Agent 与真实事故回放约束慢思考。

先看它想解决的难题——业务故障常常在常规 Trace / Metrics / Log 之间断链。快手举的例子很典型：入口请求量突然上涨，直接原因并不是入口服务异常，而是推荐质量下降导致用户反复刷新；而下游服务的兜底逻辑又把真正的异常掩盖了，最终根因落在更深层服务的一次配置变更和接口字段缺失上。技术指标看起来都正常，核心业务指标却已经变了——链路在两个节点都断了。

针对这类问题，它的 harness 有四个我觉得可以直接借鉴的设计：

① 业务资产：在源码之上再建一层认知。 让 Agent 实时读源码排障太慢（一条链路跨多个仓库和 SDK，分析要十五到二十五分钟）。所以预先把「错误码的业务含义、Metrics 与业务指标的对应、指标之间的有向影响、兜底/降级/异常隐藏路径、配置开关的影响地图」离线沉淀成业务资产。代码仍是事实源，业务资产负责降低实时诊断的认知成本——这其实就是把 AI Coding 的「代码知识地图」升级成了「业务知识地图」。

② 告警画像 + 证据金字塔：防止把「共现」当「根因」。 进 RCA 之前先给告警做画像（周期性、阈值偏离、恢复时间、服务分布、曲线聚集），把「每天定点重复、偏离稳定」的噪声挡在深度诊断之外，省下 Token 和时延。进了诊断，则按证据强度分级约束归因：

这套东西专门治一个毛病：大集群里单 Pod 抖动很常见，没有证据分级，它就会被错误关联到一堆无关的业务指标波动上。

③ 快慢路由：Agent 并不天然优于 Workflow。 已知模式走 Workflow「快思考」，拿到确定性、低延迟、低成本；只有静态 SOP 覆盖不了的复杂业务故障，才启动 Agent「慢思考」。而且慢思考本身也被工程约束住：主 Agent 维护动态 Plan 和停止条件，把八十多个工具按领域封装成 Sub-Agent 隔离上下文，耗时的代码分析走异步信箱不阻塞主循环，Sub-Agent 之间共享强线索、一个找到实锤其他就及时停止无谓下钻。

④ 真实事故 Benchmark：改 harness 要能回归评测。 新增一个工具可能修好某类 case，却拉低全局准确率。所以线上事故经专家标注后进评测集，连同故障窗口的监控快照一起保存，每次改动都让 Eval Agent 回放，对比线索命中率、归因结果、时延和成本。业务故障很难用混沌工程仿真，真实故障现场快照因此是最珍贵的评估资产。评估指标也比 Coding 更细，除了根因 Top-k 命中率，还多了「有效线索率」和「首次有效线索时间」——故障发生后多久能给人一个靠谱方向，往往比最终报告更有价值。

需要清醒的是：这套实践已经是相当完整的诊断 Harness，但还不等于处置 Harness。真要走向自动修复，前面讲的生产权限分级、人工审批、Blast Radius、动作后 SLO 验证、停止条件、回滚和审计证据，一个都不能少。

不要在「全手工」和「全自动」之间二选一

智能运维应该按场景风险逐级放权，而不是一步到位：

只读诊断是最合理的起点，而不是保守的终点。 一句话记住底线：如果无法设计出可靠的成功判定和失败止损条件，这个操作就不该进入自治。

几个必须警惕的坑：回滚并不天然可靠（K8s 回滚可能只恢复 Pod Template，数据库 Schema、Terraform State 未必对称恢复，所以回滚能力本身要测试）；弱反馈易误判（告警消失、Pod 恢复、命令返回 0 都只是局部信号）；自动化会以机器速度扩大事故（高风险自动化必须有影响半径、分批执行、Stop Condition 和人工中断通道）。还有一点提醒：现有 AI SRE 案例里不少 MTTR、降噪、准确率数据来自厂商自报，评估时应优先用自己的历史事故回放和 Shadow 数据，而不是照搬外部营销指标。

五、趋势：Harness 会「消失」，但会换一种方式活下来

Anthropic Claude Code 负责人 Boris Cherny 抛出过一句话：「Harness will disappear.」（harness 会消失。）

初听像唱衰，其实相反——Cherny 说的「消失」，是 harness 自身的胜利，不是它的终结。 它意味着 harness 把「弥补模型缺陷」那部分工作完成了，所以这部分可以收起来。而 harness 真正持久的价值——为非确定性系统设计反馈、治理、上下文、合规——会上移，不会消失。

把两种声音放到一起看就清楚了：

• Cherny 说「harness will disappear」，指的是补丁层——模型变强，会吃掉一部分今天为弥补模型能力不足而存在的工程结构；
• Osmani 说「the shift relocated friction」，指的是基础层——代码生成从来不是软件工程的瓶颈，理解、验证、维护、协作才是。而这些恰恰是 harness 的反馈层、治理层、上下文层负责的事。模型越快，这几层越重要。

所以未来真正值钱的 harness 投资，不是写更长的 AGENTS.md（那是补丁层，迟早被模型吸收），而是把反馈层、治理层、上下文层做成组织的基础设施：

测试健不健全？CI 稳不稳？code review 文化在不在？错误消息写得机器友好吗？任务状态结构化了吗？跨会话接力有没有标准协议？成本和审计有没有系统？

这些问题在 2024 年问，是软件工程的卫生标准；到 2026 年问，就是 AI 时代的护城河。模型这一层会越来越普及，但模型外面的工程基础设施，不会自动普及。Cherny 自己也承认这点——他公开的工作流里写道：CLAUDE.md 大约 100 行（行业平均 500 到 1000），每次 Claude 做错事就往里加一条，这个文件提交进 git、团队共享。

还有一个容易被忽略的辩证提醒：别把 harness 和某个模型焊死。 模型厂商往往会拿特定 harness（filesystem、bash、planning、subagent dispatch 这些动作）去协同训练，让模型在自家壳子里表现最好——这意味着「最好的 harness 不一定是模型训练时用的那个，而是为你的任务设计的那个」。所以自建 harness 要把它当成一个需要持续迭代的「活系统」，而不是抄一份配置一劳永逸。

六、最小 Harness：五个文件就能起步

聊了这么多体系化的重装方案，落到自己手上，其实可以从一个极小的闭环开始。最小 harness 的核心不只是几份文件，而是一个固定的会话生命周期：每一轮 AI 工作，都大致走开始、选择、执行、收尾这四步。

• 开始：先读规则文件，跑 init.sh，看 progress.md，读 feature_list.json，再看最近的 git 记录——先知道项目现在是否健康、上轮做了什么、还剩哪些任务；
• 选择：只选一个未完成任务，别让 AI 发散成「顺便把相关模块都重构一下」，任务太大就先拆小；
• 执行：写代码、跑验证、失败就修，关键是必须跑明确命令（typecheck、lint、test、build），而不是让 AI「感觉差不多了」；
• 收尾：更新进度日志和功能状态表，记录哪些检查通过、哪些风险没处理、哪些要人来判断，只有在项目处于可恢复状态时才提交或交给下一轮。

这个流程看起来有点笨，但它正好解决了 AI 编程最常见的几个毛病：开局不知道项目状态、中途做太多、结尾提前宣布完成、下一轮接不上。

五个文件，让一个 Agent 变可靠

这一节的最小实践，参考了开源仓库 walkinglabs/learn-harness-engineering，用一个极小的 todo 命令行工具做载体，把「最小 harness」拆成了可以直接上手的五个文件。

把「让 agent 跑得可靠」所需的结构拆开，其实只有五层，每层一个文件就足以起步：

最小 Harness：五个文件构成的可靠闭环

图 6：五个文件分别承载指令、环境、状态、范围和反馈；每层恰好消除一种常见失败。

判定标准极其简单——make check 变绿，才算做完。其中最关键的两份：AGENTS.md 用一句话说清系统是什么，然后是硬约束（MUST 收尾前跑 make check 且通过、MUST 一次只做一个 feature、MUST NOT 删改测试来让检查变绿）；feature_list.json 里 WIP=1 表示「同一时刻只能有一个进行中的 feature」，每条行为都绑定它的验证命令。

这套结构的价值，在一次对照里最清楚：把裸仓库丢给 agent 说「加个删除命令」，它没有运行说明、没有范围边界、没有要满足的测试、也不记得上次做了什么，只能靠猜；补上这五个文件后，agent 会先读 AGENTS.md，从 feature_list.json 里挑出唯一待办的 feature，写测试、把 make check 跑绿、再更新 PROGRESS.md——可复现、可续接。

关键不在文件多，而在每个文件都对应一个具体的失败。这就是「最小」的真正含义：不是省略，而是每层恰好留一个。

七、结语

把这一圈调研收拢一下，我自己最大的三点体会：

第一，Harness 的主语是工程，不是模型。 Prompt 教你怎么说，Context 决定它看见什么，而 Harness 是把一个概率性的智能体，包进一套确定性的反馈、治理和上下文系统里。「Agent = Model + Harness」这个公式很朴素，但它把责任划清楚了——模型负责聪明，harness 负责可靠。

第二，约束是自主的前提，不是它的反面。 无论是 Coding 里「写代码的人不能判自己合格」，还是运维里「没有可靠止损就不该进入自治」，讲的都是同一件事：边界越清晰、反馈越及时、失败路由越明确，你才敢把更大的自由度交给 Agent。围栏不是限制那匹马，而是让它敢放开跑。

第三，别一上来就想建大平台。 Cherny 说 harness 会消失，指的是补丁层那部分终将被模型吸收；而真正沉淀下来的，是反馈层、治理层、上下文层这些「工程基础设施」。对我们运维部门的工具开发来说，最务实的路径不是照搬那套七角色重装流程，而是先建一个只读诊断 + 独立验证的最小闭环，把 Spec、权限分级、证据留痕这几件事做扎实，再逐级放权。

模型这一层迟早人人都有，而模型外面的工程能力，才是真正拉开差距的地方。这大概就是我这次学习最想留下的一句话。

本文是笔者对 Harness 相关内容的学习整理，是按照自己的理解梳理出来的一篇文章，难免有疏漏或理解不到位的地方。希望能对大家有所帮助，也欢迎批评指正、一起交流。

参考与致谢

本文的框架和观点，来自公司内部培训、几位老师的文章及材料，以及我用 Claude 和 ChatGPT 各自做的一轮深度调研，在此一并致谢：

• 花园老师《Agent 驾驭 —— Harness》
• 李自然《Harness 完全指南：harness 是一切工作的核心》：https://mp.weixin.qq.com/s/Pbhyg8PPHNzhWbMLI732eA
• InfoQ《复杂业务场景下 RCA Agent 的探索实践》：https://mp.weixin.qq.com/s/tYGC7iPIEgc4TmRegpOgzw
• Claude 调研报告《Agent Harness Engineering: Transferring AI Coding Practices to AIOps for Financial Institutions》
• ChatGPT 调研报告《Harness 工程在运维与 SRE 领域的落地实践研究报告》
• 公司内部培训材料《多智能体协同：AI 驱动软件研发》（综述篇 / 实践篇）
• 最小 harness 开源示例：walkinglabs/learn-harness-engineering，https://github.com/walkinglabs/learn-harness-engineering