
上一篇我们把 Java 侧六个框架分成了三层台阶，最后留了个尾巴：选完层之后，这套东西该长多大。

这个问题比选框架更难回答，因为它没有标准答案。随便翻几篇讲 Harness 的文章，会发现它们把部件拆得很全：一个循环、工具系统、记忆与上下文、护栏、技能系统，再往后还有沙箱、长时运行、评测。拆得都对，但读完你会卡在同一个地方——我知道它有哪些零件了，可我不知道我的项目该装几个。

这篇换个角度。不讲零件清单，讲刻度尺：把 Harness 从最简到最全分成六级，每一级说清楚三件事：这一级加的是什么、出现什么信号才该加它、提前加要付什么代价。配上贯穿始终的那个客服场景，你看完能直接对着自己的项目定级。

---

## 一、先说清楚两件事：Harness 是什么，这篇讲什么

开篇先钉死一个词。这两篇里说的 Harness，指的是**让模型能连续干活的那套运行时机制**，不是别的意思。它由开发框架的能力和运行时的机制拼出来，没有哪个产品能整包卖给你。

判断一个东西是不是真的 Agent，标准不在它有没有接工具。挂个搜索接口就敢叫 Agent 的产品很多，但那只是“模型调了个函数”。真正的分界线是：工具返回的结果，会不会改变它后面的动作。返回空，它是接着换一个工具再查，还是直接告诉用户“没查到”？返回报错，它是重试、换路径，还是把这个错误当成事实往下推？会改，才算有了循环；不会改，那只是一问一答。

`Agent = Model + Harness` 这个式子的重点是后半段。同一个模型同一套题，换一套 Harness，任务完成率能差出十几个百分点，有时候比换两代模型的差距还大。这也是这两年大家突然都在谈 Harness 的原因。

而这篇要回答的，是部件清单之外的那一个问题：**不是它有哪些部件，而是它该长多大**。
![image.png](https://developer.qcloudimg.com/http-save/yehe-12408676/f1622e338711d6830e005b45f0467c18.png)

看这张图的时候记住一件事：别把阶梯当采购清单，从上往下照着买一遍。它更像体检表，每一级对应一类已经发生过的问题，没出问题就不往上爬。后面每一节都会先讲“这一级是被什么逼出来的”，原因就在这里。

先把整张表摊开，后面六节再一级一级讲：

| 级 | 加什么 | 触发信号（出现了才加） | 提前加的代价 |
|---|---|---|---|
| L0 | 一个循环 + 轮次上限 | 需要模型连续调用工具 | 没有代价，但漏掉上限等于无限烧钱 |
| L1 | 边界处理：认出空转、失败按类回喂、给一切设上限 | 第一次出现空转或错误被吞 | 上限设太紧会掐断正常的多步任务 |
| L2 | 工具治理：粒度重封装、单位写进描述、失败可分、写操作幂等、权限穿透 | 工具多到模型开始挑错，或工具返回被当成事实 | 做一半比不做更危险，会给你已经治理过的错觉 |
| L3 | 上下文与记忆：压缩、卸载、经验沉淀 | 上下文开始撑爆，或要跨任务复用 | 未验证的推测进了记忆就变成“稳定事实”，反而更难删 |
| L4 | 护栏：审批、沙箱、出网门禁、留痕回放 | 要对外承担后果了 | 审批点到麻木等于没有；沙箱维护贵且断连真实环境 |
| L5 | 长时运行：状态外置、跨进程恢复、计划与验收分离 | 任务跨小时、跨天 | 复杂度陡增，短任务一次也用不上 |

第三列是最要紧的一列。选型时的习惯是问“这一级有没有用”，答案永远是有用；真正该问的是“我现在有没有撞上它要解决的那个问题”。

---

## 二、它是怎么长出来的：三代台阶

先花一点时间看历史，因为“该长多大”这个问题的答案藏在里面。

| 阶段 | 当时的 Agent 长什么样 | 撞上了什么 |
|---|---|---|
| 第一代 | 模型外面挂几个工具，问一句答一句 | 答完就结束，发现查错了不会回头改 |
| 第二代 | 有了循环，能连续调工具、边做边改 | 上下文撑爆、报错被吞、在原地打转 |
| 第三代 | 要让它进真实业务，承担后果 | 权限、沙箱、留痕、回放、验收 |

每一代的新东西都不是谁先设计出来再推广的，都是上一代在真实场景里撞了墙，才被逼出来的。轮次上限是因为有人烧了一晚上 token 才发现 Agent 在空转，失败分类回喂是因为错误被吞掉之后模型把异常当成了事实，留痕回放是因为业务方追问“这个结论怎么来的”答不上来。

一句话概括：**Harness 是被事故推着长的，不是被设计图推着长的**。

这条结论是全文的骨架，后面第五节会把它落到具体问题上。先记住它，因为它直接决定了阶梯表的用法：对着已经发生的问题一级一级往上加，不是照单全收。

还有一点要分清，免得读混：下面六节讲的六级，和刚才这三代不是一回事。三代是时间轴，讲这个领域怎么走到今天；六级是刻度尺，讲你现在的项目该停在哪一级。

---

## 三、L0：先让它转起来

客服场景的第一步：用户问“我的订单到哪了”，Agent 查一下订单接口再回答。

这一步最小，但已经踩在 Agent 的门槛上了。因为查完之后它要做判断：查到了就答，没查到要不要换个条件再查一次？这就是循环。

```java
// 示意写法，仅表达结构
while (!done && step < MAX_STEPS) {
    Thought  t = llm.think(messages, tools);   // 想：下一步用什么工具、传什么参数
    ToolResult r = tools.invoke(t.name, t.args); // 干：真的去调用
    messages.add(observe(r));                    // 看：把结果放回上下文
    done = llm.isFinished(messages);             // 判断：要不要继续
}
```

四步：想、干、看、判断。这个循环就是 Harness 的地基，后面五级都长在它上面。

**什么时候加**：需要模型连续调用工具才能完成任务的时候。一轮就答完的场景，比如“把这段话摘要一下”，直接调模型就行，不用上循环。

**提前加的代价**：循环本身没有代价，漏掉上限才有。上面那段代码里的 `MAX_STEPS` 看着不起眼，它是整个 Harness 里最便宜、也最不能省的一行。

---

## 四、L1：给一切设上限

循环转起来之后，最先出问题的往往不是能力，是边界。

常见的三种：

**一是在原地打转**。模型连续几轮用同样的参数调同一个工具，每次返回都一样，它还是接着调。人一眼能看出这是在空转，模型看不出来。对它来说每一轮都是新的尝试。跑一晚上，token 烧掉一大截，任务进度是零。

**二是报错被吞掉**。工具调用失败了，代码里 catch 住异常返回一个空值，模型拿到空值，理解成“业务上确实没有这条数据”，然后理直气壮地告诉用户订单不存在。最糟的情况从来不是报错崩掉，是错误安静地变成了事实。

三是上限不止轮次一处。单轮 token、工具调用次数、单次执行的墙钟时间、重试次数，每一项都得有数。

识别空转的写法不复杂，留个指纹比对一下就行：

```java
// 示意写法：连续 N 轮指纹相同，判定为空转
String fp = t.name + "|" + t.args;
if (fp.equals(lastFp)) { repeat++; } else { repeat = 0; lastFp = fp; }
if (repeat >= 3) {
    messages.add("你已经连续 3 次用相同参数调用同一工具，换个思路，或者向用户确认。");
}
```

**什么时候加**：第一次出现空转或者错误被吞的时候。如果不是撞上了就先别加。轮次上限属于例外，它应该和循环同一天写下去。

**提前加的代价**：这一级的代价小到可以忽略。硬要说的话，上限值设得太紧会让正常的多步任务被掐断，所以上限要给够，宁可松一点也别没有。

---

## 五、L2：工具要从“能调通”变成“调不错”

客服场景再进一步：Agent 不只要查，还要能发起退款、改地址、发优惠券。写操作一进来，工具治理就成了硬需求。

常见的一种误解是，接一层 MCP 就等于“有了工具”。公司里已有的业务 API 本来是给前端界面用的，Agent 拿不到现成的工具，中间隔着一次改造。最要紧的有三条：

- 粒度要重封装。一笔售后要查订单详情、支付记录、优惠信息、历史退款，四件事应该合成一个面向场景的工具，一次返回。让模型连着调四次再自己拼，每多一次调用就多一次出错的机会。
- 单位写进描述。金额单位是分还是元，日期是时间戳还是字符串，这些不写清楚，模型就猜。猜错的代价是退款退错金额。
- 失败必须可区分。查询失败时不能随便返回一个空结果，否则 Agent 会以为这笔订单不存在。写操作则要幂等，超时重试之后不能产生两条记录。

这三条没有一条是“接上 MCP”能自动解决的。

再往上一层是**权限穿透**：客服只能处理自己负责的订单，Agent 替他操作时应该受同样的限制。调用方从人变成了 Agent，不等于原来的授权规则可以跳过。

另外记住一条：**加能力靠加 Skill，不要改 Harness 核心**。一个 Skill 是一组相关工具加一份说明（什么时候用、怎么用、有什么约束），Harness 启动时只把 Skill 列表当菜单注入，模型需要哪个再加载哪个。这么做的好处是省 token：一个几十个工具的系统，全量预加载和按需加载能差出好几倍；更深的好处是能力可以横向扩，核心循环不用跟着动。

**什么时候加**：工具多到模型开始挑错，或者工具返回被当成事实往下用的时候。

**提前加的代价**：工具只调得通、描述写得很糙，模型照样把错误当事实。这一级“做一半”比“不做”更危险，因为它会给你一种已经治理过的错觉。

---

## 六、L3：上下文会撑爆，记忆会污染

工具多了之后，上下文就开始不够用了。

一个大工具结果几十 KB 塞进上下文，几轮下来窗口就满了。满了之后要么截断、要么报错，无论哪种，模型都会“忘记”前面讲好的东西。

处理手法就两招：压缩（把早期对话压成摘要，保留关键决策和结论）和卸载（大结果不进上下文，落到文件里，只把引用和摘要放进去，要用再取）。

再往上是记忆。跨会话记住用户偏好、沉淀上次踩过的坑，这些确实有价值。但记忆这一级有个反直觉的坑：

> 一条没被验证过的推测，不会因为被写进记忆就变成事实。它只会变得更难删。

模型在某次任务里猜了个结论，当时没验证，后来写进了长期记忆。下次再遇到，它会把这个推测当成稳定事实引用。而且因为它已经记住了，你很难追溯它最初是从哪来的。**先验证再沉淀**，这条顺序不能反。

**什么时候加**：上下文开始撑爆，或者确实需要跨任务复用某些结论的时候。

**提前加的代价**：就是上面那个污染问题。还有一条更日常的：压缩策略做得太激进，会把模型刚立好的规矩压没了，表现为“跑到后面几轮，前面讲好的第三条不作数了”。所以压缩要保留决策和约束，不能只留事实。

---

## 七、L4：能交代清楚，才敢上线

前面四级都是在让 Agent “更能干”。这一级不一样，它管的是“能不能对外负责”。

客服场景走到这里，Agent 已经开始真的发起退款了。某天有个用户投诉，说这笔退款不该批。业务方转头问你一句：**这个结论是怎么得出来的？**

答不上来，这套系统就上不了线。

留痕要满足的要求很具体：出问题时得能还原当时用的是哪个模型、调了哪些工具、用了哪个 Skill、配置是什么版本。**不能拿今天的配置去猜昨天发生了什么**。这一条没有任何框架会替你做。

这一级装的东西是四样：审批卡点、沙箱、出网门禁、留痕回放。最小可用的是留痕：一次调用记一条，把模型、工具、参数、返回、耗时都存下来，能按 session 回放就行：

```java
// 示意写法：一次工具调用留一条
audit.record(AuditEvent.builder()
    .sessionId(sessionId)
    .step(step)
    .model(modelName)          // 出问题的往往就是这个字段
    .toolName(t.name).args(t.args)
    .resultDigest(sha256(r.body))
    .durationMs(elapsed)
    .build());
```

**什么时候加**：要对外承担后果的时候。判据很简单：Agent 做的事，出了问题有没有人会被问责？有，就得加。

**提前加的代价**：这一级是全文代价最重的一级，两个坑都很实在。审批点太多会点到麻木，弹窗超过人类注意力的承受范围之后，用户看都不看直接点同意，这道防线等于没有。沙箱则是又贵又断连：维护成本高，它还切断了与真实环境的连接，很多调试手段在里面失效。除非确实有不可信代码要跑，或者有多租户隔离的硬要求，否则别上。

---

## 八、L5：只有当任务跨小时、跨天

最后一级。前面五级的场景都是“分钟级”的：用户问一句，Agent 几分钟内干完。

如果你的任务要跨小时甚至跨天，比如把这批三千条工单全部分类处理完、连续盯一周的异常告警，那要面对的问题就换了性质：

- 容器重启了，进度全丢。所以状态必须外置，不能放在内存里。
- 换个进程继续跑，得能恢复完整上下文。所以要有 checkpoint 和跨进程恢复。
- 跑了几小时之后，Agent 容易偏离最初的目标。所以判断、执行、记录三件事要拆开：一个阶段定计划，一个阶段执行，另外单独记录，不能让执行的 Agent 自己判定自己做得对不对。

**什么时候加**：任务时长跨到小时级以上。

**提前加的代价**：复杂度陡增。托管架构要单独维护一套调度与恢复机制，而如果不跑长任务，这套东西一次也用不上。大部分业务 Agent 根本到不了这一级。

---

## 九、三种“长过头”的代价

“长过头”和“提前加”是同一件事的两面。上面六节讲的是每一级提前加要付什么代价，这里挑三个最容易加错的项单独说。它们的共同点是：加的时候都觉得更稳妥。

**一、审批不是越多越好**。前十次弹窗，用户会认真看；第一百次，扫一眼点同意；第一千次，直接想办法关掉弹窗。审批频率超过注意力的承受范围之后，“同意”就变成了肌肉记忆，这道防线名存实亡。这不是交互设计的问题，是人类注意力的物理极限。正确的做法是只在真正不可逆的动作上设卡：退款、删数据、发外部消息，其余的靠事后留痕回溯。

**二、记忆不是越早越好**。上一节讲过污染的问题，这里补一条：记忆应该是慢慢沉淀出来的，别先搭好一套等它填。没有真实任务喂进去，先建一套记忆系统，最后存进去的大概率是噪声。

**三、多 Agent 不是默认选项**。单 Agent 加几个好工具，能覆盖大部分任务。这里有个容易搞混的地方：**子 Agent 的上下文隔离不等于权限隔离**。上下文分开只是各看各的，权限、数据范围、代码仓库分支这些，是另一回事，不会因为拆成了多个 Agent 就自动分开。

---

## 十、回到你的场景：该停在哪一级

六级看完了，回到客服。判断顺序建议按下面三步走，比对着阶梯表硬挑要准。

**第一步，量场景**。还是上一篇那四把尺子：步骤数、跨会话记忆、隔离执行、留痕与回溯。前三条决定你要爬到第几级，第四条决定 L4 那一层要从哪天开始有。

**第二步，对着已发生的问题定级**。这是本篇和别的文章最不一样的地方：不要问这一级有没有用，要问“我现在要加的这一级，是被哪个已经发生的问题逼出来的”。速查表第三列就是干这个用的，从上往下扫，命中最高的那一条就是你要停的级：

- 还没跑起来 → L0
- 出现过空转或错误被吞 → L1
- 工具有写操作了，或返回被误读 → L2
- 上下文撑爆了，或要跨任务复用 → L3
- 要对外承担后果 → L4
- 任务跨小时跨天 → L5

多条同时命中很正常，取最高的那条。但要注意，往上每一级的代价你也一并接下了——爬到 L4 意味着 L4 那栏写的“审批点到麻木”和“沙箱断连真实环境”都是你要面对的。

答不出“被哪个问题逼出来的”，就先别加。

**第三步，看一眼边际成本再决定要不要继续爬**。有一组数字可以参考：通用能力那层一次性投入是 373 行，之后新增一个业务场景 239 行，**其中治理相关的改动是 0 行**。

这组数字说明两件事。一是治理层属于一次性投入，不用每个场景重造一遍，所以自建治理层等于重复造轮子这个担心不成立。二是每加一个新场景，长出来的是业务能力，治理代码一行没动，说明它确实停在了该停的位置。

那个项目最后停在 L4，没上 L5 的长时运行。原因很简单：业务场景步骤并不长，没有任何问题在逼它往第五级爬。这正好反过来验证了阶梯表的用法：每一级都是被上面某个已发生的问题逼出来的，没有问题逼它，就不长。
![image.png](https://developer.qcloudimg.com/http-save/yehe-12408676/99dc13cd094189fd1247a36ff521cb40.png)

---

## 十一、可带走的东西

**六级阶梯**：L0 循环、L1 边界与上限、L2 工具治理、L3 上下文与记忆、L4 护栏与留痕、L5 长时运行。每加一级之前，先说出它是被哪个已发生的问题逼出来的。

**一条自检问法**：现在要加的这一级，是被哪个已经发生的问题逼出来的？答不上来，就先别加。

**三个别急着加**：审批别铺太密、记忆别先建、多 Agent 别当默认。

**一句可以贴在墙上的话**：Harness 长到哪一级由场景复杂度决定，长过头不是更安全，是更难维护。

---

回到开篇那个客服场景。

只做“订单到哪了”，L0 加 L1 就够了，轮次上限别省。要做退款这类写操作，往上爬到 L2，工具的失败语义和幂等先做扎实。要是还要跨会话记住客户、批量处理，L3 的上下文治理躲不掉。而只要这个 Agent 的动作会产生后果，比如退款、改数据、发消息，L4 的留痕就从第一天起就得有，跟场景简单不简单没关系。

L5 那个台阶，大部分业务 Agent 这辈子都不会爬上去。这不是偷懒，是因为没有问题在逼它。

模型决定能力的上限，Harness 决定你能兑现多少。而 Harness 停在哪一级，关系着这套东西半年之后你还维护不维护得动。


上一篇我们把 Java 侧六个框架分成了三层台阶，最后留了个尾巴：选完层之后，这套东西该长多大。

Agent Harness 演进：六级阶梯，一篇讲清该长到哪一级

这篇讲 Harness 该长到哪一级。文章把 Agent 运行时从简到全分成六级：循环、边界与上限、工具治理、上下文与记忆、护栏、长时运行。每级配了加什么、什么时候加、提前加的代价。判据只有一条：能说清这一级是被哪个已发生的问题逼出来的，才往上爬。

人工智能

架构设计

开发工具

Agent Harness从L0到L5六级阶梯，按已发生问题定级而非照单全收。L0循环+轮次上限打底，L1防空转与错误被吞，L2工具治理（粒度、幂等、权限），L3上下文压缩与记忆验证，L4留痕审批沙箱，L5长时运行。每加一级须答出被哪个问题逼出，答不出就不加，避免过度建设导致维护负担。

代码解释

容器

Agent

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Agent Harness 演进：六级阶梯，一篇讲清该长到哪一级-腾讯云开发者社区-腾讯云

Agent Harness 演进：六级阶梯，一篇讲清该长到哪一级

Agent Harness 演进：六级阶梯，一篇讲清该长到哪一级

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐