第 1 章：Agent 到底是什么，不是什么
本章目标：先清理概念污染，建立后续全书都要使用的最小判断标准。
本章对应总纲：docs/ebook-outline.md中“第 1 章正文写作提纲（2026-03-31 归档）”。
1.1 为什么“Agent”这个词被用滥了
这几年，“Agent”几乎成了 AI 圈最廉价的标签。只要一个系统接了大模型、能调用几个工具、再加一点自动执行逻辑，很多人就会立刻把它叫成 Agent。这个问题不是术语洁癖，而是工程判断会因此失真。
如果你连对象是什么都没定义清楚，后面谈架构、谈边界、谈能力，都会飘。把一个问答系统误当成 Agent，你会高估它的自主性；把一个固定工作流误当成 Agent，你会低估任务动态决策的重要性；把一个真正的 Agent 仅仅当成“更强的聊天机器人”，你就会错过它最关键的系统设计问题：状态、反馈、边界和执行闭环。
所以这一章的任务，不是给 Agent 贴金，也不是去唱反调，而是做一件更朴素的事：把概念边界拉清楚。只有这样，后面每一章讨论的东西才不会混成一锅粥。
常见的误称大概有三类：
- 把带工具调用的问答系统叫做 Agent
这类系统能查资料、能执行几个动作，但本质上还是“问一次，答一次”，缺乏持续推进目标的能力。 - 把固定流程自动化叫做 Agent
例如把一串预先写死的步骤包装起来，前面加个自然语言入口，就自称是智能体。其实那更像 workflow，不是 Agent。 - 把任何接了大模型的产品都叫 Agent
这就更懒了。模型只是部件，不是系统定义。
真正该问的问题只有一个：
这个系统是不是在围绕一个目标，持续感知环境、做决策、采取行动、接收反馈，并根据反馈继续推进？
如果不是，那大概率还谈不上 Agent。
1.2 一个可工作的 Agent 定义应该包含什么
工程上没必要追求哲学上最完美的定义。我们只需要一个足够清楚、能指导系统设计、也能用来判断真假的定义。
本书采用一个非常务实的定义：
Agent 是一个围绕目标运行的系统。它能够根据当前环境与已有状态做决策，必要时调用外部能力采取行动，并根据行动结果继续调整后续行为，直到任务完成、失败或被中止。
这个定义里有五个关键点。
1.2.1 目标
Agent 不是为了“持续输出文本”而存在，而是为了推进某个目标。目标可以很小，比如“提交一个 commit”；也可以很大，比如“完成一次功能开发并通过测试”。
没有目标，系统就只是对话；有目标，系统才开始出现“下一步该做什么”的问题。
1.2.2 环境
Agent 不是在真空里工作。它总是在某个环境中运行：文件系统、代码仓库、命令行、浏览器、Issue/PR、外部 API、甚至人的反馈，都是环境的一部分。
环境决定了它能看见什么，也决定了它能影响什么。
1.2.3 动作
Agent 不只是“回答”，它还会采取动作。动作可能是：
- 读取文件
- 搜索代码
- 执行命令
- 发起网络请求
- 调用其他 Agent
- 请求人类确认
如果一个系统只能生成建议而不能真正推动任务前进，它的行动能力就仍然是弱的。
1.2.4 反馈
动作之后必须有反馈。否则系统不知道自己刚才做得对不对，也不知道是否要继续、修正还是停止。
反馈可能来自：
- 工具执行结果
- 编译/测试报错
- 用户回复
- 外部系统状态变化
没有反馈，所谓 Agent 只是在盲跑。
1.2.5 循环
最关键的是循环。Agent 不是一次推理，而是一轮又一轮的：
理解当前状态 -> 判断下一步 -> 采取动作 -> 读取反馈 -> 再判断
这就是它和普通问答系统最本质的区别。
1.3 Agent、Chatbot、Copilot、Workflow 的边界
说概念最好的办法，不是单独定义，而是拿相邻概念来切边界。
| 类型 | 核心目标 | 是否能行动 | 是否围绕目标持续推进 | 主要特点 |
|---|---|---|---|---|
| Chatbot | 回答问题 | 通常不能或很弱 | 通常不持续 | 以对话为中心 |
| Copilot | 辅助人完成局部任务 | 有限 | 弱 | 以建议和补全为中心 |
| Workflow | 执行预定义流程 | 能 | 能，但通常不动态 | 以固定步骤为中心 |
| Agent | 围绕目标持续推进任务 | 能 | 能，而且会根据反馈调整 | 以闭环决策为中心 |
1.3.1 Chatbot
Chatbot 的本质是对话系统。它擅长回答、解释、总结、改写，但通常不真正承担任务推进责任。你问，它答；你再问，它再答。它可以很聪明，但依然只是问答型系统。
1.3.2 Copilot
Copilot 比 Chatbot 更进一步。它通常嵌在某个工作环境里，比如编辑器，能根据上下文给你建议、补代码、补命令、补下一步操作。但它的重心依然是辅助人，而不是替人完整承担任务。
1.3.3 Workflow
Workflow 解决的是自动化问题。它把一串步骤预先定义好，然后按顺序执行。它很有用，但它并不天然具备动态决策能力。只要路径一变，它就容易卡住，或者需要大量额外分支逻辑。
1.3.4 Agent
Agent 的不同之处在于：它不只是按脚本跑，也不只是给建议，而是能在执行过程中根据环境和反馈不断调整路径。它是围绕目标推进，而不是围绕固定步骤执行。
这并不意味着 Agent 一定比 Workflow 更高级。很多场景下，Workflow 更可靠、更便宜、更容易维护。真正的判断标准不是“哪个听起来更高级”，而是：
- 任务是否需要动态决策？
- 环境是否经常变化？
- 中途是否需要根据反馈改变路径？
如果答案都是“否”，那 Agent 可能根本不是必要方案。
1.4 Agent 的真正分水岭：行动闭环
现在可以把最重要的一句话说出来了：
Agent 的本质，不是更会说，而是能形成行动闭环。
这个闭环至少包含四步：
- 感知：读取当前状态与环境
- 决策：判断下一步最合适的动作
- 行动：调用能力改变外部世界或推进任务
- 反馈：读取行动结果，并把结果变成下一轮决策输入
这四步连起来，系统才真正具备“推进任务”的能力。
为了看得更直白，我们拿一个简单例子对比。
普通问答系统
用户说：
请帮我修复这个 TypeScript 报错。
普通问答系统可能会回答：
- 这类错误通常是因为类型不匹配
- 你可以检查一下参数类型
- 试着加一个类型断言
这不是没用，但它仍然只是建议。
Agent 系统
同样一句话，一个 Agent 会做的事情可能是：
- 先读取报错位置
- 跳转类型定义
- 查看相关调用链
- 修改代码
- 运行类型检查
- 如果还有错，再继续修
- 没错了才停
这就是闭环。它不是“更长的回答”，而是“更完整的系统行为”。
这也是为什么很多人会误判系统能力：他们看见模型输出很像“会做事”，就以为它已经是 Agent。其实不对。真正的分水岭不在文风，不在提示词，不在能不能说出计划，而在于它有没有把行动和反馈纳入同一个持续运行的结构里。
1.5 用 Claude Code 看一个现实中的 Agent 样本
如果只讲抽象，很容易漂。这里用当前仓库里一个现实例子，把前面的定义落到地上。
plugins/README.md:6 先把 Claude Code 插件系统说得很直接：插件可以通过 custom commands、specialized agents、hooks、MCP servers 扩展系统能力。这个表述本身就在说明一件事：这里讨论的不是“一个更会聊天的模型”，而是一个由入口、执行角色、生命周期挂点和外部能力接口共同组成的系统。
再往下看 plugins/README.md:48 的标准插件结构：
commands/agents/skills/hooks/.mcp.json
这套拆法很关键。它说明当前项目在设计上已经默认接受一个事实：Agent 不是单点能力，而是要靠多层结构把目标、动作、约束和外部能力焊起来。 如果系统本质只是问答器，根本没必要长出这么清楚的分层。
再看 plugins/README.md:16 和 plugins/README.md:19，仓库里的 code-review、feature-dev、pr-review-toolkit 都不是“回答一下怎么做”，而是把审查、分析、架构设计、质量检查拆成多个执行角色。这进一步说明现实里的 Agent 关注的不是文本生成本身，而是任务如何被持续推进、分解和收敛。
首页 index.md:23 也把这个项目的学习价值说得很明：每一章都对应真实代码，每一个设计决策都能在源码里找到答案。这里真正值得学的不是“agentic”这个词，而是背后的几条设计思路：
- 能持续推进任务的系统，才值得叫 Agent，不是接了模型就算
- 动作能力要显式挂在结构里，不要把“会做事”藏在宣传语里
- 入口、执行、约束、扩展要分层，否则系统很快就会概念混乱
- Agent 必然是混合系统，会和命令、Hook、工作流、权限控制缠在一起，不存在真空里的“纯 Agent 产品”
所以拿 Claude Code 当样本，最大的收获不是学到一个定义句，而是看清：一个现实 Agent 系统从第一天起就不是“模型 + 提示词”，而是“目标推进 + 动作接口 + 反馈回路 + 边界治理”这整套东西一起成立。
再往后看你还会发现：当一个系统把入口、执行角色、生命周期挂点和外部能力接口拆得越来越清楚时，它讨论的就不再只是“是不是 Agent”，而会自然走向平台化与扩展面设计。这也是为什么后面几章会继续把 Claude Code 当成结构样本，而不只是概念例子。
1.6 本章小结
这一章做的事情很简单，但非常关键：先把“Agent”这个词从噪音里救出来。
你现在应该记住四件事：
- Agent 不是一个营销标签，而是一类围绕目标运行的系统。
- 它和 Chatbot、Copilot、Workflow 有边界重叠，但不相同。
- 真正的分水岭不是更会说，而是有没有行动闭环。
- 理解 Agent，必须从系统视角看，而不是只盯模型输出。
下一章我们不再停留在概念层，而是把 Agent 拆成最小组成单元：模型、工具、记忆、规划、执行循环。到那时，你会更清楚地看到，为什么“只有一个强模型”永远不等于“已经有了一个完整 Agent 系统”。