核心观点总览：真正限制智能体的不是模型能力，而是上下文管理
如果只抓一个核心结论，那就是一句话：今天所有“看起来很强”的智能体，本质上都是上下文管理做得更好的系统，而不是模型更聪明的系统。
2025年结束时，Meta 用超过20亿美元收购 Manus，Claude Code 年化收入突破10亿美元，这两个事件被很多人当成“AI 商业化爆发”的标志。但如果仔细拆解，会发现它们真正领先的地方，并不是模型参数更多，也不是推理更玄，而是在一个被长期忽视的层面下了重功夫——上下文、工具、记忆和环境的工程设计。
研究机构 METR_Evals 给出过一个非常直观的数据：智能体能够完成的任务时长，大约每7个月翻一倍。这说明一件事，长任务不是未来概念，而是正在发生。但与此同时，另一个残酷事实也越来越清楚：上下文一长，模型就会变笨。
大模型的注意力机制决定了它无法像人类那样无限扩展短期记忆。当上下文窗口被填满，新信息挤占旧信息，模型对关键细节的感知能力急剧下降！
Chroma 团队把这种现象称为“上下文腐烂”，DB Breunig 系统总结了长上下文下的失败模式，Anthropic 直接点明：上下文本身是一种有限资源，而且边际收益递减。就像人类的工作记忆一样，注意力是有预算的，每多塞一个 token，都会消耗一点判断力。
所以，问题不再是“怎么把更多信息塞给模型”，而是“在下一步行动之前，什么信息最值得被看见”。
安德烈·卡帕西提出的“上下文工程”，正是这个时代智能体设计的核心命题。
因此，2025年最有效的智能体Agent设计哲学，不是堆砌更多数据，而是像管理内存一样管理上下文——只在需要时加载必要信息，用完即释放或归档。
卡帕西曾指出，上下文工程的核心在于“为下一步动作精准注入恰到好处的信息”。这意味着，智能体不能依赖静态的、全量的提示词，而必须具备动态检索、筛选、压缩和复用上下文的能力。而实现这一点的关键基础设施，就是赋予智能体一个类Unix的操作环境。
给智能体一台电脑，是一切设计模式的起点
过去一年，一个共识几乎在所有成功智能体项目中反复出现：想让智能体真正干活，必须给它一台“电脑”（类Unix的操作环境）。
Barry Z 和 Erik Schluntz 对智能体的定义很直接：由大模型自己决定下一步行动的系统。而一旦让模型决定行动，它就需要一个真实可操作的环境，而不是只会聊天的沙盒。
文件系统+Shell=智能体操作系统！
文件系统给了智能体“长期记忆”的物理载体，Shell 给了它执行动作的基本肢体。它可以调用系统自带工具、命令行程序、第三方 CLI，甚至自己写代码再执行。这一步，直接把智能体从“对话助手”升级成“数字员工”。
Claude Code 的爆红，本质上是因为它不是一个写代码的聊天机器人，而是“住在你电脑里的智能体”。Manus 走的是虚拟电脑路线，但抽象层是一样的。正如 Guillermo Rauch 说的那句话：真正的编码智能体抽象不是 Prompt，而是 CLI，是操作系统。
回头看会发现，这不是倒退，而是回归。文件系统、Shell、进程、CLI，这些 Unix 时代的老东西，恰恰是模型最熟悉、最容易泛化的抽象。不是模型需要新工具，而是人类之前给的工具太花哨了。
Vercel最新开源的bash-tool正是这一思想的工程实现。它允许Agent在内存或沙箱中运行类Bash命令（如find、grep、jq），并通过readFile/writeFile读写文件，而无需将整个代码库塞进上下文。例如：
import { createBashTool } from "bash-tool"; |
这种方式极大节省了token消耗。Agent只需知道“有一个bash工具可用”，具体要查哪个文件、运行哪条命令，由它自己决定。这就像人类程序员不会背下整个项目代码，而是用grep搜索、用vim编辑、用npm run执行——智能体也应该拥有同样的工作流。
用“原子工具”压扁行动空间
动作空间要小，但能力要大：多层动作空间的设计哲学
很多人一开始做智能体，第一反应是“多给工具”。结果往往是：上下文爆炸，模型迷路。
多工具调用看似强大，实则隐患重重。MCP 等协议让“给模型加工具”变得非常容易，但问题也随之放大。以GitHub MCP为例，35个工具定义就占用了约26,000个token，不仅挤占上下文，还容易让模型混淆功能相近的工具。
然而，Claude Code仅用十几个工具，Manus不到20个，却能完成复杂软件开发任务。秘诀在于：将绝大多数操作下沉到“计算机”层，只暴露少数原子工具给模型。
最成功的通用型智能体，工具数量都少得惊人。Claude Code 只有十几个工具，Manus 不到二十个，Amp Code 甚至专门“裁剪动作空间”。
秘诀在于分层：不是让模型学会一百种工具，而是给它几个“原子动作”，然后通过计算机层把复杂性展开。
所谓"原子动作"就是原语动作，实现预设定义好的动作：
- 比如从Git操作抽象出五个原语动作：初始化、比较、合并、提交、删除！
- 一个 bash 工具中几个原语：如grep命令，就能解封调用无数系统能力。
Manus 的设计就很典型：在模型眼里，它只是在用 bash，但 bash 背后，是整个操作系统的能力。写文件、跑脚本、调 CLI、编译代码、处理数据，全都在工具定义之外完成。
CodeAct 论文从理论上证明了这一点：通过写代码并执行，智能体可以连续完成大量操作，而且因为不需要把每一步中间结果塞回上下文，token 成本反而更低。Anthropic 也明确指出，这是节省上下文预算的关键手段之一。
一句话总结：不要让模型记住怎么干活，让它直接去干。
渐进式暴露：不是不给工具，而是按需出现
智能体必须知道自己“能做什么”，但不代表它必须“一开始就知道所有细节”。
即使工具数量被压缩，如何让智能体知道有哪些能力可用？答案是“渐进式披露”（Progressive Disclosure）。
传统做法是一次性加载所有工具描述，而先进Agent只提供概要，细节按需获取。
传统做法是把所有工具定义一次性塞进上下文，简单粗暴，但代价极高。渐进式暴露这个模式，正在成为主流。
核心思想很简单：一开始只给最必要的信息，细节等用到再查。
- Manus 的做法很有代表性。系统指令里只告诉模型“系统里有哪些常用工具”，至于参数、用法，让模型自己通过 bash 加上 help 去查。这既省 token，又符合人类习惯。也就是说：Manus在初始指令中仅列出可用的CLI工具名称（如git、npm、docker），Agent若想了解某个工具的具体用法，只需在bash中运行tool --help
- Cursor Agent 把 MCP 工具描述同步到文件夹，只把工具名列表给模型。如果模型觉得有用，再去读具体说明。Agent先看到简短清单，只有在任务需要时才读取对应工具的完整说明文件。
- Anthropic 的 Skills 标准更进一步，把技能skills拆成文件夹，每个技能的 YAML 头部加载进指令，正文按需读取。
这种设计模拟了人类学习过程：先知道“有这个东西”，再在使用时查阅文档。它大幅降低了初始上下文负担，同时避免了信息过载导致的决策瘫痪。
这背后是一种非常工程化的认知：上下文不是百科全书，而是工作台。
把上下文“搬出去”：文件系统才是真正的长期记忆
一旦任务变长，把所有历史都塞在上下文里，几乎注定失败。
长期运行的智能体面临另一个难题：对话历史不断增长，很快超出上下文窗口。简单粗暴的“摘要压缩”又可能丢失关键细节。解决方案是：将上下文从提示词中卸载到文件系统。
Manus、Cursor 等系统已经形成共识：旧的工具结果、行动轨迹，必须外置。文件系统成为上下文的“冷存储”。
当上下文边际收益开始下降时，Manus 会把内容写入文件，并在文件层面做摘要，而不是强行压缩上下文。将旧的工具调用结果写入临时文件，并在累积到一定量后进行摘要，但原始数据仍可追溯。（类似事件溯源中投射project）
Cursor 会把整个 agent trajectory 存档，必要时再读回来。Cursor Agent则将整个Agent决策轨迹（包括每一步的思考、行动、结果）持久化到磁盘，后续任务可选择性地读回相关片段。这相当于为Agent建立了“外部记忆体”，既避免了上下文腐烂，又保留了信息完整性。上下文图谱核心：将系统行为、数据来源、策略约束转化为可审计的图谱记录
这种设计解决了一个长期争议的问题：摘要会不会丢信息。答案是，丢不丢不取决于算法，而取决于是否还能回溯原始数据。文件系统让这件事变得可逆。
更有创意的是，一些Agent会将任务计划写入plan.md文件，每隔几轮就重新读取，以校准目标、防止偏离。这种“计划-执行-验证”循环，正是人类项目管理的核心方法，如今被成功移植到AI代理中。也就是说，文件还能用来“管住智能体”。很多长任务智能体会把计划写成文件，每隔一段时间重新读一遍，用来校准方向，防止跑偏。这和人类写 TODO、复盘笔记是一个逻辑。
缓存不是优化，而是生存条件
缓存上下文：用“提示缓存Prompt Caching”对抗成本飙升
很多人低估了 提示缓存Prompt Caching 对智能体的重要性。实际上，没有缓存，大多数生产级智能体根本跑不起来。
线性追加的聊天历史不仅低效，还极其昂贵。每次调用都要重传全部历史，token费用随任务长度线性增长。而现实中的软件工程思维更像“调用栈Stack”——任务压入、完成、弹出，上下文动态变化。
提示缓存（Prompt Caching）技术为此提供了出路。
Manus团队直言：“缓存命中率是生产级Agent最重要的指标。” 高缓存命中意味着大部分前缀提示无需重复计算，即使使用单价更高的模型，总成本也可能低于低单价但无缓存的方案。
Claude Code 的实践也证明，高单价模型加缓存，反而比低价模型不缓存更便宜。Claude Code若无缓存，其高频交互场景将完全不可持续。
这揭示了一个反直觉事实：在Agent场景中，模型单价并非成本决定因素，上下文复用效率才是。未来Agent框架必须内置高效的缓存机制，支持上下文块的增删改查，而非简单追加。
原因很简单：智能体不是一次性推理，而是不断在一个相对稳定的上下文前缀上追加动作。如果不能复用前缀，每一步都是重新烧钱。这也直接限制了“随意修改上下文”的空间。你可以在文件系统里随便写，但一旦动了 Prompt 前缀，缓存就失效，成本立刻爆炸。
上下文隔离：用子智能体（sub-agent）切割复杂任务
单个Agent难以处理超长任务或并行需求，随着任务变复杂，把所有事情交给一个智能体，几乎必然崩溃。子智能体是目前最成熟的解法之一。
于是，“子智能体/子Agent”模式兴起：将大任务拆解，由多个上下文隔离的子智能体分别执行。
Claude Code在代码审查中，会启动多个子智能体并行检查不同类型的潜在问题（如安全漏洞、性能瓶颈、风格违规），每个都有独立上下文，最后汇总结果——典型的Map-Reduce模式。这种 map-reduce 模式不仅提速，还降低了上下文干扰。
在超长任务中，这种隔离更是刚需！
对于超长任务，一个初始化Agent生成任务计划文件，Geoffrey Huntley提出的“Ralph Wiggum循环”成为标准解法：本质上智能体就是一个Bash Shell命令的循环，实际就是让任务在多个短生命周期智能体之间接力。后续子智能体依次从计划中领取子任务，完成后更新状态。进度通过Git提交历史或共享文件同步，确保全局一致性。
Anthropic和Claude Code团队均采用此模式，并配合“停止钩子”（Stop Hook）在每轮结束后自动验证结果，防止错误累积。
环境、计划、进度都放在文件系统或 Git 中，智能体来来去去，但任务连续。这种架构不仅解决了上下文长度限制，还天然支持容错与重试——某个子任务失败，只需重启该子Agent，不影响整体流程。
Anthropic 描述的 Ralph Loop 版本中，有初始化智能体负责搭环境，子智能体逐项完成任务，还有 stop hook 用来验证结果。这套机制已经在真实产品中被反复验证。
进化上下文：让智能体从经验中学习
如果智能体永远不学习，那它永远只能重复犯错。
真正的智能体应能持续进化。现在越来越多团队开始尝试“在 token 空间里做持续学习”。不改模型权重，而是让上下文和记忆随着使用进化。
2025年，智能体“终身学习”不再停留在模型微调，而是聚焦于上下文层面的自我更新。Letta AI提出“Token空间中的持续学习”：不改模型权重，而是通过反思历史轨迹，提炼策略、失败模式、工具使用技巧，并注入未来上下文。
Lance Martin的实践颇具启发性：他将Claude Code的每次会话日志提炼成“日记条目”，定期反思这些日记，提取偏好与反馈，更新一个名为CLAUDE.md的记忆文件。下次启动时，该文件作为初始上下文加载，使智能体行为逐渐个性化。
类似地，GEPA框架会收集智能体轨迹、打分、分析失败原因，自动生成多种提示变体进行A/B测试，选出最优方案。
Anthropic的技能skills标准也支持此模式：Agent可将成功解决某类问题的流程，封装为新的SKILL.md文件，存入技能库。未来遇到同类任务，即可直接调用。这实现了“知识乐高化”——经验可复制、可共享、可传播。
小结：
最常见的做法是：记录轨迹，打分，反思失败，提炼规则，再更新 Prompt 或技能文件。GEPA、Letta、Claude Diary 都在做类似的事。
- 有意思的是，这种方法在人类视角下非常自然。写工作日志，定期复盘，把经验写进操作手册。区别只是对象变成了智能体。
- 这种记忆不一定是事实型，也可以是偏好、失败模式、操作习惯。长期来看，它让智能体越来越“像一个老员工”。
未来方向：让模型自己学会管理上下文
当然，所有这些工程技巧，最终可能都会被模型能力吞噬。
Jeff Huber 提出一个很尖锐的观点：也许压缩上下文本身就是个伪问题，真正需要的是让模型能搜索自己的轨迹。Recursive Language Models 正在朝这个方向探索，让模型学会递归地整理、折叠自己的上下文。
如果这条路走通，很多今天复杂的 agent scaffolding，可能会被模型内化。就像过去手写特征工程，最终被深度学习替代。
Prime Intellect实验室提出的“递归语言模型”（Recursive Language Models, RLM）正是此路线的代表。RLM能递归地压缩、重组、折叠自身上下文，在不丢失关键信息的前提下维持超长任务的连贯性。其核心思想是：上下文不应是静态输入，而是可被模型主动操作的数据结构。
更进一步，Letta AI的“睡眠计算”（Sleep-time Compute）设想智能体在空闲时自动反思历史会话，提炼记忆、优化技能、甚至预演未来任务。这类似于人类的“离线学习”——白天经历，夜晚整合。若此能力内化到模型本身，当前复杂的智能体框架或许会被大幅简化。
多智能体协作，是下一个难关
当一个任务需要几十个智能体同时工作时，新的问题出现了：它们彼此看不见对方在想什么。
随着任务复杂度提升，单一智能体力不从心。2025年末，多智能体协同成为新热点。Cognition 指出，当前智能体很难进行“人类式的主动协商”，很容易在并行中做出冲突决策。
Gas Town 这样的项目开始引入“市长智能体”，用 Git 做统一状态管理，尝试解决这个问题。Steve Yegge主导的Gas Town项目展示了数十个智能体如何在Git工作区中协作：一个“市长”智能体掌握全局上下文，协调其他智能体分工，所有变更通过Git提交追踪，确保一致性。
但挑战依然巨大。
Cognition团队指出，当前智能体缺乏“主动协商”能力——人类团队会实时沟通冲突、调整分工，而Agent各自为政，易产生重复或矛盾操作。未来需发展共享记忆、意图广播、冲突检测等机制，才能实现真正意义上的“蜂群智能”。
这说明一件事：当智能体规模扩大，软件工程问题会全面回归。
总结：Agent设计的本质是上下文架构设计
真正有效的智能体设计，从来不是“多塞一点 Prompt提示”，而是对上下文、动作、记忆和环境的极致克制与调度。这是一门工程艺术，而不是魔法。
2025年的实践清晰表明：成功的Agent不在于模型多强，而在于上下文管理多巧。通过赋予AI一个类Unix计算机，将其行动空间下沉到Shell层，采用渐进披露、上下文卸载、缓存、隔离、演化等策略，才能突破上下文窗口的物理限制，迈向真正长期、自主、低成本的智能体。
这场变革的核心，是从“提示工程”转向“系统工程”——不再把AI当作黑盒问答机，而是将其嵌入一个精心设计的操作环境中，让它像人类专家一样思考、探索、犯错、学习。这不仅是技术升级，更是对“智能”本质的重新理解：智能不在模型内部，而在人机协同的整个系统之中。
智能体本质：先知“语义”；再会“符号逻辑”，外挂一套Unix操作系统，就能行动了！