拆解AI Agent的内部工作原理：从一个循环聊到效率与效果的平衡术

拆解AI Agent的内部工作原理：从一个循环聊到效率与效果的平衡术

Agent的本质可以用一句话概括：一个LLM在循环里不断调用工具，直到完成目标。 这话是Simon Willison（Django联合创建者、HN常驻高赞用户）在2025年9月提出的定义，我觉得这是目前对Agent最精准的一句话描述。但光知道这句话没用，真正有意思的是这个循环内部到底发生了什么，以及各家产品为什么在同一个基本架构上做出了截然不同的取舍。这篇回答我尽量从原理层面把事情说透，同时给出值得深读的论文和资料。

◆一、所有Agent的共同骨架：感知-思考-行动循环

不管是Claude Code、Cursor、Devin还是Manus，拆开来看都是同一套骨架。OpenAI的Lilian Weng在2023年那篇被引用无数次的博客里给了一个经典公式：Agent = LLM + 规划 + 记忆 + 工具调用。这个公式到今天依然成立，变化的只是每个组件的工程精度。

核心运行逻辑长这样：

说白了就是一个 while(需要工具调用) → 执行 → 把结果喂回去 → 再想 的死循环，直到LLM认为任务完成了，不再请求工具调用，循环才终止。另一种终止条件是触发安全阀：达到最大迭代次数、token预算用完、或者超时。

这里有一个关键点很多人没注意到：LLM本身从不执行任何工具。 它只负责生成一个结构化的JSON描述（我要调用哪个工具、参数是什么），真正的执行由外部的编排代码完成。这个设计保证了安全边界，LLM永远隔着一层沙箱。

1.1 落到网络层：每次API调用到底发了什么

上面说的循环听起来很抽象，但落到HTTP层面其实非常具体。所有大模型API（OpenAI、Anthropic、Google）的核心都是一个POST请求，body里最关键的字段就是 messages 数组。这个数组是按时间顺序排列的完整对话历史，每条消息有一个 role 标识身份。

这里面有几个非常重要的事实，理解了它们才能真正搞懂Agent的工作方式：

第一，LLM是无状态的。 它没有会话记忆，不记得上一轮你说了什么。所谓的"多轮对话"，其实是客户端（你的Agent代码）在本地维护一个越来越长的 messages 数组，每次API调用都把完整历史从头发一遍。第一轮发1条消息，第二轮发3条，第三轮发5条，到第N轮可能发几十上百条。这就是为什么长对话越来越慢、越来越贵，因为每一轮都在重新处理所有历史token。

第二，工具调用是"假装"出来的对话。 当LLM决定调用工具时，它的回复里会包含一个 tool_use 块（Anthropic叫法）或 tool_calls 字段（OpenAI叫法），本质就是一段结构化JSON。你的编排代码拿到这个JSON，去执行真正的操作（读文件、调API、跑SQL），然后把结果包装成一条 role 为 tool_result 的消息，追加到 messages 数组里，再发起下一次API调用。对LLM来说，工具结果看起来就像一条普通的用户消息。

第三，messages 数组的增长就是Agent的"成本曲线"。 用一个具体的例子来感受：假设系统提示+工具定义占5,000 token，每轮对话（一次思考+一次工具调用+一次结果）平均增加1,500 token。那么：

注意这只是 input token 的费用，还没算 output。而且这是每一轮都要付的钱，不是累计总和。第30轮的那次API调用，光input就要处理5万token，哪怕你只是问了一个简单的跟进问题。这就是为什么上下文管理和提示缓存对Agent来说不是"优化"，而是"生存必需"。后面第六章会详细讲怎么解决这个问题。

Anthropic在2024年12月发布的《Building Effective Agents》里做了一个我认为非常重要的区分：workflow和agent是两回事。 Workflow是LLM按预定义的代码路径执行（比如先总结、再翻译、再润色），流程是人写死的；Agent是LLM自己决定下一步干什么，流程是动态涌现的。Anthropic的建议是，能用workflow解决的问题就别上agent，复杂度要一级一级往上加。他们定义了一条清晰的升级路径：

从左到右，复杂度递增，可控性递减。大多数生产环境的任务其实停在前三步就够了。

◆二、Agent怎么思考：推理框架从CoT到LATS的演进

Agent的核心能力取决于LLM的推理质量。过去三年，学术界贡献了一系列推理框架，每一层都在前一层上加东西。我按复杂度递增的顺序捋一遍。

2.1 Chain-of-Thought：一切的起点

Wei等人2022年在NeurIPS发表的CoT论文，核心发现是：只要在提示里加上中间推理步骤的示例，模型在数学、常识推理等任务上的表现就能大幅提升。540B参数的PaLM模型仅用8个CoT示例就在GSM8K上达到了当时最佳。后来Kojima等人发现甚至不需要示例，只需在提示末尾加一句Let's think step by step（零样本CoT）就能激活推理能力。

不过有个最新的发现值得注意：Wharton商学院2025年的研究显示，o3-mini、o4-mini这类自带内部推理能力的模型，外部CoT提示只能带来2-3%的边际提升。说白了，模型内部已经在做CoT了，你再从外面加一遍，收益很有限。

2.2 ReAct：当今Agent的事实标准

如果说CoT让LLM学会了思考，ReAct就是让它学会了边想边干。Yao等人（ICLR 2023）提出的ReAct框架，把推理轨迹（Thought）和外部动作（Action）交替进行，每次动作后从环境获取反馈（Observation），形成 Thought → Action → Observation 的循环。

用一个具体例子来看这三步怎么跑的：

这三步循环的威力在于互相补强：推理帮模型制定计划、追踪状态、处理异常；行动帮模型获取真实世界的数据来校准推理。在ALFWorld和WebShop两个基准上，ReAct比强化学习基线分别高出34%和10%，而且只用了1-2个上下文示例。

目前市面上几乎所有量产Agent产品的内核都是ReAct的某种变体。 Claude Code的主循环、Cursor的Composer、GitHub Copilot的Coding Agent，拆到底都是这个模式。区别在于工程层面的细节：上下文怎么管理、工具怎么编排、错误怎么恢复。

2.3 Tree of Thoughts：当一条路走不通

ToT（Yao et al., NeurIPS 2023）把CoT从一条线扩展成一棵树。每一步生成多个候选推理路径，用LLM自己给每条路径打分（确定/可能/不可能），然后用BFS或DFS在树上搜索，支持回溯。效果很惊人：GPT-4用CoT做24点游戏只有4%成功率，ToT直接拉到74%。

代价也很明显，每一步都要多次LLM调用来生成和评估分支，计算开销是CoT的几十倍。所以实际产品中很少直接用完整的ToT，倒是借鉴了它的回溯思想，在关键决策点做有限分支。

2.4 Reflexion：失败了就反省，用文字代替梯度更新

Shinn等人（NeurIPS 2023）的Reflexion想法特别优雅：与其更新模型权重，不如让Agent用自然语言总结自己哪里做错了，存到记忆里，下次再来。

一个Self-Reflector模块分析失败轨迹，生成文字版的反思（比如上次我在第三步忽略了边界条件检查，这次要先验证输入范围），作为情景记忆注入下一次尝试。

效果立竿见影：HumanEval代码生成从GPT-4裸跑的80%提升到91% pass@1。消融实验证明，反思环节是关键。去掉反思、只做盲目重试的对照组毫无改善。不过也有坑：模型有时候会产生错误的反思，错误诊断自己的问题，反而越改越差。

2.5 LATS：把蒙特卡洛树搜索搬进Agent

LATS（Zhou et al., ICML 2024）是目前推理框架的集大成者。它把AlphaGo式的蒙特卡洛树搜索（MCTS）和LLM Agent结合起来，LLM同时充当行动者、价值函数和优化器。六个操作（选择、扩展、评估、模拟、回传、反思）实现了系统化的探索与利用平衡。在HumanEval上达到了92.7% pass@1，HotPotQA上性能是ReAct的两倍。

当然，LATS的计算开销也是最大的，一个问题可能需要上百次API调用。目前主要用在对正确性要求极高、可以接受高延迟和高成本的场景。

◆三、Agent的记忆系统：上下文窗口不够用了怎么办

Andrej Karpathy有个比喻特别到位：LLM是CPU，上下文窗口是RAM。 RAM大小有限，而Agent在长任务中需要记住大量中间状态，这就产生了记忆管理问题。

3.1 短期记忆：上下文工程取代提示工程

当前模型的上下文窗口从128K（GPT-4 Turbo）到200K（Claude 4系列）到10M（Gemini），看起来很大。但研究表明，随着token数增加，注意力机制的实际召回准确率会下降，特别是中间位置的信息容易丢失（lost-in-the-middle效应），超过约32K token后性能开始明显退化。

所以Anthropic在2025年9月的工程博客里提出了一个新概念：上下文工程（Context Engineering）取代了提示工程（Prompt Engineering）。他们对上下文工程的定义是为下一步推理精心填充上下文窗口的艺术与科学。LangChain把具体策略分成四类：Write（往上下文写信息）、Select（选择包含什么）、Compress（压缩尺寸）、Isolate（隔离关注点）。

实际产品中的做法包括：近期上下文用滑动窗口保留，历史信息做摘要压缩（Claude Code在上下文使用率达到**92-95%**时自动触发压缩），需要的数据通过工具即时检索而非预先加载，以及从对话历史中结构化提取关键状态信息。Manus团队在博客中更直接地说：KV-cache命中率是Agent性能最重要的单一指标。

3.2 长期记忆：从向量数据库到认知架构

短期记忆解决了一次对话内的问题，但Agent跨会话、跨项目的知识积累需要长期记忆。Princeton的CoALA框架（2023）借鉴认知科学，定义了四种记忆类型：

RAG（检索增强生成）目前仍然是语义记忆的主力方案，整体流程如下：

文档切成块、向量化后存入数据库、查询时按余弦相似度检索。OpenAI报告称RAG实现可以将事实错误减少30%。

更新的方案在尝试超越基础RAG。Mem0把向量数据库和知识图谱结合，做实体抽取和冲突消解。Mastra的Observational Memory（2025）用后台的Observer和Reflector两个Agent维护压缩的时间标注观察记录，在LongMemEval上达到94.87%，同时实现4-10倍的成本降低。

其实吧，目前长期记忆最难的问题倒不是怎么记住，而是怎么忘记。什么时候该丢弃过时信息、怎么处理互相矛盾的记忆条目，这块还没有好的自动化方案。

◆四、工具调用、MCP与Skill：Agent的能力从哪来

4.1 Function Calling的工作机制

工具调用的流程本身并不复杂，但每一步的职责边界值得看清楚：

开发者用JSON Schema定义可用工具 → LLM判断是否需要工具并生成结构化参数 → 编排代码执行调用 → 结果返回给LLM。各家大模型厂商的实现已经高度趋同，OpenAI用 tools 参数，Anthropic用 tool_use 和 tool_result 内容块，底层逻辑一样。Martin Fowler团队的技术博客对这个流程有非常清晰的图解，推荐一读。

Anthropic在2025年11月做了两个比较有突破性的改进（详见官方博客）。一个是Tool Search Tool，让Agent按需发现工具而非预先加载所有工具定义，token消耗降低85%。另一个是Programmatic Tool Calling，让Claude写Python脚本来编排工具调用，在沙箱中一次性执行，取代了以前一个一个来回往返的低效模式。

4.2 MCP：Agent时代的USB接口

2024年11月Anthropic发布的Model Context Protocol（MCP）已经成为2026年初工具集成的事实标准。类比来说，以前每个AI助手连接每个数据源都要写专门的适配器（N×M问题），MCP把它变成了一个统一的接口协议（N+M问题）：

基于JSON-RPC 2.0规范通信，MCP提供三个服务端原语（工具Tools、资源Resources、提示Prompts）和两个客户端原语（根目录Roots、采样Sampling）。目前社区已经构建了数千个MCP服务器，覆盖Google Drive、Slack、GitHub、PostgreSQL等常见服务。OpenAI、Microsoft以及主流Agent框架都已支持MCP。

Google在2025年4月推出了互补的A2A（Agent-to-Agent）协议，定位Agent之间的通信。但从实际采用速度来看，MCP的生态优势更明显。Zilliz对三者做过详细对比：Function Calling解决单个模型和工具的连接，MCP解决Agent和工具生态的标准化连接，A2A解决Agent和Agent之间的互操作。

4.3 Skill：解决MCP上下文爆炸的分层方案

MCP把Agent和工具生态连通了，但随之带来一个严重的工程问题：工具越接越多，上下文直接爆炸。 回顾1.1节讲的API结构，每次调用都要把所有工具的JSON Schema定义塞进 messages 里。一个MCP工具的定义（名称、描述、参数结构）平均占200-500 token，接50个工具就是1-2.5万token，接几百个就是15万+ token，还没开始干活上下文窗口就用掉一大半。而且按6.2节讲的缓存机制，这些工具定义虽然能缓存，但它们挤占了本来可以给对话历史和任务上下文用的空间。

Skill就是为了解决这个问题而出现的分层封装方案。核心思路是把"什么时候触发"和"具体怎么做"拆开：Agent平时只加载所有Skill的轻量描述（每个几十token），匹配到具体任务后再按需加载对应Skill的完整指令。

说白了这跟iOS开发里的懒加载是一个道理：不要一口气把所有资源全加载到内存里，用到哪个加载哪个。区别在于Skill不只是延迟加载工具定义，它加载的是一整套执行方案：用什么库、分几步做、有哪些坑要避开、代码模板长什么样。

一个Skill的标准结构长这样：

以"创建Word文档"为例：Skill描述写着"当用户提到Word文档、.docx、报告、备忘录等关键词时触发"，这段描述只有几十token常驻上下文。当用户确实说了"帮我写个报告"，Agent匹配到这个Skill，这时候才去读取SKILL.md，里面写着用python-docx库、格式规范、页眉页脚怎么处理、表格怎么加样式等完整指南。读完之后Agent就知道该调用哪些工具、按什么顺序调用、每步要注意什么。

整个流程可以理解为两阶段检索：

这个两阶段设计跟4.1节讲的Anthropic Tool Search Tool（token消耗降低85%）是同一个思路，只不过Tool Search是在工具级别做按需发现，Skill是在更高的能力模块级别做按需加载。两者可以叠加使用：Skill先确定"这个任务需要做Word文档"，SKILL.md里指定了需要用到的工具子集，然后Tool Search在这个子集范围内进一步按需加载具体工具定义。

Skill协议和MCP协议的关系可以这样理解： MCP解决了"Agent怎么连接工具"的标准化问题，Skill解决了"工具太多导致上下文爆炸"和"怎么把使用工具的经验知识封装复用"这两个问题。MCP是能力接入层，Skill是能力编排层。

Skill的来源主要有三类。平台预置技能是最常见的，Agent平台方把高频场景的最佳实践封装成内置Skill，比如文档处理（docx/pdf/pptx/xlsx各一套）、前端设计、代码生成等，用户拿来即用。团队/个人沉淀技能是使用者根据自己的工作场景编写的Skill，比如"我们团队的iOS项目发布流程""我们公司的代码审查规范"，这些Skill包含了领域专有知识和团队约定，其他通用Agent根本不可能知道。AI自动生成技能则是让Agent在执行任务过程中把成功经验自动提炼成可复用的Skill。

AI自动生成这条线上，Voyager（Wang et al., NeurIPS 2023 Spotlight）是最经典的示范。它在Minecraft里实现了一个完整的技能积累闭环：Agent遇到新任务 → 写代码解决 → 环境验证 → 成功则存入技能库打标签 → 下次检索复用。跑了160轮后发现新物品的速度比无技能库基线快3.3倍，而且关键特性是技能可以组合调用，高级技能调用低级技能，形成层级化的能力体系。Google DeepMind的LATM（ICLR 2024）进一步做了经济化：强模型造Skill、弱模型用Skill，昂贵的"造"只付一次。Meta的Toolformer（NeurIPS 2023）则在训练阶段就让模型自监督地学会什么时候该用工具。

落到实际产品里，Skill已经不只是一个概念，而是一个正式的开放标准了。Anthropic在2025年10月首次发布Agent Skills，12月18日将其作为开放标准发布在agentskills.io，走的是和MCP完全一样的路线：先在自家产品跑通，再开放给全行业。Microsoft、OpenAI、Cursor、GitHub已经采纳了这个标准，Canva、Stripe、Notion、Figma、Atlassian、Cloudflare、Zapier等公司在发布当天就提供了合作伙伴预置技能。

Agent Skills的官方规范定义了一个清晰的协议结构。一个Skill就是一个文件夹，核心是SKILL.md文件，必须以YAML frontmatter开头（包含name和description），正文是Markdown格式的完整执行指南。Anthropic把这个设计叫做渐进式披露（Progressive Disclosure）：Agent启动时只预加载所有Skill的name和description到系统提示里（第一层），当判断某个Skill跟当前任务相关时，才读取完整的SKILL.md正文（第二层），如果Skill文件夹里还有子目录和额外资源，按需继续加载（第三层）。

这里有一个很容易被忽略的关键能力：Skill不只是一堆文字指令，它的文件夹里可以包含可执行代码。 Anthropic在官方博客里用PDF Skill举了一个很好的例子：PDF Skill的文件夹里除了SKILL.md之外，还放了一个预写好的Python脚本，专门用来读取PDF并提取所有表单字段。Agent需要填表时，直接运行这个脚本就行，不需要把脚本代码或PDF文件加载到上下文窗口里。

这个设计的意义在于：LLM擅长理解意图、规划步骤、生成文本，但有些操作用传统代码跑更高效也更可靠。比如排序一个列表，让LLM用token一个个生成排序结果既慢又贵，直接跑个排序算法是确定性的、可重复的。Skill把这两者结合起来了：SKILL.md里的指令告诉Agent什么时候该用、整体流程是什么，打包的脚本解决具体操作的确定性执行。

说白了，Skill = 指令文档 + 可执行代码 + 辅助资源，三者打包在一个文件夹里。 Agent根据任务需要，该读文档读文档，该跑脚本跑脚本。这让Skill既能传递"怎么做"的知识，也能直接提供"做这件事"的工具，不依赖外部MCP服务就能自成体系地完成任务。

Simon Willison对MCP和Agent Skills关系的总结最为精准：MCP提供工具访问的管道（plumbing），Agent Skills提供如何有效使用这些工具的程序记忆（brain）。 MCP告诉Agent有哪些工具可用，Agent Skills教Agent怎么用这些工具。但Agent Skills同时也能自带可执行代码充当工具，所以它既是"brain"也可以自己带"hands"。两者是Agentic技术栈的互补层，而非严格的上下层依赖关系。

在Agent Skills开放标准发布9天之前（12月9日），Anthropic联合Block和OpenAI把MCP捐赠给了Linux Foundation下新成立的Agentic AI Foundation（AAIF）。从时间线看，Anthropic的策略很清晰：先用MCP定义了Agent怎么连接工具，再用Agent Skills定义了Agent怎么获取和复用知识，两个协议加起来构成了Agent能力获取的完整基础设施。而且都走开放标准路线，不做厂商锁定，靠执行质量竞争。

目前在Claude.ai、Claude Code、Claude Agent SDK和Claude Developer Platform上原生支持Agent Skills，同时Goose、VS Code、Codex CLI等第三方工具也已接入。企业版（Team和Enterprise计划）支持集中管理Skill，IT管理员可以统一控制Agent有哪些能力、谁可以编辑。Anthropic也提到了未来方向：让Agent自己创建、编辑和评估Skill，把成功的行为模式自动沉淀为可复用的技能包，这就和Voyager的自动技能积累思路完全接上了。

◆五、多Agent协作：什么时候该上多个Agent

单Agent能力有天花板。任务足够复杂时，把不同专长分配给不同Agent确实能提升质量。MetaGPT（ICLR 2024）的研究发现，引入类似软件公司SOP的角色分工，能显著降低LLM Agent之间的无效协作，代码生成达到85.9% Pass@1。但多Agent架构的复杂度也是实打实的，不到万不得已别上。

目前的协作模式主要有这几种：

框架方面，2026年初的格局比较清晰了。LangGraph在状态管理上最精细，用有向图+检查点实现复杂流程。CrewAI走角色扮演路线，每个Agent有角色、目标、背景故事，号称被60%的财富500强采用。OpenAI Agents SDK（从实验性的Swarm演化而来）最轻量，四个核心概念：Agents、Handoffs、Guardrails、Tracing。Microsoft在2025年10月合并了AutoGen和Semantic Kernel为统一的Agent Framework，走企业级路线。

Du等人在ICML 2024上发表的多Agent辩论研究显示，让多个Agent互相质疑推理过程，准确率提高4-6%，事实性错误减少30%以上。这种模式特别适合需要高可靠性的场景。

◆六、效率与效果的平衡：Agent的经济学

这是整个Agent领域目前工程难度最高的部分。因为Agent是循环调用LLM，成本会随步骤数快速膨胀。output token的价格是input token的3-5倍，一个复杂任务跑下来几十步，费用轻松破美元。好在业界已经积累了一套分层优化策略：

6.1 模型级联与智能路由：把钱花在刀刃上

核心思路很朴素：简单问题用便宜的小模型，复杂问题才上贵的大模型。GPT-5内部就是这么干的，用一个高效模型处理大多数请求，困难问题再切换到深度推理模型。LMSYS的RouteLLM验证了这个策略可以在保持95%顶级模型性能的同时降低85%以上的成本。ETH Zurich的Cascade Routing框架（ICML 2025）进一步统一了路由和级联策略，比单独使用任一方法好14%。

6.2 提示缓存：Agent场景的杀手级优化

理解了1.1节的消息结构之后，缓存的价值就很直观了：Agent每一轮循环，发给API的 messages 数组里绝大部分内容（系统提示、工具定义、前面所有轮次的历史）都跟上一轮完全一样，只有末尾多了几条新消息。如果服务端能"记住"之前处理过的部分，只计算新增的部分，开销就能大幅下降。这就是提示缓存（Prompt Caching）干的事。

缓存的核心机制是前缀匹配。 Anthropic和OpenAI的实现细节略有不同，但原理一致：服务端把你发送的token序列从头开始逐个比对，只要和上一次请求的前缀完全一致，这部分就直接复用之前计算好的KV缓存（Transformer注意力机制中间产物），不需要重新计算。用一个图来说明：

第N+1轮调用时，前18,000个token（系统提示+工具定义+历史消息1-20）和第N轮完全一样，直接命中缓存。只有新增的2,000 token需要从头计算。Anthropic对缓存命中的token收费是标准价格的十分之一，OpenAI对超过1024 token的提示自动开启缓存。按上面的例子算，第N+1轮的input成本大约只有无缓存时的20%。

但缓存有一个致命的脆弱性：前缀必须严格一致，中间哪怕改了一个token，从那个位置往后的缓存就全部失效。 这意味着如果你在两轮之间动了系统提示、重新排列了工具定义的顺序、或者对历史消息做了任何修改（比如删掉早期消息来节省token），整个缓存链条就断了。

用一个直观的例子说明：

理解了这个机制，Manus团队分享的那些优化策略就完全讲得通了：

策略一：工具定义保持静态。 哪怕某些工具在当前任务中用不到，也别从列表里删掉，因为删除会改变后续所有token的位置，导致整段缓存失效。宁可多花一点token保持定义不变，换来的缓存命中收益远大于这点浪费。

策略二：只在 messages 数组末尾追加，永远不要修改前面的内容。 很多Agent框架为了"节省token"会做历史消息的截断或摘要替换，倒是把历史变短了，但缓存也全废了。Manus的做法是即使Agent走了弯路，也把错误的步骤留在上下文里不删除，因为删除会破坏前缀一致性。

策略三：把变化频率低的内容放在 messages 数组的前面。 系统提示（永远不变）→ 工具定义（几乎不变）→ 全局规划（偶尔更新）→ 对话历史（每轮追加）→ 当前消息（每轮变化），这个排列顺序能保证最长的前缀始终命中缓存。Manus团队透露他们每一步都会把全局计划追加到上下文末尾而非替换中间的计划内容，就是为了不打断缓存链。

其实吧，如果用做iOS开发的经验来类比，提示缓存的前缀匹配逻辑跟HTTP的ETag条件请求异曲同工：服务端记住上次的结果，客户端下次带着同样的标识来，如果匹配就省掉重复计算。只不过LLM的缓存粒度更细，是token级别的前缀匹配，而非整个请求的哈希比对。

6.3 思考预算：精细控制推理深度

Anthropic的extended thinking支持 budget_tokens 参数（1,024到128,000+），性能随思考token数对数增长。TALE框架（ACL 2025）根据问题复杂度动态调整推理token量，实现67%的输出token成本降低且准确率损失极小。Claude的effort参数（low/medium/high/max）更直接，一个开关控制整体的投入程度。

6.4 数据格式也是成本

一个很多人忽略的细节：同样的数据，Markdown比YAML节省10%的token，比JSON节省34-38%。表格数据用CSV比JSON节省40-50%。Anthropic的代码执行方案通过按需加载工具定义实现了98.7%的token缩减。这些看起来是小优化，但在Agent的循环里会被放大很多倍。

◆七、真实产品是怎么做的：拆解三个典型架构

同样的Agent基本原理，不同产品做出了截然不同的架构选择。三个代表性产品的核心差异一目了然：

7.1 Claude Code：从极简主义到Agent Teams

Claude Code的核心架构至今没变：单线程主循环，一个扁平的消息历史，最朴素的 while(tool_call) → execute → feed results → repeat。 PromptLayer对其Agent Loop的拆解显示，早期规划靠TODO列表（JSON格式的扁平清单），但这套机制有明显缺陷：Todo只活在内存里，关掉会话就没了，子Agent也拿不到主Agent的任务状态。2026年1月（v2.1.16），Anthropic正式用Tasks系统替换了Todo，这是一个重要的架构升级。Tasks和Todo的核心区别在于三点：支持依赖关系追踪（任务之间形成有向无环图DAG，Task 3可以声明"必须等Task 1和Task 2完成才能开始"，防止LLM跳步执行还没写出来的代码的测试）；文件系统持久化（任务状态写入 ~/.claude/tasks/，关掉终端、换台机器、系统崩溃后都能恢复）；跨会话和跨Agent协作（多个子Agent或Agent Teams的Teammate可以共享同一个任务列表，用文件锁防止竞争）。跨会话记忆靠CLAUDE.md文件和Skills，上下文快满了触发压缩。这套从简单到逐步完善的设计让Claude Code在2026年2月贡献了GitHub公开commits的4%，年化收入25亿美元。

但"极简主义的胜利"这个标签已经不完全准确了。随着Opus 4.6发布，Claude Code推出了Agent Teams（目前实验性功能），架构复杂度上了一个台阶。

Agent Teams和之前的Task子Agent有本质区别。子Agent是单线程模型：主Agent派出一个子Agent去探索，子Agent只能把结果汇报回来，彼此之间不能通信，所有信息必须经过主Agent中转。Agent Teams打破了这个瓶颈：

每个Teammate是一个完全独立的Claude Code实例，有自己的上下文窗口，自动加载项目的CLAUDE.md、MCP服务器和Skills，但不继承Team Lead的对话历史（从干净状态启动，只拿到Lead给的任务描述）。Teammate之间通过邮箱系统（Mailbox）直接互发消息，通过共享任务列表自动认领下一个未阻塞的任务，任务认领用文件锁防止竞争。

Anthropic工程博客上有一个极端案例很能说明Agent Teams的潜力：有人用16个Agent协作，跑了近2,000个Claude Code会话、花了$20,000 API费用，从零开始写了一个10万行的Rust C编译器，能编译Linux 6.9内核（支持x86、ARM、RISC-V）。每个Agent在独立的Docker容器里工作，通过git推送同步代码，用文件锁防止任务冲突。

不过Agent Teams目前仍是实验性功能（需要手动设置环境变量开启），有明确的局限：Teammate的token成本大约是单Agent的5倍，两个Teammate编辑同一个文件会导致覆盖冲突，长时间无人监督容易浪费算力。Addy Osmani的评价比较中肯：Agent Teams对并行性强的大型任务（代码审查、跨模块重构、多角度调研）效果显著，但对简单任务来说，单Agent仍然是更经济的选择。

说白了，Claude Code的演进路径很清晰：先把单Agent做到极致可靠，再在上面叠加多Agent协作能力。 核心循环没变，变的是协作层。这和Anthropic一贯的风格一致：能用简单方案解决的就别上复杂架构，复杂度只在确实需要时才加。

7.2 Cursor：多Agent并行的激进路线

Cursor 2.0（2025年10月）走的是另一个极端。它引入了自研的Composer模型（混合专家架构，用RL在Agent工作流上训练，号称生成速度是同等智能模型的4倍），支持最多8个Agent同时运行，通过git worktree或远程沙箱实现隔离，有一个Mission Control界面同时监控所有Agent的进度。四层规则系统（.cursor/rules、用户规则、团队规则、AGENTS.md）保证配置持久化。这种架构对并行任务很强，但复杂度也高得多。日活超100万开发者，ARR突破10亿美元。

7.3 Devin：端到端自主的代表

Devin的定位和前两者不同，它不是辅助编程，而是独立完成整个项目。运行在自包含的云端沙箱里（shell + 编辑器 + 浏览器），从规划到编码到测试到部署全部自己来。Devin 2025年度评估显示，Nubank用它做了800万行以上代码的ETL迁移，报告了8-12倍的效率提升。

Devin有一个有意思的特性：复合学习。在同一类迁移任务上，它看到的例子越多，越能避免走弯路。但它也有明确的局限：需要清晰的需求定义，模糊任务上表现差很多。

这三个产品有一个共同趋势值得注意：都采用了仓库级指令文件来持久化项目上下文。Claude Code的CLAUDE.md、Codex的AGENTS.md、Cursor的.cursor/rules、Copilot的.github/copilot-instructions.md，名字不同但作用一样，每次会话自动加载项目级的规则和偏好。而4.3节提到的Agent Skills开放标准正在把这些各自为政的格式统一起来，写一次Skill、跨平台复用。

◆八、Agent的硬伤：还没解决的问题

说完了原理和产品，最后聊聊目前Agent的核心困境。这些问题不是工程优化能解决的，而是架构层面的硬伤。

错误传播是最致命的。Agent是多步决策，第一步犯的小错会在后续步骤里被放大。一个库存Agent幻觉出一个不存在的SKU，然后调用下游API去定价、备货、发货，一连串系统全被污染。Galileo的Agent失败模式指南把这类问题归纳为7大类，值得做Agent开发的人通读一遍。

幻觉级联在Agent场景里比单模型幻觉危险得多。2025年9月的一篇综述将其形式化为：Agent幻觉是多组件的（感知、推理、行动阶段都可能发生）、累积的（小幻觉迭代放大）、有物理后果的。多Agent系统还会出现分布式幻觉，Agent们互相验证对方的错误结论，把谬误强化成共享信念。

提示注入是Simon Willison反复强调的Agent安全致命三角（lethal trifecta）：私有数据访问 + 不可信内容暴露 + 数据外泄能力。三者兼具时，不存在100%可靠的防御方案，目前没有类似参数化SQL查询那样的根治手段。

成本失控藏在每个生产部署里。ToT一个问题需要100+次API调用，带反思的多Agent系统token消耗是单次提示的10-100倍，几百个工具定义光加载就吃掉15万+ token。没有显式预算限制，Agent可以无限探索下去。

◆九、推荐阅读路径

如果想系统学习Agent，我建议按这个顺序读。

入门建立全局认知：先读Lilian Weng的LLM Powered Autonomous Agents建立 Agent = LLM + 规划 + 记忆 + 工具 的认知框架，再读Anthropic的Building Effective Agents理解workflow和agent的区分，然后看Andrew Ng的四种Agent设计模式演讲（Reflection、Tool Use、Planning、Multi-Agent），吴恩达的关键洞察是即使GPT-3.5配上Agent工作流也能超过裸跑的GPT-4。

核心论文理解推理和行动机制：Chain-of-Thought（Wei et al., NeurIPS 2022）→ ReAct（Yao et al., ICLR 2023）→ Tree of Thoughts（Yao et al., NeurIPS 2023）→ Reflexion（Shinn et al., NeurIPS 2023）→ LATS（Zhou et al., ICML 2024）→ Toolformer（Schick et al., NeurIPS 2023），按这个顺序一路读下来，推理框架的演进脉络就完整了。

面向生产实践：Anthropic的上下文工程指南、Manus的Context Engineering实战经验、以及2026年2月刚发布的2025 AI Agent Index（对30个主流Agent的技术和安全特性做了系统性记录）。

独立视角持续跟读：Simon Willison的博客是目前对Agent最冷静的独立分析来源，他对Agent的定义和致命三角概念已经被广泛引用。2025 Agentic AI综合综述（Abou Ali et al., Artificial Intelligence Review）提出了符号-神经双范式框架，适合想深挖理论的读者。

总结一下。Agent的原理拆开看并不神秘：一个LLM在循环里调用工具，辅以规划、记忆和推理框架来提升决策质量。效率和效果的平衡则靠一系列工程手段：模型级联控制成本、提示缓存减少重复开销、思考预算动态调节推理深度、上下文工程确保有限窗口里装最有用的信息。

但有一点很重要：目前所有成功的Agent产品都遵循一个共同原则，就是在够用的前提下选最简单的架构。 Claude Code用单线程循环打天下，效果不比复杂的多Agent方案差。Anthropic那句话值得反复品味，能用workflow搞定的别上agent，能用单agent搞定的别上multi-agent。复杂度不是能力的证明，可靠性才是。