核心内容摘要
GLM-4V-9B效果实录：会议白板照片理解+待办事项提取+责任人分配建议
大家还记得年初Meta以超过20亿美元的价格收购了Manus同时Claude Code的运行规模也突破了10亿美元的年化收入。
在这样的背景下看看大模型智能体设计中都出现了什么共同的模式就显得特别有意思。
这篇文章汇总了许多有趣的博客、论文和讨论希望能为大家梳理出一些规律。
RLanceMartin最近加入了AnthropicAI发表了一篇Agent设计和上下文管理的深度
总结。
这篇文章不是泛泛而谈而是把过去一年来业界对Agent设计的集体认识系统地整合在一起含金量十足。
原文链接:https://rlancemartin.github.io/2026/01/09/agent_design/长期自主运行的智能体正在走向现实METR_Evals的数据显示了一个有趣的趋势——大模型智能体能够完成的任务长度每7个月就翻一倍。
这听起来很令人振奋不过背后也隐藏着不少挑战。
一个核心问题是当上下文变得越来越长的时候模型的表现反而会下降。
Chroma的研究团队发现了一种现象叫上下文衰退有人
总结了各种失败的场景Anthropic也从工程的角度解释了这个问题上下文应该被视为一种有限资源边际效应会不断递减。
就像人类的工作记忆有限一样大语言模型也有一个注意力预算。
每增加一个新的token这个预算就会被消耗。
这个认识促使大家开始重新思考如何管理上下文。
有人就此提出了上下文工程这个概念上下文工程是一门微妙的艺术和科学就是要在上下文窗口里精心填入恰到好处的信息让智能体在下一步能够最好地利用它们。
看来设计好的大模型智能体说到底就是要把上下文管理得当。
让笔者从一些有趣的例子和想法出发和你一起探讨几个出现频率比较高的设计思路。
给智能体配一台计算机有人给智能体做了个定义它们是由大语言模型自己指挥自己的行动的系统。
过去一年大家逐渐意识到如果给智能体配上一台计算机的权限它们的表现会好很多。
这个计算机可以给它们提供文件系统和命令行这样的基础工具。
文件系统让智能体能够长期保存信息。
命令行则让它们能够运行各种内置工具、调用命令行程序或者写代码来完成任务。
这个思路在最近流行的智能体设计里随处可见。
Claude Code作为一个活在你的电脑上的大模型助手就是这个理念的体现。
Manus则是通过虚拟计算机的方式给智能体提供了类似的能力。
这些系统的核心都是通过工具调用来控制计算机。
有人就把这个本质
总结得特别形象编程智能体最基础的抽象就是命令行接口……归根结底智能体需要访问操作系统这一层。
与其说Claude Code是大模型编程工具不如说它是为你的操作系统准备的大模型。
多层级的行动空间架构智能体执行行动的方式就是调用工具。
现在给智能体配工具变得容易多了——比如通过Model Context ProtocolMCP这样的标准就能简单地加载工具。
但这样做也会带来新的麻烦。
当MCP的使用规模扩大的时候工具定义会充斥整个上下文窗口而工具调用的中间结果又会消耗大量的token。
比如GitHub的MCP服务器就有35个工具它们的定义本身就占了大约26000个token。
更多的工具还可能让模型感到困惑尤其是当这些工具的功能有重叠的时候。
有趣的是那些通用性强的流行智能体用的工具数量其实少得吓人。
Claude Code的开发团队提到他们用的工具只有大约十来个。
Manus的工具数量更少不超过20个。
Amp Code团队在设计行动空间的时候也是有意地把工具限制在很少的数量。
那它们是怎么在工具少的情况下还能做这么多事情呢秘诀就在于把行动从工具调用这一层往下推——推到计算机本身上去。
以Manus为例它的行动空间设计成了一个层级结构。
智能体使用少数几个原子级的工具比如一个bash工具然后通过这个工具在虚拟计算机上执行各种操作。
有了bash工具它就可以调用shell命令、各种CLI程序甚至直接写代码并执行。
有个叫CodeAct的论文就展示过智能体可以通过写代码和执行代码的方式串联起很多动作。
这样做的好处是显而易见的——因为中间结果不需要进入智能体的处理流程所以能省下不少token。
有人用Claude演示过这个思路的实际效果确实省了一大笔。
循序渐进地展开信息循序渐进地展开信息听起来比较抽象有人叫做循序渐进地披露信息,下面我看看怎么回事智能体需要知道自己有什么行动可以选择。
一个做法是把行动都放到工具调用层然后把所有工具定义都预先加载到上下文里。
但最近有个趋势是朝着循序渐进展开信息的方向走这样能更好地管理上下文。
这种设计理念的意思是一开始只展示最核心最必要的信息等到用户真正需要的时候再逐渐透露更详细的内容。
在工具调用层有些智能体会给工具定义建个索引然后需要的时候再动态地查询和加载工具。
有的甚至还会用一个搜索工具来封装这个过程。
对于shell命令或者装在系统里的各种命令行程序Manus的做法是这样的就在智能体的初始指令里列出有哪些可用工具如果需要了解某个工具的具体用法智能体就自己用bash调一下这个工具的help命令。
还有个更聪明的做法把MCP服务器从工具调用层往下推让它们跑在计算机上这样工具定义就能被循序渐进地展开了。
Cursor Agent就是这么干的——它把MCP工具的描述同步到一个文件夹里给智能体一个简短的工具列表智能体只有在真正需要的时候才去读取完整的工具描述。
Anthropic和Cloudflare都在他们的博客里讨论过类似的MCP管理思路。
Anthropic推出的skills标准就很好地体现了这个理念。
这个标准的核心就是把技能组织成文件夹每个文件夹里放个SKILL.md文件。
智能体初始化的时候会读取这些文件里的YAML前言部分从而知道有哪些技能可以用。
但只有当智能体真的需要了解某个技能的细节时它才会去读完整的SKILL.md文件。
把上下文搬到文件系统里如果智能体有了计算机的访问权限就可以把一些上下文从智能体自己的上下文窗口里卸载出来存到文件系统上。
Manus就是这么干的——它会把旧的工具调用结果写到文件里只有当直接卸载上下文的收益开始下降的时候才考虑对某些内容进行
总结。
Cursor Agent也采取了类似的策略它把工具结果和智能体的行动轨迹都卸载到文件系统里。
如果需要这些信息智能体可以把它们重新读回上下文。
这两个例子都很巧妙地解决了一个真实存在的问题上下文压缩也就是
总结这件事有风险因为你可能会丢失一些有用的细节。
把上下文卸载到文件系统还有另外一个作用——可以用来引导长期运行的智能体朝正确的方向走。
有些智能体会定期把一份计划写到文件里然后定期把这个计划重新读回上下文这样可以强化任务目标或者验证自己的工作是否有偏离。
充分利用缓存机制通常智能体是用消息列表的方式来管理上下文的。
每次执行一个行动后新的信息就被追加到这个列表的末尾。
有个有趣的观点说智能体用的是线性的聊天历史但软件工程师的心智模型更像是一个调用栈——任务被推上去完成后再弹出来。
从这个角度想的话有很多方式可以改变会话历史比如删除或添加某些上下文块。
不过这里有个约束条件值得考虑——如果没有提示词缓存这样的技术智能体的成本会高得不可思议。
有了缓存智能体就能从一个提示词前缀的基础上继续运行。
Manus甚至把缓存命中率列为了生产环境中最重要的指标之一。
他们提到用一个容量更大也就是更便宜的$/token的模型搭配缓存实际成本反而比用便宜模型但没有缓存要低。
有人就此指出编程智能体比如Claude Code如果没有缓存的话根本就是经济上不可行的。
隔离上下文引入子智能体很多智能体会把任务下放给子智能体来处理每个子智能体都有独立的上下文窗口、工具集和指令。
子智能体特别适合处理可以并行化的任务。
比如Claude Code团队就在代码审查的时候用子智能体让它们独立地检查不同类型的潜在问题。
类似的map-reduce模式也能用在更新lint规则或者代码迁移这样的任务上。
对于长期运行的智能体上下文隔离也很重要。
有人创造了一个叫Ralph Wiggum的概念——是一个循环不断地运行智能体直到计划被满足。
对于耗时很长的任务不可能把所有东西都放进一个智能体的上下文窗口里。
上下文本身活在文件里不同的智能体之间可以通过git历史来沟通进度。
Anthropic描述过一个版本的Ralph循环是这样的初始化智能体先搭建好环境比如一个计划文件、一个跟踪文件然后多个子智能体分别从计划文件里挑任务来完成。
Claude Code的开发者提到他们也用这个模式通过stop hook来在每个Ralph循环之后验证工作结果。
让智能体不断进化连续学习这个话题最近热度很高。
大家都想让智能体随着时间推移不断进步从过去的经验里学到东西就像人类一样。
有些研究表明有些智能体的部署会失败就是因为它们没办法适应或者学习。
Letta 大模型的团队提出了一个概念叫token空间内的连续学习说白了就是随着时间推移不断地用学到的东西去更新智能体的上下文而不是改动模型的权重本身。
这些方法有个共同线索都是通过回顾过去的智能体行动轨迹或者之前的会话记录然后基于这些分析结果来更新上下文。
这个模式可以用在任务特定的提示词上。
有个叫GEPA的研究就这么干的收集智能体的行动轨迹给它们打分反思失败的情况然后提出一组不同的任务特定提示词变体供进一步测试。
这个模式也能用在更开放的记忆学习上。
关于这块的论文其实有很多。
有人就用Claude Code试过这个想法——灵感来自一个有趣的观察把Claude Code的每个会话蒸馏成日记条目在日记条目之间进行反思然后用这些反思去更新一个叫CLAUDE.md的文件。
还可以把这个思路应用到技能的学习上。
Letta 大模型有个例子就是这么做的通过回顾行动轨迹来蒸馏出可重用的程序然后把这些程序作为新技能保存到文件系统里。
有人也试过类似的想法用在Deepagents这个项目里。
关于未来的展望通过上面的讨论几个设计模式逐渐浮出了水面。
给智能体配一台计算机把行动从工具调用层推到计算机本身。
用文件系统来卸载上下文和逐步展开信息。
用子智能体来隔离上下文。
随着时间推移让上下文不断进化用来学习记忆或者技能。
充分利用缓存来节省成本和降低延迟。
当然摆在面前的开放问题还有很多在接下来的一年里这些都会是很有意思的研究方向。
让机器自己学会管理上下文上下文管理这件事现在通常要靠手工制作的提示词来压缩数据、生成子智能体、决定什么时候卸载什么内容、还要想办法让上下文随时间演化以支持学习。
不过有句话叫苦涩的教训它告诉我们计算规模和模型规模的增长往往会击败那些手工制作的方案。
比如与其采用上下文压缩这样的做法有人就提出了一个不同的想法为什么不让模型自己变得更聪明自动搞定这些问题呢有个叫Recursive Language ModelRLM的新研究就是沿着这个思路走的。
这项工作建议大语言模型完全可以学会自己进行上下文管理。
那些现在被打包进智能体框架里的各种提示词技巧和脚手架有可能最终会被模型本身吸收。
这个想法对于处理记忆这块特别有意思。
它跟一篇关于睡眠时计算的论文有点关联——那篇论文表明智能体可以在离线的时候思考自己的上下文。
想象一下如果智能体能够自动地回顾自己的过往会话然后用这些回顾来更新自己的记忆或者技能是不是就很酷或者智能体可以直接回顾自己积累的各种记忆去更好地整合它们、为未来的任务做准备——就像人类一样。
多智能体的协调问题随着智能体处理的任务规模越来越大我们很可能会看到成群结队的智能体并行工作。
有人就指出现在的智能体在处理共享上下文的时候还很吃力每个行动都包含了隐含的决策而并行运行的多个智能体则面临着这样的风险——它们可能在互相看不见对方工作的情况下做出冲突的决策。
不像人类能主动进行对话来化解冲突这对智能体来说现在还是个难题。
有个叫Gas Town的多智能体项目就很有意思它用一个多智能体的协调器来组织工作用git来追踪任务进展有一个市长智能体掌握整个工作空间的完整信息然后协调几十个并行运行的Claude Code实例——通过一个合并队列和角色特化来管理。
这样的多智能体协调实验值得持续关注。
长期运行智能体需要的新基础设施长期运行的智能体需要新的基础设施来支撑要能观察到智能体在干什么要有钩子让人类可以介入审查要在出问题的时候能优雅地降级处理。
现在的设计模式还比较粗糙。
Claude Code用stop hook在每个迭代之后验证工作结果Ralph循环则通过git历史来追踪进度。
但目前还没有关于智能体可观测性的标准、没有统一的调试接口、也没有通用的人工干预监控模式。
随着智能体运行的时间越来越长我们很可能需要设计出新的抽象来管理它们。
这块的探索才刚刚开始但肯定会成为未来一段时间里的重点。