Agent 的信任问题：从 Skill 固化到可测性工程

本文属于《我和苏Claw底的理想国》系列文章。该系列作品都是是作者和 OpenClaw 的对话，辩论，分析，甚至是对骂的的内容的整理。

这篇文章来自一次关于 Agent 演化史的对话。我们从 Function Calling 聊到 MCP，从 MCP 聊到 Skill，然后在"Skill 的固化和灵活性"这个问题上停下来，顺着这条线一路聊到了 Agent 的信任问题。

一、为什么会有 Skill 固化的问题？

要理解这个问题，得先说清楚 Skill 是在解决什么。

MCP 解决了工具接入的标准化问题——工具开发者只需要实现一次 MCP Server，所有支持 MCP 的 Agent 都能用，不需要为每个框架单独适配。但 MCP 有一个很实际的缺陷：每次会话开始，不管工具用不用得上，所有工具的完整描述都会被一股脑加载进 context。 工具一多，context 就被撑大，模型选工具的准确率也会下降。

Skill 在这之上做了两件事。第一件是用简短的 description 替代冗长的方法描述，做延迟加载——只把"这个能力存在"这个信息放在 context 里，完整的使用知识在需要的时候才加载进来。第二件更关键：把自然语言流程和多工具调用固化成知识。 MCP 的工具是原子的，怎么组合这些工具来完成一个任务，是模型在运行时自己推理出来的，每次都要重新推理，结果不稳定，消耗大量 token。Skill 把"怎么组合"这件事提前想好了，固化成流程知识，模型不需要每次从零推理，直接按照 Skill 里描述的流程走。

这是一个很深刻的转变：从"模型在运行时推理怎么用工具"，变成"人提前把怎么用工具的知识编码进去，模型按知识执行"。

但这个转变有一个代价：Skill 把流程固化了，灵活性就降低了。 遇到 Skill 没有覆盖到的场景，Agent 可能比纯 MCP 更僵——它会试图套用最接近的 Skill，而不是从头推理一个新的解法。固化和灵活性之间，存在一个天然的张力。

二、这个张力怎么解？用 Skill 解决 Skill 的问题

这个张力的解法，其实已经在路上了：用 Skill 解决 Skill 的问题，等 Agent 学会自举迭代。

自举迭代意味着什么？Agent 不只是执行 Skill，而是能观察自己执行 Skill 的过程，发现哪里不够好，然后修改或者创建新的 Skill。这个循环闭合之后，人就从"Skill 的编写者"变成了"目标的提供者"。

但这里有一个递归问题：Agent 用来自举迭代的那个能力本身，也是一个 Skill。谁来写第一个"能创建 Skill 的 Skill"？还是人。所以自举不是从零开始的，它需要一个人工注入的起点——一个足够好的元 Skill，让 Agent 能从这里开始爬升。起点的质量，决定了 Agent 能爬多高。

**现在skills已经能做自举迭代了，模型的训练中也大量在运用自举迭代，**这两条路已经同时在跑了。Skill 层的自举——Agent 观察自己的执行过程，发现问题，修改 Skill——这个闭环在工程上已经可以做到了，是局部的、快速的、可观测的。模型训练层的自举——用模型生成的数据来训练模型本身——o 系列、R1 背后都有这个逻辑，是全局的、缓慢的、难以解释的。

两条路的分工很清楚：Skill 层做快速迭代，模型层做能力跃迁。这个分工会长期稳定。LLM 是引擎，Skill 或者未来某个相似的东西是机组的其他部件，分层是工程上必然长期存在的事情。哪怕后面我们感知不到了，也会有隐藏的分层——就像你现在用 TCP/IP，不会去想它底下还有以太网帧、还有物理层的电信号。分层没有消失，只是被封装得足够好，让上层的人可以假装它不存在。

三、引擎再强，也需要跑道

分层稳定了，但 Agent 能上多大的跑道，还有另一个问题没解决。

表面上看，Agent 现在缺的是"可信任的执行环境"——Agent 能做的事越来越多，但它在哪些边界内可以自主决策、哪些事情必须人来确认，这套机制还很粗糙。现在的做法基本上是靠 Prompt 里写"不要做 X"，或者在外面套一层人工审批，两种方式都不够好。

但这里有一个因果方向的问题需要先纠正："没有可信任的执行环境"是结果，不是原因。

真正的原因是 Agent 本身不可信——你不知道它为什么做了这个决定，不知道它下一步会做什么，出了问题也不知道从哪里追溯。黑盒、解释性差、不可控，这才是根本。在这种情况下，给它一个高权限的执行环境，等于把一个黑盒放进了生产系统。没有人敢这么做。

所以问题的根本不是"怎么建执行环境"，而是"怎么让 Agent 变得可解释、可预测、可追溯"。

四、怎么信任一个无法完全理解的系统？

这里有一个很深的矛盾：Agent 的能力来源于它的不确定性。

模型之所以能处理开放性任务、能在没有明确指令的情况下推理出解法，恰恰是因为它不是一个确定性的状态机。你没办法像审查代码一样审查它的"决策逻辑"，因为它的决策逻辑不是代码，是权重。现在的解法是在黑盒外面加透明层——让模型输出 chain-of-thought，把推理过程显式化。但这个 chain-of-thought 本身也是模型生成的，它说它是这么想的，但它真的是这么想的吗？没有人能保证。

但"无法理解"不等于"无法信任"。流体空气动力学就是一个经典的例子。每一个按照空气动力学设计出来的飞行器，都不能从第一性原理推导出"它一定能飞"，必须通过风洞实验、试飞、各种保障试验后才能正式飞行。信任不是来自于理解，而是来自于在受控条件下的反复验证。

Agent 也可以走这条路。你不需要理解它为什么做了这个决定，你需要的是：在足够多的场景下测试它，知道它在哪些条件下可靠，在哪些条件下会失效，然后把它部署在它可靠的那个范围里。

五、历史记录能建立信任吗？一场来回的争辩

顺着这个思路，可以推出一个结论：一个 Agent 在某个任务类型上跑了一万次，错误率低于某个阈值，可追溯，可回滚——这个积累本身就是信任的来源。就像一个飞行员，不是因为你理解了他的神经系统才信任他，而是因为他有一万小时的飞行记录。如果这个逻辑成立，Agent 的信任问题最终会变成一个运营问题，而不是一个技术问题。

但这个逻辑有几个地方是脆的，值得认真驳一驳。

驳点一：历史记录的有效性依赖分布稳定，但 Agent 的输入分布天然不稳定。

飞行员的一万小时飞行记录是有效的，因为物理规律不变——今天的大气和十年前的大气遵循同样的方程。但 Agent 面对的输入是自然语言，自然语言的分布会随着用户、场景、时间不断漂移。历史记录建立的置信度，在分布漂移面前是脆的。

不过这个驳点可以被反驳回来：飞行员在地球大气环境是稳定的，在外星大气环境也会失能。Agent 也是这样——虽然自然语言的分布会漂移，但可以保证在某一个特定的分布范围内，历史经验是稳定的。建立输入的栅栏，把 Agent 限定在它可靠的输入域里工作，分布稳定性的问题就可以通过约束输入域来解决。

驳点二：历史记录多，不等于盲区少。

飞机的失效通常是随机的，概率可以用统计模型描述。但 Agent 的失效可能是系统性的——某一类输入会稳定地触发错误行为，而这类输入在测试集里恰好没有覆盖到。这种系统性失效不会随着运行次数增加而被发现，它会一直潜伏，直到那个特定的输入出现。

这个驳点在飞机工程上其实也存在。大气湍流在没有足够测量手段之前，对飞行员来说也是黑盒。飞机的可测性不是天生的，也是人一点一点做出来的工程积累——可测性是被工程化出来的，不是物理规律自带的礼物。所以后面也可以做自然语言输入的可测性工程，去做输入的可测、可分析，就像飞机工程积累出大气的可测性一样。

驳点三：模型更新会让历史记录失效。

飞行员的飞行记录是连续积累的，他的能力在记录期间是相对稳定的。但 Agent 背后的模型会更新，每次更新都是一次能力的重新分布。之前积累的历史记录，对新版本模型的行为没有任何保证。信任需要重新建立，但运营体系可能没有意识到这件事。

这个驳点目前没有被完全反驳掉。它是三个驳点里最硬的一个。

六、输入栅栏：把问题从"全域可信"变成"域内可信"

驳点一被反驳之后，"输入栅栏"这个概念浮出来了，值得单独展开。

栅栏的思路是：不让 Agent 处理栅栏外的输入，或者遇到栅栏外的输入就拒绝、降级、转人工。这把问题从"怎么保证 Agent 在所有输入下可靠"，变成了"怎么定义和守住 Agent 的工作域"。这是一个更务实的工程转向。

但栅栏的边界怎么定义，谁来守？

飞行员的工作域边界是物理的——大气密度、温度、压力，这些参数是可测量的，超出范围仪表会报警。边界是客观存在的，不需要人来判断。

Agent 的输入栅栏是语义的——"这个输入在栅栏内还是栅栏外"，这个判断本身就需要一个分类器来做。而这个分类器，很可能也是一个模型。于是引入了一个新的信任问题：守栅栏的那个系统，本身可信吗？如果守栅栏的是规则系统——关键词过滤、正则匹配——覆盖率会很低，语义漂移一点就绕过去了。如果守栅栏的是另一个模型，你又回到了原点。

所以输入栅栏是一个好的工程方向，但它把问题往前推了一步，没有终结问题。

七、信任问题没有统一的答案，但有可解决的边界

争辩到这里，有一个更根本的差异浮出来了：自然语言的输入空间是开放的，而且是离散的、非连续的。"帮我订一张机票"和"帮我订一张机票，但如果价格超过500就算了"，语义距离很近，但对 Agent 的行为要求完全不同。更关键的是，新的语义组合可以无限生成，不像物理参数有自然的上下界。所以"输入可测性工程"是可以做的，但它的覆盖率天花板，可能比飞机低得多。

但与其争论"能不能做到飞机那种可测性"，不如问"在自然语言输入上，可测性工程能做到什么程度，这个程度够不够支撑某个具体的 Agent 应用"。这样 AI 的落地和应用“跑道”就是一个工程问题，而不是一个哲学问题。工程问题就有可以有解决方案。

不同的应用对可测性的要求不一样。一个帮你查天气的 Agent，输入域窄，可测性容易做到足够好。一个帮你做法律合同审查的 Agent，输入域宽，可测性要求极高，工程难度完全不同。

Agent 的信任问题没有统一答案，它的答案取决于具体的应用场景和可接受的风险边界。 这反而和飞机是一样的——客机和战斗机的适航标准完全不同，不是因为物理规律不同，而是因为风险边界不同。

Agent 能上多大的跑道，对应的就需要通过对应的实战实验。这不是一个等待技术突破的问题，而是一个需要持续做工程积累的问题。