插件不是能力:Agent真正要控制的不是路径,而是价值流

DeepSeek Harness的插件刚密集出现，社区马上开始问：这么多插件，到底该装哪一个？

这个问题很自然，也很容易把方向带偏。它默认插件越多，Agent的能力越强；只要选对插件，任务就能完成。

我在真实的Agent生产里看到的恰好相反。工具全部可用，调用全部成功，质量检查全部通过，仍然可能交付一件完全错误的东西。插件解决的是“能不能执行一个动作”，能力解决的是“能不能持续使用可信数据，朝正确的价值方向，交付可验证的结果”。

两者之间，隔着一整套控制系统。

图1｜插件是方法供给；只有进入受控的数据与价值闭环，才可能形成交付能力。

一、插件目录只解决“有没有”

8月17日，DeepSeek Harness发布v0.1.0-rc.7。这个预发布版本允许插件自行注册设置卡片，把Codex和Claude Code子代理任务接入Job Panel，并为MCP、ACP增加持久化图片附件。^[1]

这些功能有价值，但它们证明的是接口在扩张，不是能力已经形成。插件目录回答“系统现在能调用什么”；它没有回答这次任务该不该调用、何时调用、输入数据是否可信、输出能否被接受。

8月14日发布的预印本《Demystifying Agent Skills》把这层差异测得更清楚。研究整理了8,135条试验记录，并构造528组配对三元实验。在软件与终端基准中，Skill相对Workflow Memory带来6.06个百分点的成功率提升；研究进一步发现，65.7%的作用来自程序性锚定，显式知识注入只占4.5%。^[2]

换句话说，Skill真正提供的不是一包“能力”，而是一种对执行行为的约束和提示：先做什么，检查什么，哪些坑不要再踩。

问题在候选池扩大时暴露出来。Skill数量从5增加到100，实际使用精度从29.6%降到3.3%。但论文同时指出，下游任务成功率仍较稳定，准确命中所谓标准Skill既不是成功的充分条件，也不是必要条件。相关的非标准Skill有时同样能提供有效程序支持。^[2]

这条边界很重要。它既不能被写成“插件越多，任务必然越差”，也不能被忽略。它说明能力不是一次目录命中，而是把方法放进当前场景后，能否适配并完成交付。

图2｜路由精度明显下降，但下游成功率仍较稳定；命中标准Skill不等于能力。

二、路由灾难和自验灾难会互相放大

一条看似普通的插件链，至少要经过任务理解、技能检索、插件选择、参数构造、结果解释和成功判定。每一步都在压缩上一步的信息，又增加新的推理分叉。

在我的实践估计里，每经过一层，有效信息损失可能达到30%以上。这个数字不是公开统计，也没有经过系统日志测量，只用来说明工程直觉。如果暂时假设每一步独立保留70%的有效信息，四步以后只剩24.01%，六步以后只剩11.76%。真实系统里的错误往往高度相关，还可能比这个乘法示意更危险。

路由灾难发生在动作之前。Agent理解错目标、检索错Skill，或者用一个“差不多能做”的插件替代真正需要的方法。它未必马上报错，因为参数可以合法，接口也可以返回成功。

自验灾难发生在动作之后。同一个Agent负责选插件、组参数、解释返回，再判断自己有没有完成任务。它共享同一段上下文、同一组盲点和同一种语言偏好。后面的判断很可能不是纠错，而是在替前一步的幻觉补理由。

Databricks在2026年7月公开的内部编程Agent基准里，没有用LLM Judge判断正确性。其团队给出的原因很直接：LLM评审会奖励“听起来正确”，而不是“实际上正确”。他们把Agent声明完成时的代码做快照，再用隐藏测试验收。^[3]

同一研究还发现，同一个模型、同样的推理强度，经不同Harness运行，部分任务的单位成本相差超过2倍，质量却相同。主要差异来自每轮送入模型的上下文；Pi每轮发送的上下文约少3倍，用更紧的工作集和更少的轮次完成任务。^[3]

这证明Harness、插件和上下文组织都会改变执行，但仍不能单独证明能力。调用成功只是动作证据，独立验收才是结果证据。

图3｜乘法只用于说明风险；真实系统还存在共享盲点和错误自证，可能更危险。

三、不能用SOP化来解决失控

面对路由和自验灾难，最容易想到的办法是把Agent重新做成一套固定流程：任务A永远调用插件甲，插件甲返回后调用插件乙，最后按一张检查表结束。

这确实更容易控制，也可能让一部分高频、稳定、低变化任务运行得更便宜。但如果整个Agent架构都被SOP化，我们只是给传统自动化套上了一个自然语言入口。AI最稀缺的能力被一起拿掉了：它不能再围绕具体的人、具体目标和具体上下文，动态形成不同的解法。

插件、模型、检索、代码和人工判断都只是构建方法。它们应该在合适的场景里被征用，不应该预先凝固成永久的执行基础设施。目标不是把Agent构建得像一条流水线，目标是完成这一次交付。

我在《瞬知笔记》的一次真实生产中付过这笔学费。系统选错了日期和题目，但源稿、视觉、HTML、桌面与手机渲染、微信双回读全部通过。每个工具都正确完成了自己的局部动作，整条链却把错误任务生产得非常完整。

那次事故说明，SOP可以保证“错误被稳定执行”。它不能自动保证“值得执行的事情被交付”。

极致个性化和可控并不矛盾。矛盾在于，我们过去习惯通过固定路径获得可控；Agent需要换一种控制对象：路径可以动态生成，数据可信和价值方向必须持续成立。

四、Dataflow、Trustlink、Valuepoint必须一起工作

下面三个词是我在Agent实践中采用的工作定义，不是现成的行业标准。

Dataflow描述任务执行中数据怎样产生、流转和变化。这里的数据不只是结构化表格，也包括用户意图、上下文、工具返回、推理中间状态、外部证据和最终结果。插件被调用后，真正进入下一步的不是“插件名称”，而是它产生或改变的数据。

Trustlink指的是对数据的信任。它不等于相信某个Agent很聪明，也不等于一次性相信一整条自动化链。每次数据进入下一步，都要知道它来自哪里，经过了什么变换，有什么证据支持，哪些部分仍然只是推断。Trustlink断裂时，动作即使能执行，也不应继续把结果当成事实使用。

Valuepoint是标准化的价值判定点。无论Agent选择哪条路径，每做一个动作，都要回答：这一步是否让系统继续朝正向价值流前进？它是否减少了关键不确定性，生成了可验收结果，或者让交付状态真实地向前变化？如果一个调用只增加文本、日志或中间产物，却没有推进任何Valuepoint，它就是忙碌，不是价值。

三者不能被拆成三个孤立模块。

Dataflow告诉我们，现在实际流动的是什么；Trustlink判断这些数据能不能信；Valuepoint判断基于这些数据继续行动是否值得。三者共同决定一个插件调用可以进入下一步、需要补证据、应该改道，还是必须停止。

图4｜Dataflow承载数据，Trustlink判断数据可信，Valuepoint判断动作是否推进正向价值。

因此，真正要标准化的不是Agent的思考路径，而是两类判断：数据可信度如何成立，动作的正向价值如何成立。插件仍然可以动态选择，执行顺序仍然可以因人、因目标、因情境变化。控制系统只要求每一次变化都能被看见、被判断、被追责。

五、把控制合同写在交付上

企业很容易用插件数量衡量Agent建设：接了多少MCP，装了多少Skill，连了多少业务系统。这些都是资产清单，不是能力清单。

能力清单应该从交付反推。

第一，先定义最终要改变什么业务状态，而不是先列Agent要做哪些步骤。客服回复、研究报告、代码提交都只是产物；真正的Valuepoint可能是解决时间缩短、决策证据完整，或者代码通过隐藏测试并能安全上线。

第二，每次动作都要带着Dataflow身份。输入是什么、来自哪里、当前版本是什么、输出会覆盖什么，必须进入可观察状态。没有数据身份的插件调用，很难建立Trustlink。

第三，把“完成声明”和“完成验收”分开。执行者可以提交结果，不能只凭自己的语言判断给自己放行。低风险任务可以用确定性规则和抽样；高风险或不可逆动作需要独立测试、外部证据或人工授权。

第四，允许Agent动态改道，但每次改道都必须重新经过Trustlink和Valuepoint。控制的不是它有没有走预定步骤，而是改道后使用的数据仍然可信吗，这一步仍然推动正向价值吗。

第五，把指标从调用侧移到交付侧。真正有意义的指标是合格结果率、人工纠错时间、错误外部动作、单位合格结果的完整成本，以及最终业务状态是否改变。插件调用次数和自动化覆盖率最多是过程数据。

图5｜控制对象是数据可信和价值方向，不是预先规定每一步必须怎么做。

这套控制会让一部分自动化看起来变慢，因为它拒绝用“接口返回200”“Agent说已完成”冒充交付。但一条失控链运行得越快，返工和审计成本上升得越快。速度只能放大已经成立的价值方向。

六、什么情况会推翻这套判断

这套方法不能靠概念正确来证明自己。

可以选择一组重复任务，固定模型、任务难度和验收人，对比固定SOP、无控制的动态Agent，以及由Dataflow、Trustlink、Valuepoint约束的动态Agent。至少观察最终合格率、误调率、人工接管、纠错时间、错误外部动作和单位合格结果成本。

如果无控制的动态Agent在候选插件不断扩张时，仍能长期保持更高的独立验收通过率、更低完整成本，并且没有增加错误外部动作，那么本文对控制层必要性的判断就应当收窄。如果固定SOP在高度个性化任务中同样稳定获得更高采用率，也说明动态组装并非那类任务的主要价值。

低风险、可逆、只使用公开数据的探索任务，也不需要复制高风险生产系统的控制密度。控制本身必须证明它减少的损失大于增加的成本。

插件会继续变多。这没有问题。真正危险的是把“拥有更多动作接口”误认为“拥有更强交付能力”。

能力不是预装出来的，也不是一条固定架构赋予的。它发生在具体交付里：Agent可以因场景而改变路径，但Dataflow始终可见，Trustlink始终能解释数据为何可信，Valuepoint始终把每个动作拉回正向价值流。

极致个性化交付的前提，不是给Agent更大的自由，而是我们能控制得住这种自由。