原论文：Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering上交大 & 中科院等机构，arXiv:2604.08224，2026年4月
读完之后我觉得这个框架太能说清事儿了，结合我最近做Agent开发的实际感受，就整理成了这篇文章。
先跟大家说个反常识的结论
很多人都觉得，Agent行不行，关键看它的底座模型够不够强。这话没毛病，但说得不够准。
论文里有个很实在的观察：实际用的时候，很多系统可靠性的提升，压根没动过模型的参数。
都是靠加持久化记忆、整理能反复用的技能文件、统一工具接口、规范执行流程、给每一步操作记日志……这些方式实现的。
问题的核心，已经从“模型有多能干”，变成了“模型外面那套配套设施有多好用”。
论文里把这个框架叫做Externalization（外化），借鉴的是认知科学家Norman的“认知制品”理论。
核心想法其实特别简单：这些“制品”的作用，不是给你额外加能力，而是改变了任务本身的样子。
就像购物清单，不是让你记忆力变好了，而是把“费劲回忆要买啥”，变成了“对着单子核对”这种简单活；地图也不是让你突然变成导航高手，而是把藏着的空间关系，变成了眼睛一眼就能看清的结构。
LLM Agent的基础设施，干的就是一模一样的事。
三层演进：从权重到上下文，再到Harness
论文把这几年大模型Agent的发展，分成了三个阶段。
第一层：能力都藏在权重里。那时候大家的思路就是模型越大越好，所有知识都“烧”进参数里，想更新一个知识点，就得重新训练一遍模型。
这本身没什么问题，但麻烦就在于，知识、流程、策略，全被锁在一个静态的模型文件里，想查、想改，或者想针对不同用户做差异化调整，都特别费劲。
第二层：能力挪到了上下文里。像Chain-of-Thought、RAG、ReAct这些方法，核心逻辑都一样：不改动模型，而是把任务需要的信息、推理步骤，在调用模型之前塞进去。
这就把“模型记不记得住”这个难题，变成了“把答案放它眼前，它能不能用”的简单识别问题，效率一下子就提上来了。但缺点也很明显，上下文窗口就那么大，而且是一次性的，会话结束就全忘了，多个智能体一起协作，也没有统一的接口标准。
第三层：能力放到了Harness里。这就是现在正在发生的事。系统靠不靠谱，越来越取决于模型外面那套能长期保存的设施：记忆库、技能文件、协议层、沙箱、审批环节、日志系统……模型还是那个负责推理的核心，但“智能”不再只靠模型自己，而是靠外面这套体系撑起来。
外化的三个维度
论文把需要从模型里“搬出去”的负担，分成了三类。
记忆：把状态搬出去
纯模型本身是没有记忆的，每次对话都跟一张白纸一样。用户的喜好、上一次任务的进度、已经踩过的坑，都得靠提示词手动带进去，既浪费Token，也不保险。
把记忆外化之后，就有专门的记忆系统来管这件事。论文里把要存的状态分成了四层：当前任务的工作上下文、之前执行过的情节记忆、跨任务能用的语义知识，还有和特定用户绑定的个性化偏好。
从架构上来说，系统也从“把所有历史都塞进提示词”，进化到“需要什么就查什么”，再到“分层管理、该忘就忘”，现在最新的方向，甚至会用强化学习来优化检索策略。
关键在于：记忆好不好，不在于存了多少东西，而在于能不能在该用的时候，把对的东西调出来。让当前的决策能“看清楚”过往的信息，这才是记忆系统的真正作用。
技能：把流程搬出去
模型每次执行任务，都得从自己的权重里“临时想”一套工作流程。步骤先后、遇到分支怎么选、什么时候该停……每次都可能不一样。遇到长任务、多步骤的任务，这种不稳定的问题，真的特别让人头疼。
把技能外化，就是把“这类任务该怎么干”，写成一个明确的、能反复用的东西——比如一个SKILL.md文件，说清楚什么时候能用、具体步骤是什么、有什么约束、要注意什么。
技能不只是“提示词”，也不只是“工具”。工具告诉你“能做什么操作”，协议规定“怎么调用这个操作”，而技能是教你“这类任务该怎么完成”，是更高层面的、关于“怎么做”的知识。
论文里提了个很有意思的机制，叫Progressive Disclosure（渐进展开）：先只给模型看技能的名字和简单介绍，只有真的需要用到的时候，再把完整的步骤指南加载进去。
这样就不会一上来就把上下文塞满没用的细节——Claude Code的技能系统，用的就是这个思路。
协议：把交互搬出去
模型跟外部工具、其他Agent交互的时候，如果全靠它自己自由发挥生成格式，特别容易出问题。工具接口变了、另一个Agent理解方式不一样，都可能让整个流程崩掉。
协议就是把这件事变成了有规矩的约定：字段类型是什么、调用的状态机怎么运行、权限边界在哪、怎么知道有哪些能力可以用。
MCP（Anthropic推的Model Context Protocol）是Agent和工具交互协议里最有代表性的，解决的就是“每个工具都要单独适配”的麻烦。
A2A（Google）、ACP（IBM）解决的是Agent之间怎么标准化协作。AG-UI、A2UI则是解决Agent的执行状态，怎么标准化地展示给前端界面。
这些协议的价值，不只是让调用格式更整齐，更重要的是把“格式对不对、权限够不够、状态机走到哪了”这些判断，从模型的推理任务里摘出来，交给运行时来强制保证，不用再让模型费心。
Harness：把三者缝合起来的那一层
记忆、技能、协议，各自解决了一部分问题，但如果它们各干各的，就是一堆零散的零件。把它们拼成一个能正常运行的系统，靠的就是Harness。
论文把Harness的核心工作，拆成了六个方面：
执行循环与控制流，负责调度“感知—检索—规划—行动—观察”这个循环，同时设置最大步数、递归深度、资源上限，防止出现无限循环或者费用超标。
沙箱与执行隔离，决定Agent能接触什么、不能接触什么，让它的操作副作用可控，就算失败了也能回滚到之前的状态。
人工审批门，遇到敏感操作或者高风险步骤，就暂停下来等人工确认，Agent的自主程度是可以设置的参数，不是非黑即白的开关。
可观测性与结构化反馈，每次调用、每个工具使用、每一次记忆读写，都留下规范的日志，一方面方便调试和审计，另一方面把失败的记录写回记忆，给优化技能提供依据。
配置、权限与策略编码，把“能做什么、不能做什么、在什么条件下可以做”从提示词里抽出来，变成可以版本管理、可以分层继承的明确规则。
上下文预算管理，记忆检索、技能加载、协议schema、工具描述，都在抢同一个Token窗口，Harness负责在不同的执行阶段动态分配，不让它们乱抢资源、互相挤占。
三者之间的联动
论文里有一张循环图，把记忆、技能、协议之间的关系画得很清楚，我用文字跟大家说一下：
记忆里积累的执行记录，经过提炼，能变成可以反复用的技能；技能执行之后产生的新记录，又会写回记忆，让技能能自我修正。
技能最终得通过协议，绑定到能实际执行的工具或子Agent上，才能真的跑起来；而协议调用的结果，又要规范地写入记忆，才能支撑后续的决策。
记忆里的过往经验，还能影响协议的选择，比如某个工具反复失败，系统就会学会优先选别的路径。
这个闭环系统有好处也有风险。好处是能自我强化：更好的记忆能催生更好的技能，更好的技能又能积累更丰富的记忆。
风险则是错误也会被放大：一条有问题的记忆，可能会提炼出有缺陷的技能，这个技能执行的结果，又会进一步污染记忆。单靠某一个模块自己的质量控制，拦不住这种连锁问题——这就是Harness必须要管的事。
往后看：几个有意思的方向
论文最后聊了几个前沿方向，我挑几个我觉得值得关注的跟大家说。
具身智能里的同构。VLA模型（视觉-语言-动作模型）的发展，正在走数字Agent的老路，也就是这套外化逻辑。
原来大家想靠一个大模型，从头到尾解决感知、规划、执行所有事，现在越来越多的系统，把高层规划交给LLM/VLM，把底层的精细操作交给专门的VLA技能模块，两者之间用规范的协议通信。
这跟我们大脑皮层和小脑的分工，其实是一个道理。
自进化Harness。现在调整记忆策略、修改技能文件、优化执行逻辑，主要还得靠人工。
如果把Harness的配置本身，也变成可以编程修改的对象，Agent系统就能在三个层面自我进化：策略层（调整检索精度、技能排序规则）、管线层（重新安排调度方式）、边界层（决定什么时候新增一个外化模块，什么时候删掉一个没用的）。
这想法很吸引人，但风险也在这——失控的自进化，可能带来新问题的速度，比解决旧问题还快。
从私有脚手架到共享基础设施。现在大多数外化设施，都是一个Agent一套，但随着协作的环节越来越多，大家对共享记忆、共享技能库、统一协议的需求，会越来越强烈。
到那时候，技能文件就会变得像“开源库”一样，记忆系统就像“共同的知识库”，而配套的版本管理、权限审计、溯源机制，就会变成Agent生态里的治理基础设施。
最后
这篇论文最有价值的地方，就是把“Agent能力”这个模糊的概念，拆成了一个能系统设计的工程问题：哪些认知负担该留在模型里，哪些该搬出去，搬出去之后怎么组织，不同部分之间怎么配合，配合的过程怎么管控。
这对我们这些实际做Agent开发的人来说，比单纯比模型的benchmark有用多了。模型好不好当然重要，但很多时候，系统靠不靠谱，关键看外面那套配套设施设计得好不好。
