Agent 能力会被内化吗:外部系统、模型训练与研发护城河
最近读 Agent 长记忆、长任务、Skill、MCP、工具使用这些论文时,我有一个越来越强的感觉:
今天很多 Agent 工程,本质上是在给模型补外部系统。记忆靠数据库,长任务靠任务队列,工具靠 schema,反思靠 prompt loop,权限靠 sandbox,失败恢复靠 harness。它们确实能提升当下 Agent 的可用性,但问题是,如果模型下一代、下下一代把这些能力内化了,我们今天做的外部系统会不会变成一层临时脚手架?
我把相关论文又集中读了一遍,尤其是:
- Externalization in LLM Agents
- Toolformer
- Gorilla
- ToolLLM
- TInR
- Understanding Tool-Integrated Reasoning
- Agent Skills for Large Language Models
- STaR
- Large Language Models Can Self-Improve
- Self-Refine
- RISE
- Agent Distillation
- Distilling Tool Knowledge via Back-Translated Traces
- Rich Sutton 的 The Bitter Lesson
我的结论是:这个担心是对的,但只对了一半。
很多今天靠外部系统补出来的能力,确实会被模型内化。比如常见工具选择、参数填充、反思修正、失败重试、简单记忆压缩、常见工作流执行。它们只要稳定、高频、可验证,就会逐步进入训练数据、后训练流程、小模型蒸馏和产品默认能力。
但外部系统不会消失。它会从“补模型短板的脚手架”,转成“产生真实状态、验证信号、权限边界、组织知识和训练数据的基础设施”。
这才是关键变化。
一条主线:外部化和内化不是二选一
Externalization in LLM Agents 给了一个很好的总框架:LLM Agent 的能力建设正在从 weights 走向 context,再走向 harness。记忆、Skill、协议、工具、sandbox、观测、审批、评测,都属于围绕模型重组运行时的外部化能力。
这篇论文最有价值的地方,不是说“外部系统有用”,而是解释外部系统为什么有用。
外部系统不是简单给模型加挂件,而是在改变任务表示。记忆把“靠模型回忆过去”变成“从状态库检索过去”;Skill 把“每次重新生成流程”变成“加载一个可复用过程”;协议把“自由文本猜接口”变成“受约束的机器合约”;Harness 把“模型自己负责一切”变成“模型在一个可观测、可控制、可恢复的环境里行动”。
但另一边,The Bitter Lesson 也一直在提醒:AI 历史里,很多手写的、人类设计的知识结构,长期会被更通用的学习和搜索方法吞掉。只要有足够数据、算力和反馈,模型会学会越来越多过去需要外部规则或工程流程才能完成的事。
这两条线看似矛盾,其实可以合成一个循环:
先把能力外部化,让系统能稳定做事
外部系统产生轨迹、反馈、错误和验证结果
稳定、高频、可验证的部分被训练或蒸馏进模型
模型变强后,新的任务边界继续外部化
所以问题不是“外部化还是内化”,而是:
什么应该暂时外部化
什么值得被训练内化
什么必须长期外部化
谁能把这三者连成数据闭环
第一类会被内化:工具使用的常见模式
Toolformer 是一个很早但仍然重要的信号。它让语言模型从少量 API 示例出发,自己生成候选工具调用,再用工具调用是否帮助预测后续文本来筛选训练数据。最后模型学到的不只是“有个工具”,而是何时调用、传什么参数、怎么把结果接回文本生成。
这说明工具使用不是只能靠手写 ReAct prompt。工具调用模式本身可以进入模型能力。
ToolLLM 把这个方向放大到真实 API 规模:ToolBench 覆盖 16,464 个 RESTful API 和 49 个类别,自动生成工具使用指令和 solution path,再训练 ToolLLaMA。它的意义不是具体模型多强,而是证明只要外部工具生态能产出足够多轨迹,工具使用能力就能迁移进模型。
Gorilla 则补了另一个关键点:API 调用准确性和 hallucination 可以通过 fine-tuning 加检索显著改善。模型可以学会更可靠地写 API call,但 API 文档本身更新太快,仍然要靠外部 retriever 保持新鲜。
到 TInR,趋势就更直接了:它明确提出 Tool-Internalized Reasoning,把工具知识通过工具 token、双向知识对齐、SFT 和 RL 写入模型,让模型不必每次都在 prompt 里读取完整工具文档。
这条线很清楚:
从提示词教工具
到训练模型用工具
到把部分工具知识写进模型
但边界也很清楚。模型能内化的是稳定工具集合里的常见调用知识。真实世界里的工具 registry、API 文档、版本变化、组织私有接口、权限状态、调用副作用,仍然应该外部化。
换句话说,未来模型会越来越像一个熟练工程师:它不需要每次都重新学 curl、SQL、git、Python、浏览器操作。但它仍然需要查最新文档、读当前代码、跑真实测试、遵守当前权限。
第二类会被内化:反思、修正和自我改进套路
今天很多 Agent harness 都有类似结构:
执行
观察失败
反思原因
调整计划
重试
这些看起来像外部控制逻辑,但论文显示,它们也在被模型内化。
Self-Refine 不训练新模型,只让同一个 LLM 生成初稿、给自己反馈、再根据反馈修改。它证明“反馈 -> 修改”这个结构在许多任务上有效。但它的失败案例也很有启发:失败多数不是模型不会修改,而是反馈定位错误或给了错误修复建议。
所以 Self-Refine 说明了两件事:
反思循环有价值
反思质量需要被训练或被外部验证
STaR 和 Large Language Models Can Self-Improve 把自我改进推进到训练阶段。模型生成推理过程,筛选高置信或能得到正确答案的样本,再用这些自生成数据 fine-tune 自己。它们说明推理风格、rationale、解题步骤可以通过自举进入参数。
RISE 更贴近 Agent。它把单轮问题变成多轮 MDP,让模型看到自己之前失败的尝试和环境反馈,然后训练它在下一轮修正。换句话说,今天我们在外部 harness 里写的“看到失败后怎么改”,未来会成为 post-training 数据的一部分。
这对 Agent 产品影响很大。未来模型会默认更会重试、更会发现自己前后矛盾、更会利用编译器或测试反馈、更会从失败轨迹里改写策略。很多今天写在 prompt 里的“如果失败就检查 X,再尝试 Y”,会变成模型的基础能力。
但这里也有边界:自我改进需要反馈信号。没有 oracle、没有测试、没有可判定结果,模型很容易把错误解释得更像真的。反思可以内化,验证不能省略。
第三类会被内化:外部 Agent 的轨迹会变成训练材料
最容易被低估的一点是:外部 Agent 系统不是只服务当下任务,它还会生产下一代模型的数据。
Distilling LLM Agent into Small Models with Retrieval and Code Tools 做的不是普通 CoT distillation,而是让小模型学习大模型 agent 的完整行为:什么时候检索、什么时候执行代码、如何整合工具结果。它证明 0.5B、1.5B、3B 这种小模型也能通过 agent trajectory 学到一部分工具型任务能力。
Distilling Tool Knowledge into Language Models via Back-Translated Traces 则更进一步:先让工具增强 agent 用 SymPy 等工具解题,再把工具调用轨迹反译成自然语言推理轨迹,最后训练小模型在没有工具访问的情况下学到部分工具知识和结构化推理模式。
这非常关键。今天的外部系统如果设计得好,就不只是“临时补丁”,而是一个数据发动机:
工具调用轨迹
失败恢复轨迹
测试反馈
人工审批
代码 diff
环境观察
最终结果
这些都可以变成模型内化能力的材料。
所以未来真正有价值的 Agent 基础设施,不是写死很多规则,而是能记录高质量轨迹,知道哪些成功、哪些失败、为什么失败、哪个外部模块帮了忙、哪个 Skill 误导了模型、哪个验证器提供了关键反馈。
没有这个闭环,外部系统就只是脚手架。它被模型吃掉以后就没有价值。
有这个闭环,外部系统就是训练矿山。模型越强,它越能服务更复杂任务,产生更高价值数据。
但有些东西不该被完全内化
如果只看 Toolformer、TInR、RISE、Agent Distillation,很容易得出一个激进结论:既然工具、反思、Agent 行为都能训练进模型,那外部系统迟早都没了。
我不这么看。Understanding Tool-Integrated Reasoning 给了一个很强的反驳:工具不只是模型能力补丁,工具会扩大模型在有限 token budget 下能到达的策略空间。
例如:
搜索返回的是当前世界状态
Python/REPL 给的是确定性计算结果
单元测试给的是真实程序反馈
SAT/SMT solver 给的是形式验证信号
文件系统给的是可写外部状态
数据库给的是远大于上下文窗口的持久记忆
浏览器给的是当前页面和交互环境
这些东西不是“模型多背一点知识”就能替代的。
模型可以学会什么时候搜索,但不能在参数里永久保存今天的网页。模型可以学会什么时候跑测试,但不能靠想象替代真实测试。模型可以学会 API 使用习惯,但不能把每个公司今天上午刚改的接口权限内化进权重。
这里有一个判断标准:
如果能力依赖稳定模式,可以内化
如果能力依赖当前状态,必须外部化
如果能力依赖确定验证,验证器必须外部化
如果能力依赖责任归因,审计链必须外部化
这也是为什么记忆系统不会因为模型长上下文变大就消失。长上下文能容纳更多文本,但不能替代可更新、可查询、可权限控制、可审计的组织状态。记忆不是“塞更多 token”,而是状态管理。
Skill 是中间形态,不是终点
Agent Skills for Large Language Models 很适合放在这个问题里看。Skill 现在看起来是外部能力包:一个 SKILL.md,加脚本、参考材料、资源和 progressive disclosure,让 agent 在需要时加载过程性知识。
这当然是外部化。
但 Skill 也很可能是内化的中间形态。一个 Skill 如果高频、稳定、可验证,就可以被压缩成训练数据、adapter、router 策略、工具选择偏好,甚至变成模型默认行为。论文里讨论 skill acquisition、skill compilation、RL with skill libraries,本质上都在朝这个方向走。
所以 Skill 的长期价值不只是“让今天的 agent 会做某件事”,而是:
把隐性的工作流显式化
把显式流程变成可执行 artifact
把执行过程变成可评估轨迹
把高质量轨迹变成训练材料
但 Skill 也暴露出外部化无法回避的治理问题。论文提到社区 Skill 的安全风险、prompt injection、脚本漏洞、权限模型和生命周期治理。这里不能简单说“以后模型更聪明就好了”。一旦 Skill 能读文件、跑脚本、调外部服务,它就不是知识片段,而是供应链资产。
供应链资产需要权限、签名、审计、沙箱、版本和撤回机制。这些不会因为模型更强就消失。
未来研发竞争力在哪里
如果上面的判断成立,未来 Agent 研发竞争力会从“会不会写 prompt/harness”迁移到五个更硬的地方。
第一,是任务环境。
谁能接入真实业务环境、真实代码仓库、真实浏览器、真实数据库、真实审批流,谁就能获得更有价值的 agent 轨迹。没有环境,就没有高质量状态和反馈。
第二,是验证系统。
测试、编译器、评测集、human review、policy check、财务对账、权限审计,这些决定了 agent 轨迹能不能变成训练信号。没有验证,所谓自我改进就是把噪声循环放大。
第三,是数据闭环。
外部系统每次执行都应该回答:
任务是什么
模型看到了什么
用了哪些工具和 Skill
哪些步骤失败
哪个反馈让它修正
最终结果是否通过验证
这条轨迹能不能复用或训练
能回答这些问题的团队,才有持续改进的飞轮。
第四,是组织记忆。
通用模型会越来越强,但每个组织的代码、客户、流程、偏好、历史事故、权限边界、合规规则都不同。这些知识不应该随便写进模型,也不可能完全靠模型预训练获得。它们需要外部记忆、知识库、Skill、策略和审计。
第五,是边界设计。
未来优秀的 Agent 系统不是“让模型自己决定一切”,而是知道哪些决定可以交给模型,哪些必须交给工具,哪些必须交给人,哪些必须被 policy 拦住。边界设计会比 prompt 技巧更值钱。
今天该怎么做,才不容易被内化浪潮淘汰
我会用下面这套标准判断一个 Agent 外部系统值不值得做。
如果一个模块只是把模型已经快学会的常识写成 prompt,比如“遇到错误请重试”“先理解需求再修改代码”“输出前检查格式”,那它很可能是短期补丁。可以做,但不要当长期护城河。
如果一个模块能提供真实状态,比如读取仓库、执行测试、查询数据库、调浏览器、管理任务队列、保存长期记忆,它值得做。模型越强,越需要真实状态来行动。
如果一个模块能提供强验证,比如单元测试、静态分析、形式约束、权限检查、结果对账,它值得做。模型可以内化策略,但不能内化真实验证。
如果一个模块能沉淀轨迹,比如记录每次工具调用、失败、修正、审批、最终结果,它很值得做。它会成为未来训练和蒸馏的资产。
如果一个模块能管理责任,比如权限、审计、版本、回滚、数据边界、人类确认,它必须做。越强的 Agent 越需要这层,不是越不需要。
最危险的是做一堆不可观测、不可验证、不可学习的 prompt glue。它今天可能有效,明天就被模型默认能力吃掉,而且不会留下任何资产。
我的最终判断
Agent 的通用认知动作会持续内化。工具调用、反思、计划、重试、常见工作流、局部记忆压缩,这些都会越来越像模型的默认能力。
但 Agent 的真实工作系统会持续外部化。状态、工具、验证、权限、审计、组织知识、任务环境,不会被黑盒参数完全替代。
所以未来不是外部系统消失,而是外部系统升级:
从 prompt glue
升级为 task environment
从手写规则
升级为 trajectory generator
从临时补丁
升级为 verification and governance layer
从模型外的拐杖
升级为训练下一代模型的数据飞轮
如果只做“帮当前模型补短板”的外部系统,确实会被内化趋势侵蚀。
如果做的是“连接真实世界、产生验证反馈、沉淀组织知识、形成训练闭环”的外部系统,模型越强,它的价值反而越大。
这也是我现在看 Agent 研发护城河的核心判断:竞争力不在某个单点能力到底内化还是外化,而在能不能持续把两者之间的循环跑起来。