企业垂类智能体的 Harness 工程：从第一性原理到架构设计

引子

近两年，随着 Claude Code、OpenAI Codex 等编码智能体（Agent）的成熟，业界见证了一个此前难以想象的现象：给定一个目标，Agent 能够连续自主工作数小时，自行检索代码、修改文件、运行测试、再根据反馈迭代，直到交付一个可用的结果。这种 "连续自交付" 的能力，让很多工程师第一次真切感受到了 Agent 的生产力。

然而，当我们把同一个底层 LLM 接入到垂类生产场景中时，情况却大不相同。以生产运维为例，同样的 LLM，在面对 "某支付服务为何持续告警" 这类问题时，可能只能给出 "建议重启服务观察" 这样既不够精准、又暗藏风险的答复。那么，差距究竟在哪里？答案不是 LLM 本身，而在 LLM 之外的 Harness Engineering。

更值得注意的是，我们今天所能查阅到的绝大部分 Harness Engineering 实践经验，几乎都来自 AI Coding 场景，例如：Claude Code 如何管理上下文、Codex 如何将架构规约固化为 Lint 规则、DeepSeek dsh 如何将一切能力做成可插拔的插件。这些经验本身都相当扎实，但它们共享着一个很少被明确点破的前提：Coding 恰恰是 Harness Engineering 最友好的场景，比如说代码改错了可以回滚，结果对不对可以编译和测试，运行环境稳定且可复现等等。而垂类生产场景的约束条件，往往与之完全相反。

基于这一观察，本文尝试构建 2 个方法论工具：

诊断：提出一套任务场景五维坐标，用于量化任意一个垂类场景的约束特征，从而判断 Harness Engineering 的建设重心应该落在什么地方。
构建：从 "LLM 究竟是什么" 的第一性原理出发，由简到繁地推导出 Harness Engineering 的六个能力分层，并在每一层结合五维坐标，说明垂类场景下这一层需要做到什么程度。

最后，笔者将以一个生产运维值班智能体、一个智能问答机器人为例，介绍上述两个方法的实践过程。

1. Harness 是什么：从 Prompt 到 Context 再到 Harness 的三次演进

要理解 Harness 究竟是什么、又为何会出现，就需要回顾 Agent 发展的这两三年的历史，之中包含了一条 "真实问题驱动" 的因果链条。Prompt、Context、Harness Engineering 这三次演进，恰好对应着三个越来越本质的问题：

LLM 是否听得懂你在说什么？（表达问题）
LLM 是否拿到了足够且正确的信息？（信息问题）
LLM 是否能在真实执行中持续做对？（执行问题）

1.1 Prompt Engineering：先解决 "怎么说" 的问题

2022 年底 ChatGPT 掀起 LLM 浪潮时，人们发现了一个事实：同一个 LLM、同一个问题，换一种提示词，结果就天差地别。例如：让 LLM "帮我总结这篇文章"，它会给你一段平庸的概述。但如果换成 "请以资深技术编辑的身份，用三段式总结：先讲核心观点，再讲论证方式，最后讲局限，每段不超过 150 字"，那 LLM 输出的质量便明显提升。

于是第一代方法的核心观点就是：LLM 不是不会，而是你没有把问题讲清楚。既然 LLM 对输入极其敏感，那么工程优化的第一步自然落在打磨提示词本身，Prompt Engineering 随之流行起来：

角色设定：先告诉 LLM 你是谁，限定它的专业视角；
Few-shot 示例：少讲抽象原则、多给具体样例，这一思路可追溯到 2020 年 OpenAI 那篇《Language Models are Few-Shot Learners》，论证了 LLM 天生更擅长模仿范式；
思维链（Chain-of-Thought）：2022 年由 Google 研究员提出，先拆解、再推理、后作答，显著减少 "拍脑袋式" 的结论；
格式与边界约束：提前规定输出长什么样、预先划定拒答红线，提升结果的可用性与安全性。

那么，Prompt Engineering 为什么有效？根本原因在于 LLM 本质上是一个对上下文极度敏感的概率生成系统：给它什么身份，它就沿着那个身份的分布去采样；给它什么样例，它就沿着那个模式去补全。因此，Prompt Engineering 的本质并不仅仅是 "下命令"，而是塑造 LLM 的局部概率空间。这个阶段最关键的能力还不是系统设计，而是语言设计。

但它的天花板也很快显现出来。很多任务并不是 "你说清楚就行"，而是 "你得真的知道"，例如：分析一份公司内部文档、回答某个产品的最新配置、对照一套长规范生成代码。这时你会发现，提示词写得再漂亮，也替代不了 "事实" 本身。可见，Prompt 解决的是 "表达问题"，而非 "信息问题"。当任务从开放问答走进真实业务，焦点必然从 "怎么说" 转向 "给什么信息"，于是就推动了第二次演进。

1.2 Context Engineering：当 "说清楚" 不够，还得 "喂对信息"

如果说 Prompt Engineering 时代的默认假设是 "模型本来就知道，你得问对"，那么 Context Engineering 时代的假设则变成了 "模型未必知道，所以系统必须在每一次调用时，把正确的信息主动送进去。"

为什么这一转变恰恰发生在此时？根本原因在于使用场景变了。早期主流交互是聊天：任务短、链路短、状态少，把话说清楚就能解决。而 Agent 兴起之后，LLM 被放进真实的执行环境：要进行多轮对话，要调用搜索、浏览器、代码、数据库等工具，要在步骤之间传递中间结果、根据反馈修正计划。系统面对的不再是 "一次回答对不对"，而是 "一整条任务链路能不能跑通"。

这里需要澄清一个常见误解：Context Engineering 并不仅仅是 "给 LLM 补几段背景资料" 就可以了。在工程意义上，Context 是所有会影响 LLM 当前决策的信息总和，至少包括：用户输入、历史对话、检索结果、工具返回、任务状态、中间产物、系统规则与安全约束等。由此可以得到一个重要结论：Prompt Engineering 只是 Context Engineering 的一个子集。

这里还必须强调一个重要的客观事实：LLM 在推理时，能接收的 Context Length（上下文长度）存在物理上限，例如：2020 年的 GPT-3 最大输入长度只有 2048 个 token；2022 年底初代 ChatGPT 所依赖的 GPT-3.5 也不过 4096 个 token（约 4K）。这意味着你根本无法把所有资料一股脑塞给 LLM，超出窗口的部分会被直接截断，等同于不存在。即便到了今天，主流 LLM 的窗口已扩展到 128K、200K 乃至 1M token，它依然是一种有限且昂贵的资源，因为窗口越长，推理越慢、成本越高；而且当关键信息落在超长上下文的中段时，被有效利用的概率还会明显下降，业界称之为 context rot（上下文腐烂，即：信息塞得太满时，模型反而像'走神'一样，抓不住藏在中间的关键字）。

正因为 "能喂进去的信息" 存在这样一道硬边界，"如何在有限窗口里放置最关键的信息" 才成为一门必须精打细算的工程，这也是 Context Engineering 之所以如此严格的根本原因之一。

2025 年前后，随着 Andrej Karpathy、Tobi Lütke 等人的推广，Context Engineering 这一术语开始广泛流行。Anthropic 给出的定义相当准确：上下文工程是 "在推理时，为 LLM 策展并维护那一组最优 token（信息）的整套策略"，其核心原则是 "用最小的一组高信号 token，最大化达成目标的概率"。它的典型实践包括：

RAG（检索增强生成）：最早的代表，回答了 "模型参数里没有的知识，如何在运行时补进去"，即先从外部知识库检索相关内容，再注入当前上下文；
渐进式披露（Progressive Disclosure）：以 Anthropic 的 Agent Skills 为代表，不把十几个工具的说明一次性全塞进窗口，而是分为元数据层、指令层、资源层三级，只在需要时才暴露与当前任务最相关的部分。

但 Context 的局限同样明显，信息喂对了，模型也未必能稳定地执行对。它可能计划做得好、执行却偏了，可能调用了工具却误解了返回结果，也可能某一步出错之后一路错下去而无人察觉。说到底，Prompt 与 Context 都作用在输入侧：一个优化意图表达，一个优化信息供给。可当模型真正开始连续行动时，一个更复杂的问题出现了：谁来持续监督、约束、纠正并验收执行结果？第三次演进由此开始。

1.3 Harness Engineering：当模型从 "回答" 走向 "执行"

Harness 一词原意是 "缰绳、马具、挽具"，即套在马身上、供人驾驭的整套装置。把它应用 Agent 系统里，是一个非常直白的含义：当 LLM 从 "回答问题" 走向 "执行任务"，Agent 就不能只负责喂信息，还必须负责驾驭整个执行过程。

业界是如何给 Harness 下定义的呢？最凝练的一种表述来自 LangChain 团队，它用一个公式把 Harness 的边界划了出来：Agent = Model + Harness。Anthropic 在其工程博客里的描述则更为具体：Harness 是模型周围的软件脚手架，也就是循环、工具、上下文管理与护栏（the loop, tools, context management, and guardrails）。这两种说法，一个划了边界、一个列了构成，共同回答了 Harness 是什么。

那么，Harness 驾驭又是什么呢？一个通俗的类比如下，设想让一位新人去完成一次重要的客户拜访：

工程阶段	对应的动作	关注的重点
Prompt	把任务讲清楚："先寒暄，再讲方案，再问需求，最后确认下一步"	把话说明白
Context	把资料备齐：客户背景、过往沟通记录、产品报价、竞品情况	把信息给对
Harness	让他带着 checklist 出发、关键节点实时回报、会后核对纪要、出现偏差立刻纠正、最终按明确标准验收	持续观测、纠偏、验收

可见，Prompt ⊂ Context ⊂ Harness，而 Harness 关注 LLM 在真实执行中是否被一个完整系统持续约束、观测、纠偏与收敛。

那么，究竟什么时候才真正需要 Harness 呢？答案其实很朴素，取决于任务的复杂度：一次性问答，Prompt 就够用；任务复杂到上下文不够用，Context 成为核心；而一旦任务变成长链路、可执行、低容错，即需要连续行动、需要对结果负责、出错代价很高，Harness 便几乎不可避免。

1.4 一个被忽略的事实：编码是 Harness 最友好的场景，但其他垂类场景不能硬套

值得注意的是，Harness 这套工程最早诞生、发展并成熟于编程场景。

Claude Code：起初只是 Anthropic 内部的一个命令行编码工具，因在工程师之间口口相传、使用量迅速攀升，才于 2025 年初对外发布。正是在反复打磨它、以及一系列长程编码实践的过程中，Anthropic 团队逐渐意识到：真正决定好不好用的，往往不是模型本身，而是模型外面那圈 "循环 + 工具 + 上下文管理 + 护栏" 的工程体系，并在工程博客中正式用 harness 一词来指代它。
OpenAI Codex：把 harness 工程推向了大规模真实代码库。为了让 Agent 在庞大工程中稳定协作，Codex 团队把资深工程师的架构判断固化成机器可强制的 Lint 规则，又用一份精简的 AGENTS.md 充当 "导航地图"，这些都是典型的 harness 手段。
DeepSeek dsh：一套开源的 Agent Harness 运行时框架。它索性把上下文、工具、编排、安全等一切能力都做成可插拔的插件，并以事件溯源作为底座，代表了把 harness 本身彻底框架化的思路。

三者出身不同、路径各异，却共同指向同一个事实：几乎所有成熟的 Harness 概念与实践，都是先在编码 Agent 上被打磨出来的。所以这些经验也就与编码场景强关联，反之编码场景也是 Harness 工程最友好的场景，因为它同时具备三个得天独厚的条件：

低成本的验证：一段代码正确与否，无须主观判断，编译一次、运行测试、执行一遍 Lint，机器会立刻给出客观结论。
动作可回滚：改错了代码，git revert 即可撤销，沙箱重置即可还原，世界随之回到出错之前的状态。
环境确定且可复现：同一份代码、同一套依赖，今天运行与明天运行的结果基本一致。

正是这三个条件，使得编码 Agent 可以采取一种 "先动手、再验证" 的策略：大胆修改，一旦出错，事后的验证环节会予以拦截，拦截之后回滚重来即可。换言之，编码场景允许把工程重心放在事后的验证上，而事前的约束反而可以相对宽松。

然而问题也正出在这里。垂类生产场景的这三个基础条件，往往与上述情形恰好相反：验证并不免费、动作难以回滚、环境也不确定。将一套 "为最友好场景调校" 的 Harness，直接套用到一个基础条件完全相反的场景上，出问题几乎是必然的。

2. 垂类智能体为什么不能照搬：给任务场景定一套五维坐标（诊断工具）

前面我们提到了面向编程的 Harness 不能完全照搬到垂类场景中，这里笔者在实践中总结了一个五维坐标工具，用于诊断一个垂类 Agent 在其特定的任务场景中 Harness 工程的实现重心应当落在什么地方。

2.1 任务场景五维坐标

可验证性：一个结果的对错，能否被低成本、客观、快速地判定？编码的可验证性极高，编译器与测试就是最诚实的裁判；相反的，"这条故障定位结论对不对"、"这份周报写得好不好" 则很难由机器当场裁定。
可回退性：动作一旦做错，能否撤销、回退到出错之前？改一行代码是可回退的，git revert 即可；而重启一个生产集群、删除一批数据、对外发出一封通知，则大多无法回退。
环境确定性：Agent 的运行环境是否稳定、是否可复现？同一份代码在沙箱里今天跑、明天跑，结果一致；而线上环境有几十个集群、多个机房，拓扑、流量、依赖时刻在变，同一条命令此刻安全、下一刻可能致命。
自主性：任务是一次性的问答，还是需要连续数小时、跨越多个会话的长程任务？任务越长程、Agent 自主运行的时间越久，对 "记住进展、不迷失目标" 的要求就越高。
合规性：这个场景是否受监管、是否需要审计、是否必须为结果担责？编码在实验分支上几乎没有合规压力；而金融、医疗、生产运维，每一个动作都可能要留痕、要复核、要能回溯根因。

维度	核心问题	要求严格时工程实践的重心
可验证性	对错能否低成本、客观地判定？	可验证性低：从自动验证转向独立评审 + 人工把关
可回退性	做错能否撤销、回退？	可回退性低：事前约束、权限分级、两阶段审批
环境确定性	世界是否稳定可复现？	确定性低：强化异常处理，并在真实环境中反复验证
自主性	单轮，还是长程任务？	自主性高：状态持久化、记忆、断点续跑
合规性	是否受监管、需审计？	合规性高：治理、审计、数据隔离、可追溯

2.2 编码 Agent 与垂类 Agent 的五维对照

有了诊断的五维坐标这把尺子，就能把编码 Agent 与垂类 Agent 放到同一坐标系里进行对照。例如我们在后文案例中讨论的生产运维值班智能体，它与编码 Agent 的五维对照表如下：

维度	编码 Agent	生产运维 Agent
可验证性	高（编译 / 测试 / CI）	中（部分指标可查，结论多需人判）
可回退性	高（revert / 沙箱重置）	极低（重启、扩缩容、改配置多不可逆）
环境确定性	高（可复现）	低（多集群多机房，时刻在变）
自主性	高（可连续自主交付数小时）	受限（关键动作须人在环）
合规性	低	极高（操作留痕、审计、追责）

显然的，两者在坐标系里几乎站在对角线的两端。编码 Agent 在可验证、可回退、环境确定这三项上全部拿到高分，而生产运维 Agent 恰恰在可回退性与合规性这两项上要求最严格。

可见，为编码场景而设计的 Harness 架构，无法直接照搬到垂类智能体场景。

2.3 控制论三阶段：事前、循环、事后

一个 Agent 的可靠运转，本质上就是一个控制系统，可以拆成前中后三段：

事前（前馈控制）：在动作真正发生之前，用上下文、领域知识、约束与权限，尽量抬高 "一次就做对" 的可能性。
循环中（执行）：让 LLM 在 "调用工具、观察结果、再决定下一步" 的循环里推进，同时维护好状态、不迷失目标。
事后（反馈控制）：动作完成之后，验证结果到底对不对，对的话就输出、不对的话继续进入循环、出了错还能不能拉得回来等等。

再把前面归纳的任务场景五维坐标和控制论三阶段关联起来：

可验证、可回退的场景（如编码）：Harness 重心可以落在 "事后" 验证上，事前可以从简；
低可验证、不可回退、高合规的场景（如生产运维、金融、办公）：Harness 重心必须放到 "事前"，在动作发生之前就把风险拦住，同时把事后的审计与追溯做扎实。

用一个朴素的类比来说明这一区别，编码 Agent 像是在草稿纸上工作：写错了划掉重写，代价只是几张纸，所以鼓励它多写多试，关口设在终点。生产运维 Agent 则像是在做手术：每一刀都作用在真实的病人身上，无法撤销，所以真正的功夫全在动手之前，反复确认、分级授权、关键步骤必须有人复核，关口设在每一个动作的起点，事后还要留下完整的手术记录以备追溯。

2.4 从 "诊断" 到 "构建"

到这里，本文的第一件事，也就是诊断，就完成了：给定任意一个垂类场景，用五维坐标去考量、判断 Harness 工程的重心该往事前压还是往事后放、哪几层需要加码、哪几层可以从简。

但诊断只回答了 "该往哪里使劲"，没有回答 "具体搭什么"。所以接下来的第三章，笔者会从 "LLM 到底是什么" 这一第一性原理出发，由简到繁地把 Harness 的能力逐层推导出来；并且在推导每一层时，再结合五维坐标来判断在生产运维这样的场景里，这一层究竟应当投入到什么程度。

3. 从第一性原理出发：由简到繁搭建六层能力（构建方法）

3.1 第一性原理：LLM 只是一个 "无状态的文本函数"

把 LLM 做第一性原理的拆解，其最底层只剩下一个不可再分的事实：LLM 是一个无状态函数，给它一段上下文，它就吐出一段文本，仅此而已。

这一基本事实使得 LLM 有 4 个天生的 "做不到"：

它不能行动，只会吐字；
它不知道聊天窗口之外的任何事，包括最新事实与私有数据；
它不记得上一次调用，每一轮都是一张白纸；
它不保证 100% 正确，还会自信地把错的说得像真的。

这一事实直接决定了 Harness 的设计宗旨：逐一补齐 LLM 作为 "无状态文本函数" 在可靠的完成真实任务过程中所暴露出的每一个能力短板，对应到下文中的六层能力。

3.2 由简到繁：六层能力，每层补一处短板

3.2.1 L0 起点：裸模型

手里只有一个裸的 LLM 时，它能读懂指令、能推理、能生成像样的文本，能力也就到此为止。用第一性原理的视角看，它只是一个无状态的文本函数：喂进去一段上下文，吐出来一段文本。

然而，它碰不到真实世界，拿不到聊天窗口之外的新信息，记不住上一轮，还会把错的说得很笃定。后面的每一层，都是为补上其中某一处短板而生。

3.2.2 L1 工具循环：先让它能动起来

这一层补的是 "不能行动" 这处短板。

以 "Kubernetes app 某服务为何返回 502" 为例，如果缺少这一层时，LLM 只能凭记忆回答一句 "502 通常是网关问题"，便无以为继；具备这一层后，它会先执行 kubectl get pods 查看状态，发现某个 Pod 处于 CrashLoopBackOff，再用 kubectl logs 读取日志，看到一行 connection refused: redis:6379，进而顺着这条线索去排查 redis。每一步的真实输出都回灌给 LLM，它便从 "背诵知识" 转为 "勘察现场"。

这一模式在工程上最早的两项落地值得一提。

ReAct（2022 年提出）：它让 LLM 在推理（Reason）与行动（Act）之间交替，先想一步、再动一步、观察结果、再想下一步，这正是主循环的思想雏形。
Function Calling（函数调用，OpenAI 于 2023 年推出）：它让 LLM 能以结构化格式吐出 "调用哪个工具、传什么参数" 的结果，从而与确定性代码稳定对接。

这是整个 Harness 唯一不可再分的内核，无论往下如何拆解，最终都会回到它。今天几乎所有 Agent 的主循环，本质上都是这两者的延续与工程化。

那么，什么样的 Agent 需要这一层？判断标准很简单：任务是否需要触碰真实世界。纯知识问答、闲聊类智能体可以没有它；而生产运维（查状态、做变更）、数据分析（跑 SQL、算指标）这类必须与真实系统交互的智能体，这一层就是地基。

3.2.3 L2 上下文管理：喂对信息，也管住聊天窗口

这一层补的是 "不知道聊天窗口外" 的短板。

LLM 只认聊天窗口之内的内容，窗口之外的一切等同于不存在，所以要做两件事：把该看的信息送进去，同时把聊天窗口本身管住，抑制上下文腐烂。

先说 "送进去"，最常见的是 RAG 检索，先从知识库中捞出相关内容再拼入上下文，同时把任务目标、扮演角色、验收标准一并交代清楚。

再说 "管住聊天窗口"，这一步更为讲究，因为上下文并非越多越好。因为 LLM 的 "注意力预算" 有限，每多一个 token 便耗费一分，而且关键信息一旦落在长聊天窗口的中段，被有效召回的概率会明显下降。常用的方法有：

渐进式披露，先给一份目录，LLM 需要哪一块再去拉取哪一块；
接近聊天窗口上限时做压缩，把已有历史就地总结为摘要后再续跑；
把中间产物写入文件外置存放，需要时再读回。

判断要不要这一层，看的是 LLM 能否仅凭自身参数与单条指令就完成任务。闲聊类智能体基本不需要；而运维、客服、办公类智能体的答案往往依赖企业内部知识与实时状态，就必须把知识库与实时数据接进来。

3.2.4 L3 任务状态与会话记忆：记住任务进展，跨步骤、跨会话不失忆

这一层补的是 "不记得上一次" 的短板。

注意，这里说的 "状态"，特指任务执行的进展，也就是 "做到哪一步、哪些结论已经确认、还剩哪些待办"，而不是 LLM 的内部参数，也不是操作系统那种运行时状态。

之所以需要它，是因为 L1 的工具循环本身并不记录状态信息：同一个任务分成多轮、多天推进，或进程中途崩溃后重启，再次接手时，它对此前发生过什么一无所知。Anthropic 有一个贴切的比喻：这就像一个轮班作业的项目，每一班到岗的工程师都不清楚上一班做了什么。

做法是把这份进展状态放到上下文之外的持久化保存，以此来支持断点续跑：将 "进行到哪一步、哪些结论已确认、哪些教训已积累" 一一记下来。具体实现举例：

Claude Code：以一次 git commit 作为断点，另配一个进度文件充当临时工作台；另外还会在长程任务实践中把上百条待办拆成 JSON 记录、逐条推进。其中，用 JSON 而非随手写的 Markdown，是因为 LLM 不易擅自改动 JSON 的结构；
DeepSeek dsh：把整个会话记为一份只追加的事件日志，一旦崩溃便重放日志恢复。

是否需要这一层，取决于任务是否跨越多轮乃至多个会话、是否要求中断后能续跑。一次性的单轮问答用不上；而一次可能持续数小时的运维值班、一份需要分多次写就的长篇报告，都要靠它兜住进展。

3.2.5 L4 任务验证："完成" 不能让 LLM 自己说了算

这一层补的是 "不 100% 保证对" 的短板。

要讲清楚它，先回答两个问题：验什么，谁来验。

验的是：任务到底有没有真正完成、产出到底对不对。
谁来验：是绝不能让执行任务的那个 LLM 自己当裁判，避免 LLM 自己说 "我做完了"。因为 LLM 极不擅长评判自己，实测中让它为自己的产出打分，它往往一味自夸，哪怕成果在旁人看来只是平平。因此必须引入一个独立于执行者之外的验证者，让 "完成" 成为被第三方证明出来的结论，而非由执行者自行宣布。

这个验证者具体由谁扮演？通常是三者的叠加：

确定性程序（计算性验证）：测试、编译、探活、对账，客观且快，但判不了业务是否合理。
另一个专门当裁判的 LLM（推理性验证）：能读懂语义与体验，代价是较慢、不稳定、有额外成本。
必要时的人工复核；

无论用哪一种，都有两条经验值得记住：

把 "生产" 与 "验收" 拆成两个角色，并刻意把验收者调得更为多疑，实践表明，让一个独立评估者变挑剔，远比让生成者对自己下狠手来得容易；
验证要 "带环境" 进行，不是读一遍结论、看一眼截图就打分，而是像真实用户、真实系统那样实际走一遍，包括点开应用、调用接口、核对数据库状态与监控。

如何判断要不要这一层，关键看两点：你是否要对结果负责，以及对错能否被自动判定。例如运维的故障定位结论、数据分析的口径与数字、金融场景的每一笔判断，都必须配上任务验证乃至人工复核。

3.2.6 L5 安全护栏与失败回退：能真办事，就得兜得住

让一个 Agent 从 "demo 能跑" 到 "敢于上线"，卡点几乎都在这一层。它要回答两个问题：哪些动作不允许做（事前挡住），以及做错了怎么收场（事后拉回）。

先解决 "不允许做"，把危险动作挡在发生之前。按拦截强度，通常叠三道：

权限分级：工具分成只读、可写、可执行三档，默认只授予完成任务所需的最小权限；
两阶段提交：面向生产、对外发送、涉及费用等不可回退的动作，禁止一步到位，而是先产出一份 "拟执行方案"，经人工或合规校验通过后，第二步才真正落地；
规则硬约束：把架构规范与安全红线写成机器可强制的 lint（例如规定依赖只能自上而下单向流动，即按 Types、Config、Repo、Service、Runtime、UI 逐层向下、不许反向），越界即报错，并把"应如何改"回传给 LLM，这比在提示词里反复叮嘱可靠得多。

这三道之外，还有一条始终生效的底线：外部内容零信任。凡从公网、邮件、外部文档读入的内容都视为不可信，重点防范其中夹带 "忽略此前指令、你现在是另一个 Agent" 这类提示词注入工具。同样，LLM 对外的输出也应默认视作不可信的生产数据，必须经过脱敏与合规校验才可释放。

再解决 "做错了怎么收场"，让系统出错后能自己站起来。同样是三手准备：

有限自愈：某一步失败时，把错误信息回灌给 LLM 令其自行修正，但必须限定重试次数，以免它在同一处反复打转；
崩溃恢复：进程意外中断后，能凭日志重放回到断点，而不是从头再来；
收尾归位：任务结束时不论成败，都要清理临时资源、释放锁，并明确 "提交或回滚"，不给下一个任务留下脏状态。

这一层要投入到什么力度，几乎完全由风险决定：动作越不可回退、合规要求越高，就越要在这一层重点投入。纯只读的问答智能体无须太重；而运维改动生产、办公对外发信、金融执行交易，都必须把这一层做到最重，典型措施包括只读定位与授权写严格分离、环境绑定不可变、关键写操作强制人工审批，以及全链路审计。

3.2.7 L6 多智能体编排：真扛不住了才扩展

当任务长到、大到、杂到单个智能体一个上下文、一个角色都扛不住时，才考虑把它拆给多个智能体。这里要区分两种目的不同的方案：

Sub-Agent（子智能体）：主智能体把一段子任务派给子智能体去做，目的主要是上下文隔离，即让子智能体用干净的上下文深挖，只把结论摘要回传，避免噪声污染主上下文。它是 "主从" 关系，子智能体通常不做对等决策。
Multi-Agent（多智能体协作）：多个各有专长的智能体分工协作完成同一个大任务，例如 planner、coder、reviewer 各司其职，目的是分工与专业化。它是 "对等 / 流水线" 关系。

不管用哪一种，都要守住一条原则：克制，不为多而多。多智能体最大的风险，在于让若干智能体各自并行做决策、再把彼此看不见的中间结论硬拼到一起，结果往往更糟糕。因此，真要协作，也应优先保证信息在智能体之间充分共享，而不是各自为战。

判断要不要这一层，看的是单一上下文、单一角色是否真的扛不住。绝大多数垂类任务到 L5 便已足够结实；只有真正长程、大规模的任务（如大型迁移、跨多个子系统的排查）才用得上编排；而在运维这类场景中，即便引入编排，真正执行动作的环节反而要刻意 "锁小"。

3.3 编码 Agent 与垂类 Agent 的六层对照

有了这张图，就能把编码 Agent 与生产运维 Agent 放在一起对照。两者用的是同一套六层，差别只在于每一层投入的轻重不同：

能力层	编码 Agent	生产运维 Agent
L1 工具循环	重（反复试错是主旋律）	中（执行动作受严格约束）
L2 上下文管理	中（读代码为主）	重（知识库 + 实时状态 grounding）
L3 状态记忆	中（git 即断点）	偏重（跨会话排障续跑）
L4 验证	重（编译 / 测试 / CI 近乎免费）	中（探活对账 + 独立评审 + 人工）
L5 安全护栏	轻（沙箱可回滚）	最重（只读/授权写隔离、审批、审计）
L6 多智能体编排	可上（大型重构）	谨慎，执行环刻意锁小

对照之下，两者的区别就一目了然了。编码 Agent 把重心放在 L1 与 L4，也就是 "先执行、再验证"，L5 相对较轻；生产运维 Agent 则把重心整体前移到 L5，把安全与治理投入到最重，反而要刻意约束执行环节。

可见，编码 Agent 的配比是典型的 "草稿纸逻辑"：L1 试错和 L4 验证极重，因为改错成本极低；而生产运维 Agent 则是纯粹的 "手术台逻辑"：把 L5 安全护栏做到极致，甚至不惜牺牲一部分 L1 的自主性。

还需补充一点：每一层的配比都不是一次定死的。随着 LLM 能力不断增强，今天必须重点投入的某一层，日后或许就能精简，把相应的判断交还给 LLM。因此每一次 LLM 升级，都值得重新审视一句：哪几层只是当前 LLM 能力不足时的临时支撑？

4. 五维坐标 × 控制轮三阶段 × 六层能力

部件：图中每个方框（L1--L6）是一层能力，也就是搭 Harness 的零件；
骨架：竖向的 "事前、循环、事后" 三个阶段，是把这些零件组织起来的控制论闭环；
标尺：任务场景五维坐标，用来衡量每一层零件该投入多少，图右侧标出了每一段主要受哪几维影响。

三者合起来就是一句话：用五维坐标诊断你的任务场景，定出该在控制量三阶段中的什么位置、侧重实现哪几层的部件，便得到一套专属 Harness。

下面这张表，把 "哪个维度主要作用于哪一层" 对应清楚：

维度	主要影响哪一层	该维度要求严格时
可验证性	L4 验证	低，则从自动验证转向独立评审 + 人工把关
可回退性	L5 安全护栏	低，则事前约束、两阶段提交、审批更重
环境确定性	L1 / L5	低，则异常处理与"带环境"验证更重
自主性	L3 / L6	高，则状态持久化、记忆、编排更不可省
合规性	L5 安全护栏	高，则审计、权限、数据隔离更重

值得注意的是，笔者认为好的 Harness 实践不是层数最多的那个，而是恰好补上当前 LLM 在你的垂类任务场景中所暴露出来的短板即可，此外的多一层都是负担和过度设计。真正重要的不是 "恰好六层"，而是每加一层之前，先确认上一层是不是真的撑不住了。

5. 落地案例：两个场景，同一套方法论

这一章用同一套分析方法来分析两个案例，步骤都是：先讲需求背景，再做五维坐标诊断，据此定出六层能力配比，最后落成架构设计。它们的坐标很不一样，因此最后配出的 Harness 也很不一样。

5.1 案例一：生产运维值班智能体

5.1.1 需求背景

一家企业有多套线上环境（多个集群，分布在不同机房）。运维团队每天在 IM 群里应付两类事：一类是"这个报错是什么意思"的日常咨询，一类是"支付链路是不是出问题了"的线上告警。他们希望有一个生产运维值班智能体，通过 IM 群与 Web 两个入口，来完成四类工作内容：回答咨询、巡检状态、定位故障，以及在受控范围内执行运维变更操作。

5.1.2 五维坐标诊断

用第二章的五维标尺逐维打分：

可验证性：中。部分结论能靠探活、对账当场核验，但"这条故障根因对不对"多半仍需人来判断。
可回退性：极低。重启服务、扩缩容、改配置、删数据，很多动作一旦执行就收不回来。
环境确定性：低。多集群多机房，拓扑与流量时刻在变，同一条命令此刻安全、下一刻可能闯祸。
自主性：受限。允许它长时间自主巡检、定位，但关键变更必须有人在环。
合规性：极高。每个动作都要留痕、可审计、可追责。

可见，该场景中，可回退性与合规性都最严格。所以，Harness 工程重心不能压在事后验证，而必须前移到事前约束与治理，也就是把 L5 做到最重，把执行环节刻意锁小。

5.1.3 六层能力配比

按第三章的六层，逐层给出这个场景的轻重取舍：

L1 工具循环（中）：巡检与定位都靠它反复 "查状态、读日志、缩小范围"。但它的工具默认全是只读的，真正改动系统的执行环被刻意锁小（原因见 L5）。
L2 上下文管理（重）：低可验证场景的关键核心。答案必须有据可查，而非 LLM 凭记忆去编，所以要把企业知识库（RAG）与集群、监控、日志的实时状态一起检索进来，让每个判断都能追溯到具体文档或某条指标。
L3 状态与记忆（偏重）：一次排障可能跨小时、跨多轮，靠它记住 "已经排除了哪些可能"。更进一步，把成功的定位路径与变更 SOP 沉淀成长期记忆，下次遇到相似告警可直接复用。但沉淀必须搭配遗忘功能：与环境强相关的旧 SOP 在架构变更后要能自动失效、转入待复核，否则它会照着已经不存在的拓扑去查。
L4 独立验证（中）：定位结论不由干活的那个 LLM 自己拍板。一方面用探活、对账做客观核验（这是计算性验证），另一方面引入一个刻意 "多疑" 的独立裁判去质疑根因（这是推理性验证），高风险结论再叠一道人工复核。注意：此处 L4 虽为 "中"，但并不代表验证不重要。在手术台逻辑下，验证无法像草稿纸那样 "先做再验"，因为动作不可逆。因此，运维场景的验证是：一部分在 L5 的事前审批中由人完成（预验证），一部分在事后仅做客观探活（计算性验证）。L4 的权重被有意拆解并前移了。
L5 安全护栏与失败回退（最重）：这是整个案例的重心，投入最重。在动作发生前，做三件事：只读定位与授权写严格分离；一切不可回退的动作走两阶段提交（Agent 只产出 "拟执行方案"，人工审批通过后才由系统执行，它自己碰不到 "执行" 按钮）；环境绑定不可变（一个会话一旦绑定某套环境，中途绝不允许切换，凭证随之绑定，从机制上根除 "把生产当预发" 的误操作）。而在动作出错后，靠有限自愈、崩溃重放、收尾归位兜住。全链路审计则贯穿始终。

- L6 多智能体编排（谨慎）：按能力把问题路由给专业子智能体（如网络、存储、数据库各一个）。这些子智能体的角色与行为都受严格约束：角色上只做 "专项只读调查"，即在自己领域内深挖、给出判断，不做全局决策、也不碰任何变更动作；行为上各自使用独立的干净上下文、只用只读工具，查完只把结论摘要回传，由主智能体统一收口。这样一来，多开子智能体带来的只是"上下文隔离"的好处，而不会放大变更风险，更不是让它们并行各拍各的板再硬拼到一起。

5.1.4 架构设计

把上面的配比落成一套可实现的架构，主链路是一个五步闭环（图 3）：

对照上面的链路，一套功能模块划分是：

入口适配层：对接 IM 群与 Web，把不同入口的消息统一成标准的对话事件，屏蔽渠道差异。
检索层（两个数据源）：一路是知识库检索（RAG），供给 SOP、架构文档、历史案例；另一路是实时状态采集，对接集群、监控、日志的只读接口，回答"现在到底怎么了"。两路结果一起拼进上下文。
上下文编排器：把检索结果、任务目标、权限信息、已绑定的环境组装成一次调用的上下文，并负责窗口管理（压缩、外置）。
主循环与工具集：智能体的核心循环。关键在于工具要分成两组注册，只读工具（查状态、读日志、看配置）默认可用，授权写工具（重启、扩缩容、改配置）默认锁住。
授权关卡：设在 "只读定位" 与 "授权写" 之间，负责两阶段提交、人工审批，以及环境绑定校验。这是整套架构里最不能省的一块。
验证器：对定位结论做探活、对账等客观核验，并挂一个独立裁判质疑根因。
记忆与沉淀存储：一方面存任务进度（供断点续跑），一方面也存长期经验（供复用），且带遗忘策略。
审计日志：独立于主链路之外，完整记录每一次工具调用、每一个决策与授权，供事后追溯。

最后提醒一句：入口适配、检索、上下文编排、主循环、验证、记忆这一串骨架，几乎可以原样搬到别的垂类智能体上；真正因场景而异、需要重新拿捏的，是授权关卡与审计这类治理件的轻重。下一个案例就会看到，换个场景，这几块的分量立刻不同。

5.2 案例二：智能问答机器人

5.2.1 需求背景

再看一个常见得多的场景：一个面向用户的智能问答机器人（例如产品答疑、售前咨询），通过网页或 App 的对话入口回答用户提问。它只回答问题，不改动任何系统。

5.2.2 五维坐标诊断

同样用五维标尺量一遍：

可验证性：中低。"答得好不好"很难当场客观判定。
可回退性：中。它不改动系统，但对外说出去的话收不太回来，可能造成误导或不当承诺。
环境确定性：中高。主要读知识库，环境相对稳定。
自主性：低。基本是单轮或少数几轮问答。
合规性：中高。对外发言，要守口径、不能乱承诺。

坐标一变，重心也随之改变：它的要害不在执行变更的安全（它根本不执行危险动作），而在两点，即答案要准（别胡说）、出口要稳（别乱承诺）。

5.2.3 六层能力配比

同一套六层，配比却和案例一几乎相反：

L1 工具循环（轻）：多数问题一问一答即可，最多调用查知识、查订单这类只读接口，几乎没有执行动作。
L2 上下文管理（最重）：这是它的命门。答案必须来自知识库检索，而不是 LLM 凭记忆生成，否则就是一本正经地胡说。这里 RAG 的质量几乎决定了产品的上限。
L3 状态与记忆（轻）：多为单轮或短对话，无需跨会话的长期状态。
L4 验证（中）：上线前靠合规校验把关，上线后靠抽检解决率、满意度做事后评估。
L5 安全护栏（换了方向）：不再是 "防止误删生产"，而是 "防止乱说话"，即输出要过一遍合规与口径校验，不承诺做不到的事，命中敏感或超纲问题就转人工。
L6 多智能体编排（轻）：单个上下文足以应付，无需编排。

5.2.4 架构设计

它的主链路比案例一短得多（图 4）：

对照案例一的模块划分，就能直观看出这套 "减法" 减在哪：入口适配、检索层、上下文编排、主循环、验证、审计这套骨架依然保留，但案例一里最重的授权关卡与授权写工具在这里被整个去掉了（它根本不执行危险动作），沉淀闭环也可以省去或做得很轻。省下来的分量，全部加到了两处：检索层要把 RAG 做到最准（L2），输出护栏要把住 "不乱说、不乱承诺、该转人工就转人工"。

5.3 小结：没有通用最优，只有匹配坐标

把两个案例摆在一起，本文的方法就闭合成一句话：先用五维坐标，再按坐标决定每一层投入的轻重。同一套六层、同一把标尺，坐标不同，重心便落在不同的位置：

案例	坐标上的要害	工程重心落在
生产运维值班智能体	不可回退、高合规	L5 安全护栏（两阶段审批、环境绑定、审计），辅以 L4 独立验证、L3 沉淀与遗忘
智能问答机器人	怕胡说、怕乱承诺	L2 知识 grounding，辅以换了方向的 L5 输出护栏

结论也就水到渠成：它们的强，都不在于接了多强的 LLM，而在于把工程重心精准地压在了各自任务场景最脆弱的那几处。那么，如果把这套 "看坐标、补短板" 的方法再往上抽象一层，它会收敛成一个更简单的模型。这，就是最后一章要讲的。

6. 智能体落地的三环理论

最后，笔者想把它们收进一个更简单的心智模型：一个由内到外、层层包裹的 "三环"。

arduino 复制代码

   ┌─────────────────────────────────────────────────┐
   │ 三环 · 价值闭环（业务重塑）                       │
   │  ┌───────────────────────────────────────────┐  │
   │  │ 二环 · 控制论三阶段（工程控制）             │  │
   │  │  ┌─────────────────────────────────────┐  │  │
   │  │  │ 一环 · 工具循环（技术内核）           │  │  │
   │  │  │     〔 LLM 〕 ＋ tools in a loop     │  │  │
   │  │  └─────────────────────────────────────┘  │  │
   │  │   事前约束 · 循环执行 · 事后验证            │  │
   │  └───────────────────────────────────────────┘  │
   │   检索 · 注入 · 思考 · 执行 · 沉淀，回流组织知识  │
   └─────────────────────────────────────────────────┘
        能动             可靠              增值

由内到外，三环依次回答三个越来越大的问题：能不能动，动得对不对，以及做这件事到底有没有让业务变得更好。

6.1 一环：工具循环，让智能体 "能动起来"

最内层，就是第三章那个不可再分的内核：让 LLM 在循环里调用工具。LLM 产出动作，确定性代码执行，结果回灌，再决定下一步。它解决的是最基本的问题，即让 LLM 从"只会吐字"变成"能真办事"。

但它只是起点。一个只有内环的智能体，能动，却不一定动得对、动得稳。而且这一环几乎没有壁垒：今天任何人接上一个够强的模型、给它几个工具、套一个循环，都能让它跑起来。所以真正拉开差距的，在外面两环。

6.2 二环：控制论三阶段，让智能体 "做得对、兜得住"

往外一层，是把工具循环包进 "事前约束、循环执行、事后验证" 这个控制闭环里。第二章的三段、第三章的六层能力与五维标尺，都长在这一环上，它解决的是可靠性。

短板驱动：不要照着组件清单堆层，而要先问 "我的任务里，LLM 现在具体做不到什么"，缺什么补什么。补齐当前短板即可，多一层都是负担。
组件会过期：每一层都是 "LLM 暂时做不到" 的一个假设。模型变强之后，要敢于把某些层做薄、把判断交还给它；而像业务合规、安全审计这类编码的是业务约束、不因模型变强而失效的层，则要稳稳保留。

二环才是垂类智能体真正的工程护城河：同样的内环，谁的三阶段调得更贴合自己的五维坐标，谁就更可靠。第四章两个案例的差别，本质上就是二环的配比不同。

6.3 三环：价值闭环，让智能体 "越用越增值"

最外层，也最容易被忽略。一个只做到二环的智能体，是一个可靠的任务执行者，任务做完也就结束了。而三环追问的是一个更大的问题：它能不能反过来让业务本身变得更好？

例如案例一中的 "沉淀" 能力，当 Agent 把每一次排障的路径、每一份被验证过的方案，回流到组织的知识库与记忆中，它就不再只是完成任务，而是在持续沉淀组织的经验：过去靠老师傅口口相传、会随人员流动而流失的隐性知识，被固化下来，可复用、可传承。用得越多，这套知识越厚，智能体越准，人也越能从重复劳动里腾出手，去做更高价值的判断。于是形成一个 "使用、沉淀、增值、更愿意使用" 的正向闭环，Agent 从一件工具，长成了业务流程本身的一部分。

需要说明的是，三环并非每个场景都要做满。像案例二那样的问答机器人，价值主要还落在二环的答准与合规上；但凡是长期服务于同一套业务、且经验值得积累的场景，三环就是它从 "好用的工具" 走向 "越用越离不开" 的关键。

结语

本文从一个对比开篇：同样的模型，编码智能体能连续自交付，运维智能体却处处受限。一路走下来，答案已经清楚：差距不在模型，而在模型之外那一圈 Harness。

如果把全文浓缩成一张图，就是那三个同心环。最内的一环是工具循环，它让智能体能动起来，却几乎没有壁垒；真正决定成败的，是外面两环：二环用 "事前约束、循环执行、事后验证" 的控制闭环，让它做得对、兜得住；三环用 "沉淀"，让每一次使用都回流成组织越来越厚的能力。

也正因如此，垂类智能体的竞争，从来不在于谁接了更强的 LLM，而在于谁能用五维标尺看准自己任务场景的短板与风险边界，再把六层能力配出恰好匹配的轻重。模型会越来越强，最内环的门槛只会越来越低；而外面两环的工程精度与业务闭环，才是真正长在自己业务里、别人搬不走的护城河。

Agent 不难，为自己的任务场景配一套刚好够用、并能随模型进化而不断调整的 Harness，才是真正难的，也真正值得的事。