Agent 架构基础
Agent 和聊天机器人的本质区别，不是模型更大，而是有没有行动循环。 聊天机器人等待用户驱动，每轮输出文本；Agent 围绕目标持续运转，输出的是行动——调用工具、写入文件、执行代码、操作界面。行动会产生真实的副作用，观察结果后继续推进，直到目标完成或触发人工干预。这个感知→推理→行动→观察的闭环，是 Agent 的定义性特征。
Lilian Weng（OpenAI）2023 年提出的框架将 Agent 拆解为四个必要组件：核心推理模型（LLM）+ 记忆（Memory）+ 规划（Planning）+ 工具使用（Tool Use）。缺少任何一项，系统就退化为更弱的形式——没有工具是聊天机器人，没有记忆是无状态处理器，没有规划是纯反射式系统。
记忆系统：三个存储层次
Agent 的记忆不是一个统一的存储，而是三个层次不同的机制。
上下文内记忆（In-Context Memory）是当前任务的工作记忆——对话历史、工具调用记录、检索到的文档。它直接可访问，无需检索，但受到 token 预算的严格约束，随任务推进不断增长，是 Agent 架构中最核心的瓶颈资源。
外部记忆（External Memory）是上下文窗口之外、通过检索访问的持久化存储——向量数据库中的历史交互、关系型数据库中的结构化数据、文件系统中的中间结果。外部记忆的容量几乎无限，但访问有延迟，且检索质量决定了注入的信息质量。
参数记忆（Parametric Memory）是模型权重中隐式编码的预训练知识和 Fine-tuning 技能。它覆盖广泛、访问零成本，但有训练截止限制，运行时不可更新，且容易幻觉。
上下文内记忆是三者中最需要主动管理的。 随着任务推进，历史信息会超出窗口容量，或因为"迷失在中间"效应而被忽略。常见的管理策略是滚动摘要：最近几轮完整保留（工作记忆），更早的历史压缩为摘要（情节记忆），关键决策和事实提取存入外部存储（语义记忆），按需检索注入。必须保留的是：用户的明确约束、已确认的决策、以及错误记录——防止 Agent 在多轮中重复同样的错误是长链任务可靠性的基础。
规划：三种主流模式及其权衡
ReAct 是目前使用最广的规划模式，因为它实现简单且自适应。 Yao 等人 2022 年提出的 ReAct（Reasoning + Acting）把推理轨迹和行动交织在一起：每次行动前显式输出 Thought，行动后处理 Observation，再决定下一步。这种模式可以根据工具返回的实际结果动态调整计划，而不是机械执行预定步骤。缺点是贪心式推进，没有回溯机制，早期走偏后难以纠正。
Tree of Thoughts 解决了 ReAct 无法回溯的问题，但计算成本极高。 ToT 将问题求解建模为树搜索，在每个节点生成多个候选思路，用评估函数打分，剪枝后继续展开最优分支，支持回溯。在数学推理、创意写作等需要全局优化的任务上效果显著，但每次推理需要 5-10 倍于 ReAct 的 LLM 调用次数，工具调用密集的工程任务中实用性有限。
Plan-and-Execute 把规划和执行解耦，适合需要人工审查的场景。 先由规划器生成完整的任务步骤列表，再由执行器逐步运行，遇到意外时触发重规划。计划可以在执行前被人类审查，这是对需要"先确认再执行"的高风险任务的重要特性。但初始计划往往脱离实际，环境变化时重规划成本高。
规划并非越多越好，有时过度规划是有害的。 当任务简单时，规划开销大于收益；当环境变化快时，精心制定的计划瞬间过时；当 LLM 本身无法准确预估步骤时，长计划是"有害的自信"。Valmeekam 等人 2023 年的研究发现，当前 LLM 在无工具辅助的纯规划任务上仍然表现较差——规划能力很大程度上依赖工具调用形成的反馈闭环，而不是模型本身的推理能力。
工具调用：机制与设计原则
工具调用的本质是结构化文本生成，执行由宿主程序完成，模型本身不执行任何代码。 模型生成包含工具名和参数的 JSON 结构，宿主程序解析后调用对应函数，将结果注入下一轮上下文。这意味着：工具调用的可靠性取决于模型生成合法 JSON 的能力；工具执行失败和模型调用失败是两个独立问题，需要分别监控。
好工具的设计原则：单一职责、名称即文档、参数最小化、错误信息可行动。 每个工具只做一件事，避免"万能工具"——工具越复杂，模型选择和填参的错误概率越高。工具名应是自解释的动词短语（search_web、read_file），而不是模糊的通用词（process、handle）。参数数量越少越好，必要时用枚举值约束输入。返回错误时要告诉 Agent 下一步怎么做——"File not found. Use list_files() to see available files." 比 "Error: 404" 有用得多。
工具数量超过 20 个时，模型选择工具的准确率会显著下降。 解决方案是工具检索：将工具定义存入向量库，按当前任务动态检索相关工具子集注入上下文，而不是把所有工具一次性塞进 System Prompt。这是上下文工程在工具管理上的直接应用。
观察与反思
观察不只是"接收工具结果"，还包括验证、整合和推断。 工具返回的原始输出需要被解析（从中提取有效信息）、验证（是否符合预期）、整合（与已有状态合并），并从中推断隐含信息。工具结果格式化同样重要：关键信息前置（模型对结果开头注意力最强），超长结果摘要处理，技术错误翻译为业务语义。
Reflexion 是最重要的自我反思框架，它不更新参数，而是把反思写进上下文。 Shinn 等人 2023 年的研究：Agent 执行失败后，生成语言形式的反思（"我因为 X 失败了，下次要注意 Y"），存入"经验记忆"，下次尝试时作为上下文注入。不同于强化学习，Reflexion 在推理时就能起效。实验数据：在 HumanEval 编程任务上，Reflexion 将 GPT-4 的 pass@1 从 67.0% 提升到 91.0%。
多智能体系统
主从式是最常见的多 Agent 架构：协调者负责任务分解，子 Agent 专注执行。 协调者（Orchestrator）将复杂任务拆解后分发给具备不同工具集的子 Agent——搜索 Agent、代码 Agent、数据库 Agent——收集结果后整合汇报。这是 LangGraph、CrewAI、AutoGen 的默认架构，也是工业部署中最成熟的模式。
MCP（Model Context Protocol）是 Agent 工具集成的新标准。 Anthropic 2024 年 11 月发布的开放协议，定义了 Client（Agent）与 Server（工具提供者）之间的通信方式，提供三类原语：Tools（可调用的函数）、Resources（可读取的数据源）、Prompts（可复用的提示模板）。MCP 之前，每个 Agent 框架都有私有的工具集成方式；MCP 让工具可以跨框架复用，数月内第三方 MCP Server 超过 1000 个，成为事实标准。
多 Agent 系统的协调挑战不亚于分布式系统。 各 Agent 维护独立状态，需要共享状态存储（Redis、数据库）+ 消息广播保持一致；全链路追踪每个 Agent 的行动才能定位失败点；Agent 间循环等待需要超时机制和依赖图分析；成本是单 Agent 的 N 到 N² 倍，应优先用工具调用而非子 Agent。权限边界上，Anthropic 的建议是：子 Agent 的权限应小于等于协调者的权限，防止权限提升攻击。
可靠性与失败模式
错误传播（Error Cascading）是长链 Agent 失败的最常见模式。 早期步骤的错误被后续步骤当作事实接受，形成错误雪球。AgentBench（2023）的数据：每增加一个工具调用步骤，任务完成率大约下降 5-10%，10 步任务的完成率通常低于 50%。τ-Bench（2024）的数据更严峻：即使单次任务成功率 80%，在 50 次连续任务中全部成功的概率为 0.8^50 ≈ 0.001%。这对需要批量自动化的工业部署是核心挑战。
提示注入是多工具 Agent 的重要安全风险。 工具返回的内容（网页、文档、数据库条目）中可能嵌入恶意指令，劫持 Agent 行为。与直接对话中的提示注入不同，工具结果注入更难防御，因为模型被训练为"信任"工具返回的内容。
长程任务（20+ 步骤）的可靠性需要工程补偿，而不只是更强的模型。 层级任务分解——把大任务拆成每层 3-5 个子任务，子任务完成后只传摘要而非完整过程；检查点机制——定期序列化任务状态，支持从中断处恢复；显式持久化中间结果到外部存储，而不是依赖上下文隐式记忆；在关键决策点插入人工确认。这些工程补偿可以将长链任务完成率从理论的 36% 提升到可接受的水平。
典型产品的演进路径
从代码补全到自主 Agent，这条路径有几个清晰的节点，每个代表性产品在架构选择上都有不同的取舍。
Codex 确立了"代码是 LLM 一等公民"的认知。 OpenAI 2021 年发布的 Codex 是在 GPT-3 基础上针对代码专门训练的模型，驱动了 GitHub Copilot——第一个大规模商业化 AI 编程产品。Copilot 建立的范式是：IDE 内嵌、行级补全、单函数生成，模型是被动的建议者，人决定每一行代码的取舍。这个范式的局限也很明显：模型没有代码库的全局视图，每次生成都是无状态的单次推理，无法跨文件理解依赖关系。
Claude Code 代表了从"辅助编码"到"自主编程 Agent"的跨越。 Anthropic 把模型放进真实的开发环境：终端、文件系统、Git、测试运行器。模型可以读整个代码库、修改多个文件、运行命令、看报错、迭代结果，直到任务完成。这不是更好的补全，而是范式的切换——模型从建议者变成了执行者，人负责审查结果而不是审查每一行代码。SWE-Bench 数据显示这条路线的有效性：2024 年初最好的系统解决了约 12% 的真实 GitHub Issue，到年底最优系统提升到 40%+。
OpenClaw 走的是"本地优先的通用个人 Agent"路线。 与 Claude Code 专注于编程环境不同，OpenClaw 是运行在本地机器上的开源通用 AI 助手，通过 WhatsApp、Telegram、iMessage 等消息渠道接入，具备持久记忆、浏览器控制、文件读写和 Shell 执行能力，还能自主构建新技能扩展自身。它代表了另一个方向的探索：Agent 不应该局限于特定工作区，而应该成为跨应用、跨场景的个人基础设施，且数据和计算都留在用户自己的硬件上。
Hermes Agent 是开源社区在模型层的对应路径。 Nous Research 的 Hermes Agent 基于 Hermes 模型系列构建，而 Hermes 是在 Llama 基础模型上专门优化 function calling 和 agent 能力的开源模型。它解决的问题是：让开源社区不依赖闭源 API 就能构建能力相近的 Agent 系统。Hermes 的意义不只是"更便宜的替代品"，而是验证了 Agent 能力可以通过专门的对齐训练从开源模型中释放出来——降低了整个生态的准入门槛，也推动了闭源产品持续提升能力上限。
四条路线的关键差异不在于技术，而在于对"Agent 应该是什么"的判断。
行动空间：IDE 补全 → 终端+代码库 → 消息+浏览器+系统
运行位置：云端 API → 终端 CLI → 本地机器
开放程度：闭源 → 闭源 → 开源
专注方向：代码补全 → 编程任务 → 通用任务
模型依赖：OpenAI → Anthropic → 开源 Hermes
共同面对的架构挑战相同：上下文管理、工具调用可靠性、长链任务的错误传播、记忆持久化。差异在于谁负责基础设施、数据在哪里、适用哪类任务。这四类产品并不是竞争关系，而是在不同约束条件下（隐私、成本、专业度、开放性）对同一类问题给出的不同答案。
当前进展与边界
代码 Agent 是目前可靠性最高的 Agent 形态，因为代码有客观的验证标准。 SWE-Bench 数据：2024 年初最好的系统仅能解决约 12% 的真实 GitHub Issue；到 2024 年底，最优系统提升到 40%+。代码可以被执行、测试结果可以被验证，这使得代码 Agent 可以通过"运行→看报错→修改"的循环自我纠错，这是在开放域任务中难以复制的优势。
Computer Use 把 Agent 的行动空间从 API 扩展到了任意图形界面。 Anthropic 2024 年发布的能力让 Claude 可以截图→理解界面→操作鼠标键盘，无需工具 API 即可使用任何软件。当前局限：每步需要截图→推理→执行，速度慢、成本高，且容易被 UI 变化干扰。但这代表了一个重要方向：降低工具集成门槛，让 Agent 可以像人一样使用软件。
Agent 能力的边界在于：任务结构是否清晰、错误是否可检测、状态是否可验证。 结构清晰（代码、数学）+ 错误可检测（运行即知）+ 状态可验证（输出有标准答案）的任务，是当前 Agent 最可靠的适用区。结构模糊（开放域决策）+ 错误难检测（输出好坏主观）+ 状态难验证（无明确完成标准）的任务，Agent 的自主性需要更保守，人工干预点需要更密集。