一句话：Agent 是一个由目标驱动的闭环：模型自主决策，通过工具作用于外部世界，并根据结果决定下一步，直到目标达成。 这个概念早于 LLM，LLM Agent 只是用大模型来当决策者。LLM 没有改变 Agent 的定义，变的是决策者有多通用。
1定义
1.1四个必要特性
按重要度 (区分 Agent 与非 Agent 的能力) 排序：
| # | 特性 | 含义 | 判别问句 | 反例 |
|---|---|---|---|---|
| 1 | 自主决策 | 路线由模型在运行时定：调哪个工具、调几次、先做什么 | 把模型换成固定脚本，执行路径会变吗？ | 固定管线、Prompt 串联、RAG |
| 2 | 闭环 | 每一步的结果回到模型，决定下一步怎么走：边做边看，不是把计划从头执行到尾 | 中间结果不同，后续路径会不同吗？ | 不看结果的重试循环；只决策一次的意图路由；执行完不回传结果的单次 function calling |
| 3 | 工具调用 | 通过工具感知 (读文件、搜索) 和改变 (写库、发消息) 外部世界 | 行动会改变它将来看到的东西吗？ | 多轮自我反思、纯推理链：「会想」但不「会做」 |
| 4 | 目标驱动 | 为目标运转，由模型判断目标是否达成、何时结束；代码只设兜底 (最大轮数 / 超时 / 预算) | 结束是因为「做完了」，还是「跑完了」？ | 固定步数的流水线、跑完即止的批处理 |
为什么这么排：
- 自主决策是分水岭。另外三条 Workflow 也可能有，但只要路线是代码定的，就不是 Agent。
- 闭环让自主决策有意义。只决策一次的叫 Router；没有自主决策的循环 (SGD、重试) 也不是 Agent。1 是核心，2 是载体，两者必须同时成立。
- 工具让闭环穿过外部世界。没有工具，闭环只在模型自己的推理里转，拿不到新信息，也改变不了什么。
- 目标驱动几乎自动满足。用户下达任务就等于给了目标。它在工程上真正的体现只有「由谁判定结束」，而这本身也是一种自主决策。
四个特性的分工：自主决策回答谁来定路线，闭环回答怎么推进，工具调用回答靠什么和外部世界打交道，目标驱动回答为什么而跑、何时停下。
和学术定义的对应 (Wooldridge & Jennings 1995；Franklin & Graesser《Is it an Agent, or just a Program？》1996)：自主性 → 自主决策；时间连续性 → 闭环；处境性 / 反应性 (感知 + 行动) → 工具调用；目标导向 / 主动性 → 目标驱动。
1.2两个判据
- 反向测试：即 1.1 的第一条判别问句。如果步骤和顺序在写代码时就定了，那就是 Workflow，不是 Agent。
- 意向立场 (Dennett)：当「把它当成有目标、会做选择的主体」来理解，比「把它当成一套机制」来理解更有用时，才值得叫它 Agent。恒温器、SGD 在形式上也能套进 Agent 的定义，但一行公式就能完整描述它们，Agent 这个标签提供不了任何新东西。
1.3Agent 与环境的边界
边界看的是绝对控制力的极限，而不是物理位置 (Sutton & Barto)。凡是 Agent 能随意改写的，都属于它的内部状态；凡是它改不了、可能「让它意外」的，才是环境。一个永远不会让你意外的对象，不需要感知。
2LLM Agent 的构成
2.1模型 ≠ Agent
模型 (权重) 是一个纯函数：f(tokens) → 下一个 token 的概率分布。它不执行任何东西。
模型只「说」要调哪个工具，Agent 代码负责「做」：
服务层 把工具定义 (名字/描述/参数 schema) 拼进 prompt
模型 生成一段约定格式的文本: <tool_call>{"name": ..., "arguments": ...}</tool_call>
服务层 把这段文本解析成结构化的 tool_calls 字段
Agent 校验 / 鉴权 / 人工确认 → 执行工具 → 把结果作为 tool 消息拼回对话 → 再调模型
直到模型某一轮不再要求调工具，判定结束
所谓模型「会调工具」，准确含义是：它被训练过，能在合适的时机按约定格式输出调用意图。这是文本生成能力，不是执行能力。所以决策是两层共同完成的：模型提议，Agent 代码裁决并执行。
2.2分层
应用 业务入口、UI、任务落库
Agent 轮次循环、执行工具、管理上下文、判定终止、权限护栏 ← OpenAI Agents SDK Runner
模型服务 chat template、注入工具定义、解析 tool_call、服务端工具 ← OpenAI / Claude API
推理引擎 逐 token 解码循环、KV cache、批处理 ← vLLM 等, 跑在 GPU 上
权重 f(tokens) → 下一 token 概率分布 ← 纯函数
Agent = 模型 (决策部件)+ 循环 + 工具执行 + 状态管理 + 终止判定。 单拿模型，它只是一次性调用的函数；放进这个闭环，整个系统才是 Agent。
2.3能用 vs 好用
第 1 节决定「是不是 Agent」，下面这些决定「能不能上线」：
- 工具设计：工具是写给模型看的接口。返回值要让模型看得懂，报错要能引导它自我纠正。
- 上下文工程：决定哪些信息常驻、哪些按需加载 (比如 skill 的渐进披露)，长任务要压缩或摘要。
- 状态持久化：任务落库，可中断、可恢复。
- 护栏：只读 / 可写的权限边界、最大轮数、成本预算，破坏性动作前先让人确认。
- 可观测：每一轮的工具调用和出入参都留 trace，能回放整条决策链。
- 评估：控制流不确定，单元测试覆盖不了，要靠用例集 + 结果判分做回归。
3Agent 的强弱
3.1强弱取决于决策难度
四个特性决定「是不是 Agent」，强弱则看它能在多难的决策问题上做出好决策。决策空间越小，比如只有几个选项，自主决策就越简单，用简单的方式也能实现，这是弱 Agent。决策空间越大，选项近乎无限，决策就越难，能决策好的是强 Agent。
但难度不只看选项多少。下棋每一步只有几十种合法走法，照样很难。决策难度有四个维度：
| 维度 | 简单 | 困难 |
|---|---|---|
| 宽度：每步有多少选项 | 3 个工具里挑一个 | 任意写代码、任意组合参数 |
| 深度：要连续决策多少步 | 2–3 步完成 | 几十上百步，前面错一步后面全偏 (误差累积) |
| 不确定性：环境反馈清不清楚 | 成功或失败一看便知 | 反馈含糊、延迟，甚至误导 |
| 目标开放度：目标定义得清不清楚 | 「查出这张卷的维度」 | 「帮客户设计一套 Java 岗的测评方案」 |
还有一点：选项多不等于难，关键是好选项有多稀少。 大部分选择都能接受的，空间再大也容易；只有极少数路径走得通的，空间小也难。
3.2两条路：模型智力 vs harness 设计
决策难度高时，要做出好决策，要么靠基座模型的智力，要么靠 harness (Agent 层代码) + 提示词的设计来补。harness 做两件事：
- 缩小有效决策空间 (对应宽度、深度)：只给少量语义清晰的工具，不给万能执行器；用 skill 或流程提示把长任务拆成几段，每段只决策几步；确定性的部分直接写成代码，只把真正需要判断的地方交给模型。
- 补足决策信息 (对应不确定性)：做好上下文工程；工具返回值和报错写清楚；拿不准时让它停下来问人，而不是硬猜。
很多时候模型决策不好，不是智力不够，而是信息不够。这种情况下补信息，往往比换更强的模型更有效。
3.3权衡：harness 越厚，上限越低
智力和结构可以互相替代，但结构有代价。harness 把空间收得越窄，弱模型越能做好，系统的上限也越低：遇到设计时没想到的情况就无路可走。收到极致，路线完全由代码决定，Agent 就退化成了 Workflow。
Workflow ── Router ── 弱 Agent ──────────────── 强 Agent
路线写死 选一次 小空间、浅深度、 大空间、长链路、
harness 约束重 harness 薄, 靠模型智力
按当前模型的能力决定 harness 的厚薄。 模型变强了，就该把 harness 拆薄，把决策权还给模型。否则当初为弱模型搭的结构，反而会限制强模型。
4误区：这些不是 Agent
| 案例 | 为什么不是 | 实质 |
|---|---|---|
| 调了一次 LLM (提取、润色、分类、翻译) | 没有循环，没有行动 | LLM 调用 |
| 多个 Prompt 串起来 | 步骤和顺序写死在代码里 | Workflow(Prompt chain) |
| RAG：先检索再生成 | 固定两步，模型不决定要不要检索、检索几次 | Workflow |
| LLM 做意图分类，再走固定分支 | 模型只做一次选择，后面的路径是代码定的 | Workflow(Router) |
| 「提取 → 校验 → 入库」这类固定管线，每步都用 LLM | 用 LLM 的步骤再多，控制流也在代码手里 | Workflow |
| 大模型本身 | 权重是纯函数，不执行任何东西 | Agent 的决策部件 |
| 训练好的分类器 | 输入 → 输出，调用一次就结束 | 函数 |
| SGD 等优化算法 | 更新规则是固定公式，数据是静态的、不受它影响 | Agent 的学习部件 |
| 名字里带 Agent 的程序：User-Agent、监控 Agent、SNMP Agent | 这里的 Agent 是「代理」，替人转发，不做自主决策 | 代理程序 |
| 用了 Agent 框架 | 框架不决定性质，要看控制流在谁手里 | 视实现而定 |
对照本仓库：flows/ 里用 Prompty 提取、润色题目，是 LLM 调用或 Workflow。david/agent/ 那套主 Agent 由模型自己挑 skill、循环推进，才是 Agent。
灰色地带：主动学习、贝叶斯优化这类「自己决定下一步去哪探」的算法，只算弱 Agent。推荐系统、多臂老虎机、强化学习 (推什么会决定用户点什么，点击数据又回来影响决策) 是真正的 Agent。区别在于：系统的输出会不会改变它将来看到的世界。
5多 Agent 与子 Agent
5.1多 Agent
多个各自满足第 1 节定义的 Agent，每个都有自己的循环、上下文和目标，彼此通过消息协作。这个思路可以追溯到 Hewitt 的 Actor 模型 (1973)：状态封装、异步消息、各自决定怎么响应。
常见的组织方式：
| 模式 | 结构 | 控制权 |
|---|---|---|
| 编排者-执行者 (Orchestrator–Workers) | 一个主 Agent 拆任务、派活、汇总结果 | 始终在主 Agent |
| 转交 (Handoff) | A 判断该由 B 处理，就把对话整个交给 B (OpenAI Agents SDK 的 handoffs) | 随转交转移，不回到 A |
| 对等协作 / 辩论 | 多个 Agent 轮流发言、互评、投票 | 分散，需要外部规则来收敛 |
误区：如果谁先跑、谁后跑、结果怎么合并都是代码写死的，那只是多个 LLM 步骤组成的 Workflow，不是多 Agent。判据和单 Agent 一样，看控制流在谁手里。
5.2子 Agent
子 Agent 是多 Agent 里最常用的一种形态：父 Agent 把一个子 Agent 当成工具来调用。子 Agent 在自己独立的上下文里跑完整个循环，最后只把结论返回给父 Agent。
| 对比 | 工具 | 子 Agent | Skill |
|---|---|---|---|
| 内部有没有决策循环 | 没有，是确定的函数 | 有，独立循环 | 没有，是注入给当前 Agent 的说明书 |
| 上下文 | 共享父 Agent 的 | 独立 | 共享当前 Agent 的 |
| 返回 | 执行结果 | 结论或摘要 | 不返回，指导当前 Agent 怎么做 |
为什么要拆出子 Agent：
- 上下文隔离 (最主要的理由)：读几十个文件、跑大量搜索这种过程会产生大量中间信息，全放在子 Agent 里，父 Agent 只收到结论，主上下文不会被撑爆。
- 并行：彼此独立的子任务可以同时跑。
- 专精：子 Agent 有自己的 system prompt 和工具集，只做一类事。
- 权限收窄：比如只读的检索子 Agent，不给它写权限。
代价：每个子 Agent 都要重新建立上下文，token 成本成倍增加；父子之间只靠一段摘要传递信息，细节会丢。能在一个 Agent 里做完的，就别拆。
6选型
能用 Workflow 解决的，就别上 Agent；能用单 Agent 解决的，就别上多 Agent。
Agent 换来的是灵活性，代价是不确定性、成本和调试难度。适合交给 Agent 的场景是：步骤数事先不可知、路径依赖中间结果、需要试错，比如需求澄清、「检索后不满意就改条件重搜」。路径固定的管线，写成 Workflow 更稳。
确定要上 Agent 后，按第 3 节的思路，根据任务的决策难度和模型能力来决定 harness 的厚薄。
7附：简史
| 年代 | 事件 | 贡献 |
|---|---|---|
| 1950s | McCarthy 提出、Selfridge 命名「Agent」：一个「软机器人」，给它目标就能自己办细节，卡住时用人话求助 | 愿景：目标委托 + 自然语言 + 人在回路 |
| 1966–72 | Shakey 机器人 + STRIPS 规划器 | 机制：感知-规划-行动闭环 |
| 1973 | Hewitt Actor 模型 | 结构：封装、消息、自主响应 |
| 1980s | 合同网协议、Minsky《心智社会》 | 多 Agent 协作 |
| 1990s | BDI 模型、面向 Agent 编程、Wooldridge & Jennings 四特性、FIPA 标准 | 概念定型 |
| 1990s–2010s | 游戏 NPC (行为树、GOAP)、强化学习 (TD-Gammon、DQN、AlphaGo) | 决策者从规则演进到学习出来的策略 |
| 2020s | LLM Agent | 决策者第一次足够通用，工具接口从「形式化建模」降成「写说明书」 |
McCarthy 当年提出的愿景，和今天的 LLM Agent 几乎一一对应。过去做不到，是卡在知识瓶颈上：世界模型要人手写，一出封闭环境就失效。大模型补上的就是这一块。