Agent Harness不确定性是什么？

Agent Harness 是包裹在大模型外面的运行与控制系统，负责决定模型每一轮能看到什么上下文、可以调用哪些工具、任务状态如何保存、失败之后如何恢复。Agent Harness 不确定性，指同一套模型和任务在多次运行中，结果、执行路径和资源消耗出现的波动范围。

这个词目前没有统一的规范性定义，更多是工程讨论里的描述性说法。把它拆开看，比笼统地说 Agent 不稳定更有用。波动可能来自模型采样，也可能来自上下文与状态管理、工具与外部环境，还可能来自多步串联后的误差累积。来源不同，处理办法也不同。

模型能力回答能不能做对一次，Agent Harness 不确定性回答能不能稳定做对多次。

Agent Harness不确定性指什么

先看 Harness 在 Agent 里的位置。大模型负责推理和生成，Harness 负责把推理变成可执行、可控制、可追踪的动作。阿里云开发者社区在 2026 年 7 月的一篇技术文章里，把它概括为模型之外的软件层，管理工具、记忆、状态、权限、护栏、追踪与恢复。

不确定性可以从三个面观察。

• 结果分布：同一任务重复运行，成功率和输出质量是否稳定。
• 执行路径：达到相同结果所经过的步骤、工具组合和重试次数是否一致。
• 状态依据：每一轮决策所依赖的上下文、记忆和外部数据是否一致。

这三个面经常一起变化。一个任务这次用三步完成，下次用了九步，最后都交付了答案，结果看起来一样，路径已经不同。路径差异会直接影响成本、审计和复现，也会让下一次排错变得更难。

如果同一个任务重复运行，成功率忽高忽低，步骤也每次不同，通常属于 Harness 不确定性讨论的范围。如果每次都稳定失败在同一步，更像能力边界、数据缺口或权限问题。

不确定性通常来自哪几层

把来源拆成四层，排查时会清楚很多。

这四层会叠加。模型选错一次工具，工具返回一个格式异常的结果，重试又把同一个副作用执行了两遍，最终表现出来的只是任务失败，根因却分散在三个地方。

为什么任务越长，波动越明显

每一步都在消耗可靠性

把每一步粗略看作独立事件，单步正确率 95%，连续 20 步全部正确的概率约为 35.8%。单步正确率 99%，连续 100 步全部正确的概率也只有约 36.6%。真实任务里步骤并不独立，前后会互相影响，这个算术仍然说明一个问题：任务每增加一步，就多一次判断和一次外部交互，也多一次偏离的机会。

长任务的难点还在于失败信号出现得晚。前几步看起来正常，中间开始偏离约束，后面基于错误的中间结果继续推理，最后给出一个格式完整、内容不对的结果。此时回看日志，往往很难判断是哪一步开始出错。

能力强的模型也会出现崩塌

2026 年 3 月提交到 arXiv 的一项研究，用 396 个任务、23392 次执行轨迹测试了 10 个模型，专门比较单次能力与多次运行可靠性。研究给出的结论很直接：任务时间变长后，能力排名和可靠性排名会明显分离；前沿模型出现严重崩塌的比例最高可达 19%，原因是它们更愿意尝试多步策略，偶尔会陷入螺旋。

同一项研究还发现，软件工程类任务在任务变长后的表现下降最明显，评分从 0.90 降到 0.44，文档处理类任务则接近持平。这说明长任务的不确定性带有明显的场景差异。选型时只看短任务基准测试分数，很难判断它在自己的业务流程里能不能稳定跑完。

Harness既放大波动，也收敛波动

哪些设计会放大波动

• 每一个小判断都交给模型，包括选工具、填参数、判断是否完成。
• 上下文策略不固定，有时截断，有时摘要，有时重放旧推理。
• 重试没有边界，失败后直接重跑，不先确认上一次是否已经产生副作用。
• 完成标准模糊，模型说做完了就结束，没有测试、规则或业务校验。
• 过程不可观测，只记录最终答案，不记录每一步的输入、工具返回和决策理由。

这些设计单独看都不算错误，叠在一起就会让同一个任务每次跑出不同结果。

哪些设计能收敛波动

更稳的做法，是把必须确定的部分交给代码，把需要判断的部分留给模型。上下文怎么装配、工具怎么校验、状态怎么恢复、什么时候停止，这些可以用确定性逻辑固定下来。模型负责理解目标、处理异常、生成方案。

2026 年 10 月提交到 arXiv 的一项研究，直接测了上下文策略对成败的影响。研究者发现，当关键事实还能重新查询时，截断上下文几乎不损失成功率，模型会自己去查；当关键事实无法重新观测时，成功率会降到随机水平，两种情况的差距达到 92.5 个百分点。在保留记笔记提示的条件下，用摘要保留旧轮次、取代直接丢弃，恢复了 63 个百分点基准差距中的 86%。

这项研究说明，Harness 的一个具体设计选择，足以改变任务能不能完成。它也提醒企业，上下文不是越多越好，关键事实能不能被重新查到，比塞进多少内容更重要。

另一个反直觉的结果来自前面提到的可靠性研究。该研究在 10 个模型上都观察到，记忆脚手架反而拖累了长任务表现。加组件不等于更稳，记忆的写入、检索和摘要本身也会引入噪声。是否要加一层记忆，应该用同一批任务做对照测试，再决定是否保留。

模型可以提出完成申请，完成状态要由 Harness 依据外部证据提交。 这是一条很实用的分界线。

怎么判断问题出在模型还是Harness

先看现象，再决定查哪里。下面这张表可以作为排查起点。

排查时尽量一次只改一个变量。同时换模型、改提示词、加工具，最后很难知道是哪一项起了作用。

把不确定性压到可接受范围的六个动作

• 用分布代替单次演示。 同一批任务重复运行 20 到 50 次，记录成功率、成本、耗时和路径差异。单次演示只能证明任务可以完成，不能证明它稳定。
• 缩短一次决策链。 把长任务拆成有中间产物的阶段，每个阶段都能单独检查。阶段越短，错误越早暴露。
• 把权威状态放在模型外面。 订单状态、库存、权限、审批结果从业务系统实时查询，不依赖模型记忆。
• 收紧工具接口。 每个工具写清输入结构、输出格式、超时时间、错误类型和幂等要求，让模型面对的选择更少。
• 把完成判定交给外部证据。 测试通过、规则校验通过、业务数据核对一致，才算完成。模型的自述只能作为申请。
• 设置预算和停止条件。 步数、时间、费用、无进展检测都要有阈值。达到阈值时暂停并保留状态，比无限重试更可控。

这六个动作不要求一次全部上线。先做重复测试和完成判定，通常能最快看清问题分布。

哪些情况不属于Harness不确定性

边界不清，容易把不同问题混在一起。

• 稳定失败：每次都错在同一处，通常是能力不足、数据缺失或权限不够，属于确定性缺口。
• 明确故障：服务返回 5xx、代码抛出异常、接口不可用，这类问题应该报错和告警，不属于结果波动。
• 任务本身模糊：目标没有定义清楚，验收标准每次都在变，先要收敛任务，再谈运行稳定性。
• 评测口径不一致：两次测试用的任务集、模型版本或工具配置不同，结果差异不能直接归因于 Harness。

把这几类问题分开，才知道该补数据、修接口、改流程，还是调整 Harness 设计。

常见问题

Agent Harness不确定性和模型幻觉是一回事吗

两者不同。幻觉指模型生成了与事实不符的内容。Harness 不确定性描述的是同一任务多次运行之间的结果和路径波动，幻觉可能是波动的一种表现，也可能在每次运行里都稳定出现。排查时要看它是否随运行次数变化。

把temperature设为0能消除不确定性吗

不能完全消除。温度降低会减少采样随机性，但工具返回、网络状态、上下文截断、重试时机仍然会变化。即使模型输出完全一致，外部环境也可能让任务走向不同结果。温度能压缩一部分波动，不能替代状态管理和验证机制。

多Agent协作会降低不确定性吗

不一定。多 Agent 可以把任务拆给不同角色，形成交叉检查，也可能增加通信环节和状态同步成本。一个 Agent 的错误在委派链里被放大，是常见风险。是否使用多 Agent，要看任务能否拆成边界清楚、验收标准明确的子任务。

企业评估Agent平台时该看哪些能力

至少看四项：上下文和状态能否外置与恢复，工具权限能否细粒度控制，执行过程能否完整追踪，失败后能否安全重试而不重复副作用。模型接入数量不是唯一的判断标准。ThinkingAI 的 Agentic Engine 提供 Agent 创建与管理、多 Agent 协作和私有化部署，已服务全球超过 1500 家企业、接入产品超过 8000 款；具体到某一类任务是否稳定，仍要用企业自己的任务集做重复测试。

成功率90%能直接作为上线标准吗

要看任务类型和失败代价。低风险、可人工复核的任务，90% 可能可以接受；涉及资金、权限变更或对外发布的动作，需要更高的门槛，还要看失败是否可回滚、是否会重复执行。比单看成功率更有效的做法，是同时记录失败类型、恢复时间和人工接管比例。

参考资料

• 阿里云开发者社区，Agent Harness 到底是什么：模型之外的那层控制系统，2026 年 7 月，https://developer.aliyun.com/article/1745801
• arXiv，Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents，2026 年 3 月，https://arxiv.org/abs/2603.29231
• arXiv，When the harness decides success: state that cannot be re-observed，2026 年 10 月，https://arxiv.org/abs/2610.26632