AI Agent：一个循环、五个部件，和工程上真正难的地方

资料截至 2026-10

一、先分清：workflow 和 agent 不是一回事

业界引用最多的那篇 agent 设计文章（Anthropic 的《Building effective agents》）给了一个很实用的区分：

• workflow（编排）：LLM 和工具按预先写死的代码路径协作
• agent（智能体）：由 LLM 自己动态决定流程和工具用法

先看 workflow 够不够——它更可控也更便宜。Anthropic 归纳了五种常见模式：

模式	做什么
Prompt chaining（提示链）	任务拆成固定顺序的几步，用延迟换准确率
Routing（路由）	先分类再送到专门的处理链，简单请求可以丢给便宜模型
Parallelization（并行）	分片（各干各的）或投票（同一任务跑多次）
Orchestrator-workers（编排-工人）	中心模型动态拆任务给子模型，再汇总
Evaluator-optimizer（评估-优化）	一个生成、一个挑刺，循环迭代

只有当步骤本身无法预先确定时才需要 agent。Anthropic 的忠告是：从最简单的方案开始，复杂度只在确实有用时才加——因为 agent 更贵，而且错误会沿着循环累积。

二、最小循环：想—做—看

agent 的本质就是一个循环。2022 年的 ReAct（2210.03629，ICLR 2023）把它讲清楚了：让模型交替地推理和行动。

观察 → 思考下一步 → 调用工具 → 观察结果 → 思考……

为什么这个循环有用：让模型单独”想”，它会编；让它单独”做”，它不会规划。把两者交错在同一段上下文里，模型就能用真实的工具反馈纠正自己。今天各种 agent 框架不管包装成什么样，内核都是这个循环。

三、五个部件

1. 模型（大脑）：关键是”会不会调工具”

不是所有模型都能当 agent 的大脑，function calling 是硬门槛：模型要能输出结构化的调用请求，而不是在自然语言里夹一句”你可以去查查天气”。

如果模型是自己部署的，这一步要显式打开。以 vLLM 为例：除了 --enable-auto-tool-choice，还得用 --tool-call-parser 指定解析器——因为各家的工具调用格式不一样。它的解析器清单本身就说明问题：hermes（Qwen2.5 系）、llama3_json、mistral、deepseek_v3、glm45、kimi_k2、qwen3_xml……几十个。还要配合 --chat-template。想更严格可以给工具加 strict: true，或用 --tool-strict-level 统一提高要求。

vllm serve meta-llama/Llama-3.1-8B-Instruct \
    --enable-auto-tool-choice \
    --tool-call-parser llama3_json \
    --chat-template examples/tool_chat_template_llama3.1_json.jinja

工具调用的思路最早可以追溯到 Toolformer（2302.04761，NeurIPS 2023）：让模型自己学会什么时候该调 API。

2. 工具：从自己写，到 MCP

最早的工具是硬编码的：想让 agent 查天气，就写个 get_weather 塞进 tools 列表。问题是每接一个新系统（GitHub、数据库、日历）都要重写，换个框架还得再来一遍。

MCP（Model Context Protocol）就是来标准化这件事的。官方定义是”连接 AI 应用与外部系统的开源标准”，比喻是 AI 应用的 USB-C 口：工具方只要写一次 MCP server，所有支持 MCP 的客户端（Claude、ChatGPT、VS Code、Cursor 等）都能直接用。当前规范版本是 2026-07-28。

记住它的边界：MCP 管”能调用什么”，不管”什么时候调用”——后者仍然由模型或你的代码决定。

3. 记忆与上下文

agent 的记忆分两层：

• 上下文内：本次任务的过程、工具返回值、失败原因都堆在上下文里。上下文会爆，所以工程上大量精力花在压缩、摘要、按需检索上（这也是 context engineering 这个词的来源）
• 跨会话：把经验沉淀到外部存储（文件、向量库、笔记），下次任务再读回来

4. 规划与控制

• 规划：Tree of Thoughts（2305.10601，NeurIPS 2023）让模型同时展开多条推理路径再挑；更朴素的做法是先出计划再执行
• 反思：Reflexion（2303.11366，NeurIPS 2023）让 agent 失败后写一段复盘，带着复盘重试——不用改模型权重
• 控制：最难的是什么时候停。必须有步数上限、时限、重复动作检测，否则 agent 会原地打转烧钱

5. 环境与反馈

agent 要能安全地动手：沙箱、权限、可回滚。评测上几个公认基准是 SWE-bench（2310.06770，ICLR 2024）测真实 GitHub issue 修复、AgentBench（2308.03688，ICLR 2024）测多环境任务、GAIA（2311.12983）测通用助理类任务。

四、多智能体：什么时候值得

• AutoGen（2308.08155）：把多 agent 对话做成框架，让模型扮演不同角色互相讨论
• Generative Agents（2304.03442，UIST 2023）：那个”小镇模拟”，25 个 agent 各有记忆、会互相传播信息，证明了记忆加反思能让行为显得像人
• Voyager（2305.16291，TMLR 2023）：在 Minecraft 里让 agent 自己写技能、存进技能库并复用

多智能体不是默认选项。一个 agent 配好工具，通常比三个 agent 互相聊天更便宜也更可控；只有任务天然可切分（研究 + 编码 + 评审这种）才值得拆。

五、工程上真正难的地方

1. 成本与延迟：一次任务可能是几十次模型调用，token 和延迟都是单次问答的几十倍
2. 错误累积：每一步的小偏差会沿着循环放大（Anthropic 专门提醒了这点），所以需要检查点和回滚
3. 评测难：同一个任务可以有多种正确路径，跑一次成功不代表稳定——要多次运行看方差
4. 安全：agent 有权限就会出事——提示注入（网页里藏一句”忽略上面的指令”）、误删、越权调用。这也是 2026 年还在出《Safety in Self-Evolving Agents》《Trustworthy Agentic AI》这类综述的原因
5. computer use 另有一堆工程坑：截图分辨率、动作空间设计、延迟，2026-09 已有专门的《Efficient GUI Agents: A Systems Survey》（2609.02309）来系统讨论

六、别急着上框架

Anthropic 给的三条原则我很认同，顺序也重要：

1. 保持简单：很多模式用几十行代码就能实现，先用 LLM API 直接写
2. 透明优先：框架会把 prompt 和返回值藏起来，出问题很难查
3. 认真设计 agent-计算机接口：工具的名字、参数、返回值、错误信息怎么设计，和给人做 UI 一样值得投入——他们的说法是，投入 ACI 的精力应该和投入 HCI 的精力相当

这和我对 MCP 的看法一致：协议解决的是”复用”，不解决”什么时候用”。

七、怎么开始

最小路径跑起来：

1. 选一个支持 function calling 的模型（本地部署的话按第三节开参数）
2. 写 2~3 个工具（读文件、查网页、执行代码）
3. 手写那个循环（观察→思考→行动），务必加步数上限
4. 先跑一个能验证对错的任务，别一上来就自动化高风险操作

等被”手动循环”卡住了，再考虑上框架和 MCP server。

参考

• 2210.03629 — ReAct: Synergizing Reasoning and Acting in Language Models — ICLR 2023（CCF-A）
• 2302.04761 — Toolformer: Language Models Can Teach Themselves to Use Tools — NeurIPS 2023（CCF-A）
• 2303.11366 — Reflexion: Language Agents with Verbal Reinforcement Learning — NeurIPS 2023（CCF-A）
• 2304.03442 — Generative Agents: Interactive Simulacra of Human Behavior — UIST 2023（CCF-A）
• 2305.10601 — Tree of Thoughts: Deliberate Problem Solving with Large Language Models — NeurIPS 2023（CCF-A）
• 2305.16291 — Voyager: An Open-Ended Embodied Agent with Large Language Models — TMLR 2023
• 2308.03688 — AgentBench: Evaluating LLMs as Agents — ICLR 2024（CCF-A）
• 2308.08155 — AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation — 预印本
• 2310.06770 — SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — ICLR 2024（CCF-A）
• 2311.12983 — GAIA: a benchmark for General AI Assistants — 预印本
• 2609.02309 — Efficient GUI Agents: A Systems Survey of Observation, Action and Memory — 预印本
• 2610.00093 — Safety in Self-Evolving Agents: A Survey — 预印本