1.5 常见误区：Agent 不是「更长的提示词」
一句话结论：模型从来不会「执行」任何东西——它只会输出一段结构化文字，真正动手的是你的框架代码。理解这一点，能一次性拆掉关于 Agent 的一大半误解。
读这篇之前
这一篇是第 1 章的总复盘，建议先读完 1.1–1.4。在这里我们集中处理那些在讨论中反复出现、并且会直接导致技术选型错误的误解。
一、先破除最根本的一个误解
模型不会真的执行代码。
这句话值得反复强调，因为它是几乎所有 Agent 误解的源头。
模型做的只有一件事：输出一段结构化文字（通常叫 tool_calls）。真正解析这段文字、去调 API、去读文件的，是你写的框架代码。
所谓「Agent 调了天气 API」，真实流程是这样的：[原文 4615]
① messages[0] · system
role: system，content: "你可以使用以下工具…"，tools: [get_weather, send_email]
② messages[1] · user
"北京明天天气怎么样？"
③ ← 第 1 次模型调用完成
④ messages[2] · assistant
content: null
tool_calls: [{ name: "get_weather", id: "call_abc123", arguments: {...} }]
← 模型到这里就停了，它没有执行任何东西
⑤ 你的代码：解析 tool_calls → 真的去调 get_weather → 拿到结果
⑥ messages[3] · tool
role: tool，tool_call_id: "call_abc123"，content: "{明天晴，28℃}"
⑦ ← 第 2 次模型调用，模型看着这条结果继续
看清这条链路，你就能理解两件事：
- 模型只是"提要求"，执行能力在你手里。 所以工具的安全性完全由你控制——这也是第 14 章「人在环」能成立的基础。
- 每次调用之间都是断开的。 模型没有"记忆"，它只是每次都被喂一整份消息列表。上下文是你拼好交给它的，不是它自己记住的。
二、八个常见误区，逐个拆掉
误区 1｜Agent 就是「更长的提示词」
错。 提示词再长，模型能看到的仍然只有上下文里的东西。Agent 的关键不在于"说得多"，而在于能通过工具把上下文之外的信息拿进来。
判据很简单：把工具全去掉，它还剩下什么？如果只剩"更长的一段文本生成"，那它从来就不是 Agent。
误区 2｜连续对话就是 Agent
错。 连续聊天只是历史消息越攒越多，模型始终没有"做"的能力，也没有"根据结果调整判断"的循环。[原文 538]
一个很实用的测试：看它有没有「根据行动结果改变判断」的能力。 聊了二十轮但从没执行过任何动作的系统，本质上是多轮对话；只调两次模型但两次中间真的读了文件的系统，反而更接近 Agent 的实质。
误区 3｜Agent 越自主越好
错，而且危险。 自主性是有代价的：不可预测、难调试、成本不可控。
生产系统里更可靠的往往是受约束的 Agent——在关键节点插入人工确认、把不可逆动作单独把关。这也是第 14 章「人在环（HITL）」的出发点。
误区 4｜用了 Agent 框架就算 Agent
错。 框架只是把循环、工具、上下文管理这些零件封装好了。如果流程里模型根本没在做判断（只是按固定顺序走），那你用的是 Workflow，套了层框架的皮。
判断方法还是 1.4 的那句：下一步由谁决定？
误区 5｜Agent 能解决模型幻觉
不能根治。 Agent 能通过工具获得真实信息，从而降低幻觉概率——但如果工具返回的内容本身有错，或者模型读错、总结错，幻觉照样发生。
Agent 改变的是"信息从哪来"，不是"模型一定说得对"。这是第 13 章「评估」存在的理由。
误区 6｜上下文越长，Agent 越聪明
错。 超过一定长度后，关键信息被淹没、注意力被稀释，表现反而下降。长上下文不是免费能力，而是要管理的资源。
所以真正的工程问题不是"能塞多少"，而是"该塞哪些"——这是第 5 章的主题。
误区 7｜让模型一次输出多个工具调用，就不用多轮了
部分正确，容易误解。 模型确实可以在一次回复里请求多个工具调用（并行执行），但结果回来之后仍然要再推理一次才能利用它们。
并行减少的是"决策轮次"，不是"结果回填后的推理"。所以成本不会因此降到零。
误区 8｜先做 Agent，不行再降级
顺序反了。 降级比升级难得多——一旦业务逻辑长在模型的自由决策上，想改成固定流程基本等于重写。
正确顺序是 1.4 那张复杂度阶梯：从单次调用开始，不够再加检索，再不够用 Workflow，最后才上 Agent。
三、把 Agent 与 Chatbot 的系统性差异摆在一起
前面拆的是零散误区，这一张表给出整体的对照，可以作为自查清单：[原文 297][原文 4615]
| 维度 | Chatbot | Agent |
|---|---|---|
| 输入 | 一次对话 | 一个目标 |
| 决策 | 单轮 prompt → 答 | 多轮规划 → 执行 → 反思 |
| 记忆 | 仅当前会话上下文 | 短期 + 长期 + 程序记忆 |
| 行动 | 纯文本输出 | 调用工具、改文件、发 API |
| 边界 | 用户每轮触发 | 自主循环到目标达成 |
| 工作链路 | 输入 → 输出 | 任务 → 规划 → 调工具 → 观察 → 纠错 → 完成 |
用一句话概括这条鸿沟：LLM 是会说话的模型，Agent 是会干活的助手。 同一句话，LLM 回答完就结束；Agent 会拆任务、调工具、看结果、错了再来，直到把事办成。[原文 4615]
还有一条贯穿全系列的主线，也在这里点明：
模型负责聪明，工程负责稳定。 [原文 4615]
Agent 的效果上限由模型决定，但它的可靠性、成本、安全性、可维护性几乎全部由工程决定。这也是为什么本系列后面七部，大部分篇幅都在讲工程而不是讲模型。
四、把一个误区放到实际项目里看后果
抽象讲误区没用，看一个具体项目会怎么被这些误区毁掉。
一个典型的失败项目
需求：给销售团队做一个"自动跟进潜在客户"的助手
做法：上 Agent 框架，配 15 个工具（查 CRM、发邮件、查日历、
查公司信息、写备注…），让它自主决定
三个月后的实际情况：
| 现象 | 对应哪个误区 |
|---|---|
| 每月 Token 账单从预估的 500 涨到 8000 | 误区3（越自主越好）、误区7（先做再降级） |
| 销售说"它有时候发两封一样的邮件" | 状态没外显（2.2）+ 无幂等（10.4） |
| 出了个错发给客户的事故，无法复现 | 误区2（连续对话≠Agent）、无轨迹 |
| 想改成固定流程，发现改不动 | 误区8（先做 Agent 再降级） |
| 老板问"这功能值多少钱"，答不出来 | 成本不可预测（1.4 六维度） |
五个现象全部落到第 1 章讲的误区上。
正确的做法应该是什么
第一步：Workflow 三步
① 查 CRM 拿潜在客户状态（代码）
② 判断是否该跟进（规则 + 一次模型调用分类）
③ 生成跟进邮件草稿（一次模型调用）
第二步：把"发送"做成人工确认
→ 草稿进待发队列，销售点确认
第三步：跑一个月，看数据
→ 如果规则判断准确率不够，才考虑在②里加自主查询
这个做法成本可预测、行为可复现、事故可避免。 而且第一步两周就能上。
"销售确认"这一步还有个额外好处：它顺便给了你训练数据——哪些草稿被改了，就是改进的依据（第 13 章）。
五、一份自查清单：你的项目有没有踩这些坑
| # | 自查项 | 踩了说明 |
|---|---|---|
| 1 | 我问过"为什么不能用 Workflow"吗？ | 可能过度设计 |
| 2 | 我能说出每次任务的平均轮数吗？ | 成本不可控 |
| 3 | 出问题时我能拿到完整轨迹吗？ | 不可维护 |
| 4 | 所有"写"的动作都有审批或幂等吗？ | 会重复执行 |
| 5 | 我的提示词里有没有"更长的提示词就能解决"的幻想？ | 没理解 Agent 本质 |
| 6 | 我能说清"这一步为什么让模型决定"吗？ | 可能在用错工具 |
| 7 | 有没有哪个环节"模型其实没做判断"？ | 那里该用代码 |
六、一个经常被忽略的判断：你到底在造什么
拆完误区，还剩一个更根本的问题值得问：你正在做的产品，用户是"每轮触发"还是"给个目标自己跑"？
这两者的工程重心完全不同：
- 每轮触发（Chatbot 形态）：重心在单轮质量——提示词、检索准确率、响应速度。优化空间集中在一处，容易量化。
- 给目标自己跑（Agent 形态）：重心在循环的稳定性——工具成功率、错误恢复、终止条件、成本上限。优化是系统性的，单点改进常常看不出效果。
这个判断会直接决定你后面该读哪一部：
| 你的形态 | 优先读 | 原因 |
|---|---|---|
| 单轮问答为主 | 第 2、3、7 章 | 提示词 + 检索 + 模型边界 |
| 多步流程但路径固定 | 第 4、12 章 | 工具 + 编排 |
| 自主循环为主 | 第 5、10、13、14 章 | 上下文 + 运行时 + 评估 + 安全 |
先认清形态，再挑技术栈——顺序反了，通常会做出一个"什么都有、什么都不精"的系统。
七、一个补充误区：以为"提示词质量"决定上限
这一个单独拎出来，因为它最普遍。
很多团队在 Agent 效果不好时，第一反应是"再改改提示词"。 改了二十版，效果还在原地。
原因在 1.3 的结论：模型只能看见上下文里有的东西。 提示词写得再好，也变不出它没看到的信息。
判断"是提示词问题还是别的问题"的一句话测试
把正确答案直接放进上下文，看模型能不能答对。
| 结果 | 说明 |
|---|---|
| 能答对 | 不是提示词问题——是信息供给问题（补检索/补上下文） |
| 答不对 | 才是提示词或模型能力问题 |
这个测试 5 分钟就能做，能省掉几天改提示词的时间。
一个常见的误诊链条
现象：Agent 说错了一个业务规则
误诊：提示词没说清楚 → 加三句说明 → 还是错
再误诊：模型不行 → 换更大模型 → 还是错
真因：那条业务规则根本不在上下文里
"那条规则在哪？"这个问题，应该在改提示词之前问。
一个实践建议
在项目里保留一个"上下文清单"：
| 模型需要知道什么 | 现在从哪来 | 是否有 |
|---|---|---|
| 业务规则 | ? | ❌ |
| 项目约定 | CLAUDE.md | ✅ |
| 当前数据 | 工具查询 | ✅ |
| 历史决策 | 无 | ❌ |
两个 ❌ 就是你的真实瓶颈——比任何提示词优化都值得先补。
八、第 1 章小结
把这一章的五篇压缩成一张图：
flowchart LR
A["1.1 从聊天到干活<br/>为什么 Agent 出现"] --> B["1.2 四模块 + 四步闭环<br/>零件与结构"]
B --> C["1.3 为什么必须多次调用<br/>能力天花板在上下文"]
C --> D["1.4 三者的边界<br/>什么时候不该用 Agent"]
D --> E["1.5 常见误区<br/>拆掉错误直觉"]
五个可以带走的结论：
- Agent = LLM + 上下文 + 工具 + 循环（再加规划与终止条件）。四个零件缺一不可。
- 闭环的"回边"是灵魂——上一轮行动的结果成为下一轮判断的依据。
- 多次调用不是选择，是必然——因为工具结果只能通过新调用进入上下文。
- 上下文是能力天花板——提效果先补上下文，再考虑换模型。
- 大多数场景不需要 Agent——先走复杂度阶梯，别一步登天。
九、下一篇
第 1 章回答的是「Agent 是什么」。但要判断一个 Agent 设计得好不好，你还缺一块基础知识：模型本身到底能干什么、不能干什么？
为什么模型必须依赖工具才能做事，而不是直接就把事办了？为什么它有时会一本正经地胡说？为什么同一个提示词，有时有效有时失灵？
第 2 章从模型的工作方式讲起，第一个要讲的就是那个决定 Agent 一切上限的东西——Token 与上下文窗口。