2022 年做 Agent 的人抱怨没有方法，2026 年做 Agent 的人抱怨方法太多：几十个框架、上千篇论文、每周一个新范式。但这两种抱怨其实是同一个问题——你分不清哪些决策已经收敛、哪些还没有。已收敛的决策点，工业界有默认答案，抄就是了，自己发明是浪费；未收敛的决策点，谁的答案都别全信，要自己做实验。这篇文章的全部工作，就是把 Agent 工程拆成六个决策点，然后逐个回答：它收敛了吗？
判断一个决策点是否收敛，我用一个可操作的标准：存在一条完整的「论文→产品」传导链——有论文把原理讲清楚（为什么这样做是对的），且有不止一家的生产系统把它落成了默认组件（不这样做反而要解释）。链条完整，就是收敛；只有论文没有产品，或只有产品没有原理，都算未收敛。
这篇是我 Agent 工程系列的「地图篇」。之前的《Agent 工程七问》讲原理（把真相移到模型外面），《六层系统》讲架构分层，这篇讲选型：每个决策点上，源头论文是哪篇、技术代表是什么、你该抄还是该赌。
决策点一：控制流——谁决定下一步？
根本问题：任务的执行路径是人在代码里写死，还是模型在运行时自己定？
源头论文：ReAct（arXiv 2210.03629，2022）。Yao 等人证明了一件现在看理所当然、当时并不显然的事：让模型交替生成「推理痕迹」和「行动」，推理帮模型跟踪和修订计划，行动让模型从外部世界拿回新信息。这个 Thought→Action→Observation 循环，就是今天几乎所有 Agent 框架里那个 while 循环的学术源头。
落地技术代表：Anthropic 的工程博客《Building Effective Agents》给了工业界最被引用的决策框架——先区分 workflow（LLM 和工具被预定义代码路径编排，可预测）和 agent（LLM 在运行时自己决定过程和工具使用，灵活），然后给出一条反直觉的建议：从最简单的方案开始，很多场景根本不需要 agent，一次检索增强的单模型调用就够了。需要预定义编排时用图框架（LangGraph 的 checkpointer + 图控制流是代表）；需要模型自主时用单循环 harness（Claude Code / Claude Agent SDK 的 gather context → take action → verify → repeat 是代表）。
收敛度：已收敛。默认答案是「能 workflow 就 workflow，要 agent 就用单循环 + 强模型」。值得注意的是收敛的方向：过去两年编排层的巧劲（复杂的图、角色扮演、精心设计的 pipeline）被不断拆除，换成更简单的循环加更强的模型——这是苦涩教训（Bitter Lesson）在 Agent 工程层的重演。循环与图的详细取舍我在《Loop 还是 Graph》里拆过。
决策点二：行动接口——Agent 用什么动世界？
根本问题：模型的输出如何变成对世界的操作？接口长什么样，直接决定成功率上限。
源头论文有两篇，分别回答「接口该为谁设计」和「动作该用什么表示」：
- SWE-agent（arXiv 2405.15793，NeurIPS 2024）提出 ACI（Agent-Computer Interface）：LM agent 是一类新用户，需要专门为它设计的界面。同一个模型，把「给人用的 shell」换成「给 agent 设计的文件查看器/编辑器」，SWE-bench 解题率显著提升。工具不是模型的附件，是模型能力的放大器或瓶颈。
- CodeAct（arXiv 2402.01030，ICML 2024）回答表示问题：与其让模型生成受限的 JSON 工具调用，不如让它直接生成可执行 Python 代码作为统一动作空间——17 个模型的测试中成功率最高提升 20%。代码天然支持组合、循环、中间变量，JSON 不支持。
落地技术代表：协议层是 MCP（Model Context Protocol）。2024 年 11 月由 Anthropic 发布，2025 年 12 月捐给 Linux 基金会旗下新成立的 Agentic AI Foundation（OpenAI、Google、Microsoft、AWS 均为成员），已集成进 ChatGPT、Gemini、Copilot、VS Code——工具接入协议之争实质结束。动作表示层则两条路线并存：JSON tool call（生态最广）和 code-as-action（CodeAct 路线，OpenHands、smolagents 是代表；bash + 文件系统这个「最古老的 ACI」依然是 coding agent 的主力）。
收敛度：协议层已收敛（MCP），表示层收敛中。实践默认：通用集成用 MCP tool call；动作之间需要组合与数据流动的场景（数据分析、批量操作）用代码执行。工具解剖的细节见《Agent Search 工具解剖》，模型为什么会伸手拿工具见《LLM 为什么伸手》。
决策点三：上下文与记忆——窗口装不下怎么办？
根本问题：上下文窗口有限且中段注意力衰减，长任务的信息必须被分层管理：这一刻喂什么进窗口，长期记什么在窗口外。
源头论文：
- MemGPT（arXiv 2310.08560，2023）把操作系统的虚拟内存思想搬进来：窗口是”主存”，外部存储是”磁盘”，由系统在两者间调页——今天所有「分层记忆」产品的共同祖先，后来直接演化成 Letta 公司。
- CoALA（arXiv 2309.02427，2023）从认知科学借来分类学：working memory（窗口内的活跃变量）与长期记忆三分——episodic（做过什么）、semantic（知道什么事实）、procedural（按什么规则行事）。这套词汇现在是记忆系统设计的通用语言。
- 《A Survey of Context Engineering for LLMs》（arXiv 2507.13334，2025）综合 1400+ 篇论文，把「上下文工程」立为正式学科：检索/生成、处理、管理三大基础组件，向上组装成 RAG、记忆系统、多智能体。
落地技术代表：Claude Code 是最容易观察的样本——compaction（把长历史摘要成总结，等价于数据库 checkpoint）、CLAUDE.md（procedural memory 的文件化）、子代理隔离上下文（把大结果挡在主窗口外面）。「context engineering」这个词经由 Cognition 2025 年的博客等推手进入主流词汇表，一年内从口号变成岗位名。
收敛度：思想已收敛，实现未收敛。「分层记忆 + 主动管理窗口」没有争议，但具体记忆系统（怎么写入、怎么检索、怎么遗忘）各家自研、没有赢家——这是六个决策点里论文最多、共识最少的一个。我此前拆过驱逐机制和遗忘作为能力，都属于这个决策点的分支。
决策点四：单体还是多体？
根本问题：一个 Agent 干到底，还是拆成多个 Agent 协作？这是 2025 年吵得最凶的问题，也是最适合展示「用论文断案」的问题。
源头论文：《Why Do Multi-Agent LLM Systems Fail?》（MAST，arXiv 2503.13657，2025）。Berkeley 团队分析 7 个流行多智能体框架、200+ 任务，归纳出 14 种失败模式、三大类：规约缺陷（角色/任务定义不清）、智能体间失调（信息不共享、决策冲突）、验证缺失（没人把关成败）。关键结论：失败大多源于系统设计，而不是模型不够聪明——换更强的模型救不了坏的协作结构。
工业界的两极与和解：Cognition 的 《Don’t Build Multi-Agents》主张单线程——每个动作都携带隐式决策，并行智能体的隐式决策会互相冲突，除非共享完整轨迹（不是消息摘要）；几乎同期 Anthropic 发布多智能体研究系统，用 orchestrator + 并行 subagent 做深度调研，并给出成本刻度：agent 消耗约 4 倍于聊天的 token，多智能体系统约 15 倍。LangChain 后来的调和文点破两篇共识大于分歧：「读」型任务（并行检索、各自独立）适合多体，「写」型任务（改同一份代码/文档）适合单体——写操作的隐式决策冲突正是 MAST 分类里的第二类失败。
收敛度：判据已收敛，边界仍在移动。默认答案：单体起步；只有任务可分解为互相独立的并行读操作、且你付得起 15 倍 token 时，才上多体。Cognition 作者本人 2026 年也松口「找到了一些真正可行的多体配置」，说明边界还在探索。多体编排的深水区我在《Agent Swarm 深读》里写过。
决策点五：评测——什么算成功？
根本问题：随机内核意味着单次成功不算数。不解决「什么算成功、多稳算可靠」，前四个决策点的任何优化都无法被验证。
源头论文：τ-bench（arXiv 2406.12045，2024）。两个设计现在成了行业口径：以世界终态论成败——对话结束后比对数据库终态与标注目标态，模型说什么不重要，世界变成什么样才重要（呼应七问里「把成败的真相放进世界的终态」）；pass^k 度量可靠性——同一任务跑 k 次全部成功才算通过。论文里最扎心的发现：当时最强的 function calling agent（gpt-4o）总体成功率不足 50%，零售域 pass^8 掉到 25% 以下——单次演示与可靠服务之间差着一倍以上的距离。后续 τ²-bench（arXiv 2506.07982）把用户也变成有状态的参与者，继续加压。
落地技术代表：coding agent 的终态验证器是现成的——测试通过即成功，这是 SWE-bench 系的根基，也是为什么 coding 成为 Agent 第一个成熟场景：验证器最便宜的领域，Agent 进化最快。通用域的对应物是 AgentBench 一系（我的评测笔记拆过）。生产实践里，评测正在从「上线前跑基准」变成「harness 内置验证步骤」——好 harness 的标准里，verify 是循环的一等公民。
收敛度：口径已收敛（终态 + 多次采样），领域基准未收敛。你的业务域大概率没有现成基准，自建 eval 是绕不开的必修课。
决策点六：能力提升——靠外挂还是靠训练？
根本问题：Agent 表现不够好时，改进往哪里投——上下文里的知识外挂，还是模型权重本身？
源头论文：
- 外挂路线：Voyager（arXiv 2305.16291，2023）在 Minecraft 里让 agent 把学会的行为沉淀成可执行代码技能库，可检索、可组合、不改一个参数。这是今天 Claude Skills / Agent Skills 这类「把经验写成文件供未来调用」机制的学术祖先（我在 Skills 与 MCP 研究前沿里追过这条线）。
- 训练路线：《The Landscape of Agentic RL for LLMs》（arXiv 2509.02547，TMLR 2026）综合 500+ 工作，指出范式迁移：从把 LLM 当单步生成器做 RL（退化的单步 MDP），到把它当嵌入动态环境的决策体（时间上延展的 POMDP）——训练目标从「这句话答对」变成「这条多步轨迹把任务做成」。
落地技术代表：外挂路线是生产默认——prompt/上下文迭代、技能文件、工具改进，成本低、可回滚、不动模型。训练路线（agentic RL、在自家环境里微调）目前主要发生在模型厂和头部 agent 公司，应用团队直接受益于其成果（更强的基座）而很少自己下场。
收敛度：未收敛，这是 explore 区。行业共识只有优先级：先穷尽上下文层的改进，训练是最后手段。但「经验如何自动沉淀为技能」「应用团队要不要自己做 agentic RL」都是开放问题——想赌方向，赌在这里。
合成：一张地图
| 决策点 | 默认答案 | 技术代表 | 源头论文 | 收敛度 |
|---|---|---|---|---|
| 控制流 | 能 workflow 就 workflow；要 agent 就单循环+强模型 | Claude Agent SDK；LangGraph | ReAct 2210.03629 | ✅ 已收敛 |
| 行动接口 | 协议用 MCP；组合密集的动作用代码执行 | MCP；bash+文件系统；OpenHands | SWE-agent 2405.15793；CodeAct 2402.01030 | ✅ 协议层收敛 |
| 上下文与记忆 | 分层记忆 + 主动管理窗口 | Claude Code compaction；Letta | MemGPT 2310.08560；CoALA 2309.02427；综述 2507.13334 | ⚠️ 思想收敛，实现未收敛 |
| 单体 vs 多体 | 单体起步；并行「读」任务且预算够才多体 | 单循环 harness；orchestrator+subagent | MAST 2503.13657 | ⚠️ 判据收敛，边界移动中 |
| 评测 | 世界终态论成败 + pass^k 测可靠 | SWE-bench 系；自建 eval | τ-bench 2406.12045 | ✅ 口径收敛，基准未收敛 |
| 能力提升 | 先穷尽上下文外挂，训练是最后手段 | Skills 技能库；agentic RL（厂内） | Voyager 2305.16291；RL 综述 2509.02547 | ❌ 未收敛 |
读这张表的方式，和读任何一棵搜索树一样：✅ 的节点直接 exploit——抄默认答案，把它们当成不需要重新发明的地基；⚠️ 和 ❌ 的节点才值得 explore——读论文、做实验、形成自己的判断。Agent 工程师的稀缺价值不在六个决策点上都有观点，而在于准确知道哪几个不需要观点。
一个诚实的提醒：这张地图是我从论文和工程博客里合成的，表格里的每个数字（20% 提升、15 倍 token、pass^8 < 25%）都有来源可查，但没有一个是我亲手复现的。检验一张地图的唯一方式是拿着它走一遍路——对我自己，下一步就是用这张地图搭一个最小系统：ReAct 单循环（决策点一）+ bash 工具（决策点二）+ 十个任务的终态 eval 跑 pass^4（决策点五），百行代码以内，把「读过」变成「测过」。
参考来源
arXiv 论文
- ReAct: Synergizing Reasoning and Acting in Language Models（2210.03629）
- CoALA: Cognitive Architectures for Language Agents（2309.02427）
- MemGPT: Towards LLMs as Operating Systems（2310.08560）
- Voyager: An Open-Ended Embodied Agent with Large Language Models（2305.16291）
- Executable Code Actions Elicit Better LLM Agents（2402.01030）
- SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering（2405.15793）
- τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains（2406.12045）、τ²-bench（2506.07982）
- Why Do Multi-Agent LLM Systems Fail?（2503.13657）
- A Survey of Context Engineering for Large Language Models（2507.13334）
- The Landscape of Agentic Reinforcement Learning for LLMs: A Survey（2509.02547）
工程实践
- Anthropic: Building Effective Agents
- Anthropic: How we built our multi-agent research system
- Anthropic: Building agents with the Claude Agent SDK
- Cognition: Don’t Build Multi-Agents
- LangChain: How and when to build multi-agent systems
- Anthropic: Donating MCP and establishing the Agentic AI Foundation