关于 Agent Failure Attribution 与 Runtime 结构的一个问题

[goatliamia]

老师您好！我是最近在学习agent的学生，最近在 DSH 上做了一个很小的 Runtime 插件实验，过程中发现了一条和 Life-Harness 很有意思的交叉点。

目前观察到：有些原本看起来需要 Model 决策的步骤，如果当前 Event 已经提供了足够确定的事实，其实可以直接从 ReAct loop 里消掉 不出现这一轮；而另一些行为虽然在很多 trajectory 中反复出现，却未必应该直接被固化成 Harness 行为。

所以想请教一个很具体的问题：

在 Life-Harness 里，你们是如何区分“环境本身稳定存在的结构”和“某个模型反复出现的行为模式”的？

尤其是随着模型能力快速变化，一些过去需要 Skill / Prompt / Harness intervention 的行为，后来可能已经被模型本身吸收了。

我们最近的实验在这里：
https://github.com/goatliamia/dsh-runtime-react

很想听听老师您对这个边界的看法。

[Tianshi-Xu]

您好，感谢你的提问！这个问题是一个很重要且是harness的核心问题，目前我的结论是：只有领域足够垂直且存在较为固定的流程（例如客服agent/助手agent），最好这个流程与通用任务还不类似，此时该agent提供的确定性功能可以稳定的转化为可靠的harness来弥补模型性能的缺失，而且通用模型在垂类场景知识本身也匮乏。除此之外的harness组件，除非具备实时推理能力（例如实时推理检索选择skill），否则很难泛化到各种不同的任务和不同的模型中，为通用任务设计的harness随着模型能力的提升都会被不同程度内化，因此目前system prompt在做减法。

如何准确、低成本地判断一个harness组件已经被模型吸收也是目前一个非常重要的问题。

[goatliamia]

感谢老师回答！
如何准确、低成本地判断一个 Harness 组件是否已经被模型吸收，我觉得这可能比单纯讨论“该不该做 Harness”更重要。

最近在 DSH 上做的实验其实也比较谨慎。思路不是先假设某类 Harness 能力已经被模型吸收，然后把它删掉，而是从真实 trajectory 里反过来看：

如果某一步的前置事实已经足够确定，下一步 transition 也已经唯一确定，那么这一步是否根本不需要再让 Model 做一次 ReAct decision？

目前我们已经实验到了一个比较小的例子：Runtime 根据 Event-derived state 判断前一步之后世界是否已经达到某个确定状态，在这种情况下，可以直接承接下一步 transition；而如果状态仍然 unknown、存在多个选择，或者只是需要语义判断，就仍然交给 Model。

所以现在我们更倾向于把它理解成：

不是“用 Harness 替代 Model”，而是不断寻找那些已经没有 decision freedom 的步骤，并把它们从 Model loop 中消掉。

这可能也是一种判断 Harness 是否正在被模型吸收的方法：如果一项 Harness 机制越来越多地只能处理 Model 已经能够稳定完成的决策，那么它的必要性可能就在下降；反过来，和外部世界的确定性事实、执行边界相关的部分，可能不会因为模型变强而自然消失。

我们也还在继续验证，暂时不会把这个结论推广得太远。也没有进入真实的业务场景，也很想看看有没有更好的方法来判断这个边界，期待与老师的继续交流！

[goatliamia]

我还在继续学习您的研究，有些问题想继续请教您一下
比如Life-Harness 里最终固定下来的几个 intervention，有两个地方让我觉得和我最近实验中验证到的点接近，想请教一下老师的看法。

一个是 Action Realization。如果某类 action 在进入环境前已经可以由确定性的 contract / tool state 唯一判断为无效、需要 canonicalize，或者重复执行没有意义，那么我在想，这类是不是可以进一步向前推一步：不只是阻止 Model 已经提出的动作，而是直接消掉本来就没有新增决策价值的这一轮模型决策？

另一个是 Trajectory Regulation。其中像确定性的重复、无效 retry、已经确认 effect 发生后继续执行这类情况，我感觉也可能存在类似的空间：不是替 Model 做新的判断，而是当 Event 已经足够确定时，直接压掉这一轮不再产生有效信息的 ReAct loop；但像恢复策略、换路径等仍然属于需要 Model 判断的部分。

主要想不明白的问题是：哪些 Harness intervention 本质上是在帮助 Model 做决策，哪些其实是在消掉已经不存在 decision freedom 的一轮 loop。

既然 Agent 最终仍然是在计算机这个高度确定性的世界里运行，那么有些现在看起来需要 Harness 来解决的问题，会不会其实可以借鉴传统软件工程已经存在很久的思路？

比如幂等、状态机、CAS、precondition / postcondition、权限、schema 校验、事务、事件溯源等。它们通常并不要求执行者“理解”这些规则，而是直接把确定性的边界落实到系统里。

[Tianshi-Xu]

哪些 Harness intervention 本质上是在帮助 Model 做决策，哪些其实是在消掉已经不存在 decision freedom 的一轮 loop。 我理解这个是两个问题，第一个问题是harness帮助模型做决策，这个work的前提是harness一定比模型还聪明，也就是规则比较确定的场合，否则泛化性一定是有挑战的，这一点我认为是harness主要的价值，在我们确信的领域，我们有自信写的harness比模型自己探索要好。第二个问题是消掉本来就没有新增决策价值的这一轮模型决策，我觉得harness的价值还是在提升性能同时降低成本；当前模型很需要自我纠错能力，也就是他发现已经出错了，可以自我恢复，无法强求一整个链路每一步都是正确的；我去年的工作CLEANER尝试过在训练过程中消除错误tool call，重新产生正确的，但发现效果一般，核心是模型看不见错误，失去了纠错能力，所以消去当前轮次决策需要小心，哪怕该决策没什么用处，强大的模型还是可以依赖他进行自我纠正，所以life-harness仅做错误提醒。不过，如果错误轮次占据极大上下文，进行压缩可以提升模型的性能，同时压低成本。
关于和软工的一些对比，我觉得是的，如果规则确定，完全可以固化为harness，例如对数据库的操作本身存在强逻辑性，非法操作可以直接识别进而阻止。

[goatliamia]

非常感谢老师指导，“错误本身是信息”的这个方向，其实我有设计这个机制，不是把错误的探索这一轮压缩掉，而是尽量把真实的错误/状态变化暴露给 Model，让它自己完成纠错。

在项目的实验里，主要也是在区分这两种情况：

一类是 tool 结果和真实状态不一致。这个时候 Runtime 不替 Model 做恢复决策，而是把事实暴露出来。实验里已经看到，Model 知道“实际上没有发生什么”或者“实际上已经发生了什么”之后，行为会发生变化。不过目前样本还比较少，也不想过度外推。

另一类才是昨天才发现很有意思的 loop 上的消除：Model 已经选择了一条路径，而后续 transition 已经被当前状态确定，模型的意图已经确定了一个选择，带出的动作与当前相同，这时候会压缩掉了他的动作直接执行。和tool设计的思路其实很像。

实验主要是在两个步骤 事前的不变和事后的变化：

错误需要被暴露，因为错误本身可能提供 self-correction 的信息；
模型已经确定的路径则不一定需要每一步都经过一次 Model。

另外，其实我这里给老师您说错了一个信息：我现在说的 Harness 是收窄了很多，主要是在观察 Model 和确定性软件系统之间的边界，并没有试图涵盖工具控制、工作流、完整 orchestration 等更大的 Harness 范畴。是我自己逃向了一个更确定的领域。

因为我自己对业务场景的复杂程度也深有感触

比如在客服 Agent 里，用户说“退款还没到账”。表面上看都是一个问题，但计算机系统里可能发生的是完全不同的事情：

可能数据库里的退款状态确实还是 pending；也可能支付系统已经完成，只是回调没有回来；也可能事务已经提交，但接口刚好超时；甚至可能数据库已经更新了，只是缓存还是旧状态。

这几个情况最后都可能表现成 Agent “一直查询退款状态”。

所以我比较好奇的是，在您的研究中，如果发现某种行为通过加入 Harness 后变好了，是怎么判断解决的是哪个问题？

也就是说，除了看 Agent 的表现本身，会不会进一步去看背后的计算机系统状态？

“模型不知道”“真实的系统本身状态没确定”和“真实的系统其实已经确定、只是没有把事实正确传给模型”这三个目前是我在学习中很想去确认的点。

[Tianshi-Xu]

你举的这个例子可能还涉及工具本身的可信度，tool返回的信息应当尽量准确，这也属于harness的一类，例如支付没有回调、缓存未更新等问题我理解是确定性的，可以通过设计更好的tool机制来返回给agent一个更可信的结果，避免agent因为环境返回的信息不足，只能自行猜测；这也是我认为垂类场景必须优化一下harness的原因。“除了看 Agent 的表现本身，会不会进一步去看背后的计算机系统状态” 这个是会的，life-harness的Action Realization Layer就是根据具体场景的确定性规则，提前预制/完善tool call机制，这也是因为在我们评测的tau-bench场景中，明显存在大量的非法系统状态，而且可以提前检测避免。

[goatliamia]

感谢老师指导！我也会继续学习的，说起来您对法律场景的agent应用有研究吗？这类我的理解既有高度的固定流程，又涉及到复杂的逻辑语义判断，感觉是个很复杂的场景。

[Tianshi-Xu]

不客气，我对法律agent了解可能不太多，我目前还是主攻coding场景。不过我认为金融（已经是）和法律agent会是一个超级大的专业市场