第 4 章：模型在 Agent 里到底负责什么
本章目标：把模型从神话里拉下来，讲清它在 Agent 系统里的真实职责、能力边界与常见误判。
本章对应总纲：docs/ebook-outline.md中“第 4 章正文写作提纲（2026-03-31 归档）”。
4.1 为什么很多人会把 Agent 问题误判成模型问题
这一章要专门回答一个常见误解：
只要模型足够强，Agent 的大部分问题就会自然消失。
这是错的。
一遇到 Agent 做不好，最常见的反应就是：
- 模型不够强
- 上下文太短
- 推理能力不够
- 换个更大的模型试试
这种反应不一定错，但多数时候太懒。
因为在真实系统里，失败来源往往根本不只在模型。它也可能是：
- 工具描述不清
- 状态没保存好
- 权限边界太乱
- 决策逻辑没接住反馈
- 目标定义本身就含糊
所以在分析 Agent 时，一个重要纪律是：
先区分这是模型问题，还是系统结构问题。
如果不做这一步，后面就很容易把所有毛病都怪到模型头上。
4.2 模型在闭环里真正负责哪几件事
如果把 Agent 看成一套运行系统，那么模型主要负责四类事情：
- 理解：理解用户目标、上下文、工具描述、反馈信号
- 判断：在当前状态下决定下一步最合适的动作
- 生成：生成自然语言、结构化参数、计划片段或调用指令
- 压缩：把大量上下文提炼成后续可用的中间表示
这四件事合起来，决定了模型是 Agent 的认知核心。
但注意，这里说的是“认知核心”，不是“系统本体”。
系统本体还包括：
- 工具接口
- 状态层
- 执行循环
- 权限边界
- 停机条件
模型只负责其中一层。
4.3 理解：模型先把输入世界变成可判断的问题
4.3.1 不是看见文字，而是建立任务语义
用户说一句：
帮我修一下这个测试失败。
模型要做的第一件事，不是立即输出方案，而是把这句话转成一个更可操作的问题：
- 当前目标是什么
- 这是修改请求还是解释请求
- 要先读取什么上下文
- 当前是否已经有足够信息行动
也就是说，模型先把松散输入整理成任务语义。
4.3.2 为什么工具描述也属于模型要理解的输入
很多人低估了一件事：在 Agent 里，工具描述本身就是模型的重要输入。
因为模型必须理解：
- 这个工具能做什么
- 什么时候该用它
- 输入格式是什么
- 输出意味着什么
- 和别的工具相比该怎么选
所以工具系统设计差，常常不是“工具少”，而是“模型根本看不懂该怎么用”。
这时你再去怪模型智商不够，方向就歪了。
4.4 判断：模型最核心的价值，是在当前局面里选下一步
4.4.1 模型不是负责一次想明白全部，而是负责局部决策
这也是 Agent 思维和传统 prompt 思维很不一样的地方。
传统 prompt 更像是：
- 尽量把问题一次说全
- 期待模型一次答全
- 输出结束，任务基本结束
而 Agent 里的模型更像一个带反馈的决策器：
- 先基于当前状态做局部判断
- 选择下一步动作
- 接住动作结果
- 再进入下一轮判断
所以在真实运行里，模型更常做的不是“完成整道大题”，而是：
在当前这轮状态下，选出最值得做的下一步。
例如：
- 先读文件还是先搜定义？
- 先修改还是先验证？
- 继续当前路径还是回退？
- 该自主处理还是该问用户？
这类判断看起来不惊天动地，但它们决定了系统是不是能稳着往前走。
4.4.2 好模型和差模型，差别常体现在局部判断质量
一个模型可能写得很能说，但在执行场景里表现很差。原因通常不是它不会表达，而是它的局部判断质量不稳定。
常见症状有：
- 明明该先读上下文，却直接开始改
- 明明该验证结果，却提前宣布成功
- 明明遇到权限边界，却继续硬做
- 明明路径已经错了，却不回头
所以做 Agent，不要只看模型写出来的话漂不漂亮，而要看它选下一步动作时稳不稳。
4.5 生成：模型不只生成文本，还生成动作接口
4.5.1 在 Agent 里，“生成”不是单纯写文章
在普通聊天里，生成通常意味着输出一段自然语言。
但在 Agent 里，生成还常常意味着：
- 生成工具调用参数
- 生成结构化结果
- 生成计划片段
- 生成对环境状态的中间描述
- 生成给用户的澄清问题
所以模型输出并不只是“最终答案”，它经常只是系统内部下一步动作的接口材料。
4.5.2 为什么结构化生成尤其关键
如果模型生成结果太散、太含糊，系统就很难稳定接住。
比如：
- 工具调用参数不稳定
- 状态摘要忽长忽短
- 计划表达风格每轮都变
- 反馈归纳前后不一致
这些问题单看像小毛病，叠起来就会把 Agent 的执行稳定性打烂。
所以从系统设计角度看，模型生成能力最值钱的地方，不是文采，而是可接入性和可复用性。
4.6 压缩：模型还承担上下文整理器的角色
4.6.1 为什么 Agent 一定会遇到上下文膨胀
只要任务不是一句话结束，系统就会不断积累：
- 用户需求
- 文件内容
- 工具输出
- 错误日志
- 中间判断
- 历史尝试
这些信息不可能无限堆着不整理。否则上下文越跑越肿，系统会越来越笨。
所以模型除了理解和判断，还要承担一件非常现实的事：
把旧信息压缩成后面还用得上的表示。
4.6.2 压缩不是摘要好看，而是保留后续最需要的东西
真正有价值的压缩，不是把原文缩短，而是保留：
- 当前目标
- 已完成步骤
- 已证伪路径
- 尚未解决的问题
- 关键约束和边界
压缩得好，后面的判断就稳；压缩得差，系统就会开始遗忘重要事实，然后重复犯错。
所以“摘要”在 Agent 里不是附属功能，而是连续执行的基础设施。
4.7 哪些事再强的模型也不该独自背锅
现在反过来说：模型不负责什么。
4.7.1 模型不负责提供真实外部能力
模型不会凭空读文件、运行命令、访问网络。
这些能力来自工具层。
如果系统根本没有对应工具，或者工具权限被限制，那不是模型不够强，而是系统能力边界就在那里。
4.7.2 模型不负责保证动作真的生效
模型可以建议改法，也可以生成改动，但“改完后到底有没有修好”，必须靠反馈层验证。
没有验证，模型再自信也没用。
4.7.3 模型不负责决定全部风险边界
删除文件要不要确认、能不能推送远端、是否允许写敏感路径，这些都属于系统级边界控制。
如果这些边界全靠模型自由发挥，那系统迟早出事。
4.7.4 模型不负责长期一致性
长期记忆、项目偏好、跨会话规则、持久状态，这些都不能只寄托在“模型自己记住”。
该存储的就得存储，该索引的就得索引。
靠模型自然记忆，是不负责任的设计。
4.8 为什么“模型更强”仍然很重要
前面说了这么多边界，不是为了贬低模型，而是为了把责任分清。
模型仍然极其重要，因为它直接影响：
- 理解是否准确
- 判断是否稳定
- 工具选择是否合理
- 参数生成是否可靠
- 压缩是否保留关键事实
你可以这么理解：
- 系统结构决定上限能不能成立
- 模型质量决定这个上限能不能稳定达到
两者不是替代关系，而是乘法关系。
结构烂，强模型也救不回来。 模型差，好结构也跑不顺。
4.9 用 Claude Code 看模型的现实位置
在 Claude Code 这样的系统里，模型显然不是孤立工作的。
先看当前仓库怎么描述自己。plugins/README.md:6 把系统扩展面拆成 custom commands、specialized agents、hooks、MCP servers；plugins/README.md:48 又把插件结构固定为 commands/、agents/、skills/、hooks/、.mcp.json。这种结构本身就在表达一个很重要的判断：模型不是系统本体，它只是被放进多个控制层之间的认知引擎。
再看 plugins/README.md:16、plugins/README.md:19、plugins/README.md:24。这里的 code-review、feature-dev、pr-review-toolkit 都把任务拆给不同执行角色。甚至连审查这种事，都不是让一个模型“一次想完”，而是让多个角色分别做 bug detection、architecture design、quality review、comments analysis、type design analysis。
这背后说明两件事：
- 模型负责局部高价值判断，不负责包打天下
- 一旦任务复杂，系统会优先拆执行角色，而不是指望单个模型裸奔解决所有问题
再往风险边界看，examples/settings/settings-strict.json:1 把 Bash 放进 ask，把 WebSearch / WebFetch 放进 deny。这又说明：模型即使判断“应该这么做”，也不等于系统就允许它直接这么做。模型给出的是候选动作，系统边界才决定动作能不能落地。
所以 Claude Code 这个样本真正值得学的，不是“模型很强”这句废话，而是它把模型放在了一个更大的控制结构里，并默认遵守几条规则：
- 模型负责理解、判断、压缩，不负责定义边界
- 动作是否允许执行，要由工具层和权限层决定
- 复杂任务优先拆角色，不要把所有复杂度都压给同一个模型
- 模型能力提升是收益项，但不是替代结构设计的借口
这才是现实系统里模型的正确位置：它很重要，但它永远是结构中的一层，不是结构本身。
4.10 设计 Agent 时，应该怎样正确看待模型
工程上，一个更稳的态度是：
第一，把模型当认知引擎，不当万能核心
它非常重要，但不是所有责任都归它。
第二，把模型能力浪费在真正值得的地方
比如：
- 理解模糊需求
- 进行局部推理
- 选择下一步动作
- 压缩复杂状态
而不是让它做一堆本该由固定机制保证的事。
第三，把系统问题和模型问题分开诊断
看到失败，先问：
- 是模型理解错了？
- 还是工具定义太差？
- 是状态丢了？
- 还是闭环没接住反馈？
这样你才能真正优化系统，而不是只会喊“换更大的模型”。
4.11 本章小结
这一章的核心，不是讨论哪个模型更强，而是把模型在 Agent 里的责任边界讲清楚。
你现在应该记住六件事：
- 模型是 Agent 的认知核心，但不是 Agent 全部。
- 模型主要负责理解、判断、生成和压缩。
- 很多所谓“模型问题”，其实是工具、状态或闭环设计问题。
- 再强的模型，也替代不了真实工具、反馈验证和权限边界。
- 模型质量决定系统判断是否稳定，但系统结构决定这些判断能否落地。
- 做 Agent 设计时，最蠢的做法就是把所有毛病都怪到模型头上。
下一章我们继续往下走，专门看工具这一层：为什么工具不是随便挂几个 API 就完事，而是整个 Agent 系统最容易做烂、也最决定行动质量的一层。