什么是 AI Agents？
2024 年底，Anthropic 发布了《Building effective agents》[1]一文，系统地讲述了如何构建基于 LLM 的 agent 应用。本文是我读这篇文章的笔记。
“Agent”一词有多种用法：有些人把它理解为能长时间独立运行、自己用各种工具完成复杂任务的完全自主系统，另一些人则用它指沿着预先定义好的流程执行的实现。
Anthropic 不去争论哪种才算“真正的 agent”，而是把这些变体统称为 agentic system（智能体系统），再在内部划一条架构上的界线：
- 工作流（workflow）：LLM 和工具通过预先定义的代码路径编排。
- Agent：LLM 动态指挥自己的流程和工具使用，掌控任务如何完成。
我的理解：agentic system、workflow 与 agent
理解了这条界线，再回头看日常语境，就容易分辨了。
我们日常熟悉的 agent，通常是“自己想办法把事办成的 AI”，比如 Claude Code 会自己读代码、改文件、跑测试，并根据报错继续修复。这类系统下一步做什么由模型决定，属于狭义的 agent。
相反，在 Coze、Dify 这类平台上拖拽搭出来的“智能体”，往往是固定的节点流程加上几次 LLM 调用。按 Anthropic 的标准，它们属于 workflow。但无论是 workflow 还是 agent，都归入 agentic system 这个大类。
因此，判断一个系统是 workflow 还是狭义的 agent，关键看控制权在谁手里：步骤由代码决定的是 workflow，由模型决定的是 agent。两者对比如下：
| 对比项 | Workflow | Agent |
|---|---|---|
| 谁决定步骤 | 你的代码 | 模型 |
| 路径 | 固定，可预测 | 灵活，不确定 |
| 类比 | 你说怎么干就怎么干的员工 | 能自己想办法解决问题的员工 |
什么时候该用 agentic system
分清了这几个概念，接下来的问题是：实际做项目时，真的需要用它们吗？文章的策略可以总结为一句话：先找最简单的方案，需要时再逐步升级。
Anthropic 建议，用 LLM 做应用时先找最简单的解决办法，只有确实需要时才增加复杂度，甚至可能根本不需要做 agentic system。原因是 agentic system 通常要拿延迟和成本去换更好的任务表现，所以要先想清楚这笔交换划不划算。
如果确实需要更复杂的方案，可以这样选择：
- 任务定义清楚、需要可预测性和一致性时，用 workflow
- 需要灵活性、需要模型在大规模场景下自己做决策时，才用 agent
- 但对很多应用来说，把单次 LLM 调用优化好（加检索、加上下文示例）通常就够了
我的理解：升级阶梯
把上面的策略落到具体项目中，可以设置一个升级阶梯：从最简单的层级开始，只有当前层级无法满足需求时，才升到下一级。当然，复杂的项目可能各个层级都会用到。
| 层级 | 做法 | 适用情况 |
|---|---|---|
| 1 | 单次 LLM 调用 + 检索 + 示例 | 大多数应用到这里就够了 |
| 2 | Workflow（固定的多步编排） | 任务明确，要稳定、可预测 |
| 3 | Agent（模型自己决定步骤） | 步骤无法预先确定，需要灵活应对 |
怎么搭建 agentic system
确定了该用哪个层级，接下来就是动手实现。Anthropic 在文中也讲了何时、怎么使用框架。
起步阶段可供选择的框架包括：Claude Agent SDK、Strands Agents SDK（AWS）、Rivet 和 Vellum。前两个是写代码用的 SDK，后两个是可视化工具。
框架的好处是上手快：它帮你调用 LLM、定义和解析工具、把多次调用串联起来。但它也有代价：通常会增加抽象层，遮住真实的提示词和模型返回，让调试变得困难，还容易诱使人在简单方案就够用时增加复杂度。
所以 Anthropic 建议：先直接用 LLM API，很多模式几行代码就能实现；如果用框架，一定要搞懂底层代码，因为对底层的错误假设是常见的出错来源。
常见的设计模式
无论是否使用框架，搭建时都会用到一些常见的设计模式。文章一共提出了 5 种 workflow 模式和 1 种 agent，它们都建立在同一个基础构件之上，所以先从这个构件讲起。
基础构件：增强型 LLM
增强型 LLM 是 agentic system 最基本的构件，指的是被检索（retrieval）、工具（tools）和记忆（memory）增强过的 LLM。现在的模型能主动使用这些能力：自己生成搜索查询，自己挑选合适的工具，自己决定保留哪些信息。
图中三条双向虚线表示来回的交互：
| 能力 | 交互方式 | 作用 |
|---|---|---|
| 检索 | Query / Results | 从外部资料中查信息 |
| 工具 | Call / Response | 调用外部功能，如搜索、计算、读写文件 |
| 记忆 | Read / Write | 保存和读取需要留存的信息 |
实现这些增强能力时，Anthropic 建议抓住两点：一是按具体用例定制，二是给 LLM 提供简单、文档齐全的接口。其中一种做法是使用 Model Context Protocol（MCP）[2]，通过一个简单的客户端接入不断增长的第三方工具生态。
需要注意的是，文章后面的所有模式，都默认每一次 LLM 调用已经具备这些能力。换句话说，下面每个模式里出现的“LLM”，其实都是一个增强型 LLM。
5 种 workflow 模式
在增强型 LLM 之上，把多次调用按预先定义的代码路径组织起来，就得到了 workflow。文章介绍了 5 种：
| 模式 | 一句话理解 |
|---|---|
| Prompt chaining（提示链） | 把任务拆成固定的先后步骤，上一步的输出是下一步的输入 |
| Routing（路由） | 先给输入分类，再分流到不同的专门流程 |
| Parallelization（并行化） | 多个 LLM 同时处理再汇总，包括分段（Sectioning）和投票（Voting）两种变体 |
| Orchestrator-workers（编排者与执行者） | 中心 LLM 动态拆分任务，分给多个执行者，再整合结果 |
| Evaluator-optimizer（评估与优化） | 一个 LLM 生成，另一个评估并反馈，循环改进 |
Agent
与上面 5 种不同，agent 不再依赖预先定义的流程：模型自己规划、调用工具，并根据环境反馈循环推进，直到完成任务。它是整个体系里控制权最彻底地交给模型的一类。
小结
- 概念：agentic system 是总称，包含 workflow 和 agent 两类。区分标准只有一条：下一步做什么，是代码决定的，还是模型自己决定的。
- 选型：先找最简单的方案，需要时再逐步升级。大多数应用，单次 LLM 调用加检索和示例就够了；任务明确、要求稳定时用 workflow；步骤无法预先确定时才用 agent。
- 实现：先直接用 LLM API，搞懂底层后再考虑框架，避免被抽象层遮住提示词和模型返回。
- 基础与模式：所有模式都建立在增强型 LLM（检索 + 工具 + 记忆）之上，在此基础上有 5 种 workflow 模式和 agent。
整篇文章的核心态度可以概括为：克制地使用复杂度。agent 不是越多越好，而是在简单方案确实不够时的选择。
下一步
了解完概念和模式，接下来该动手实践了：
- 手写第一个最小 agent 循环
- 给它加 2～3 个工具，并打印每一步日志
- 逐个深入 5 种 workflow 模式，每种写一个小例子
参考文献
[1] Erik Schluntz, Barry Zhang. Building effective agents. Anthropic, 2024. https://www.anthropic.com/research/building-effective-agents
[2] Anthropic. Model Context Protocol. https://modelcontextprotocol.io
文中提到的框架与工具（出处同 [1]）：Claude Agent SDK、Strands Agents SDK（AWS）、Rivet、Vellum。