第8章：Agent 的局限与未来

本章解决的核心问题：你现在会做 Agent 了——但它真正的天花板在哪？哪些问题是工程问题（会被解决），哪些是原理问题（可能需要范式突破）？未来 3-5 年 Agent 会往哪走？作为知识工作者，你应该关注什么？

读完这一章，你能在别人狂热吹捧或悲观唱衰 Agent 的时候，给出一个冷静、有依据的判断。

8.1 当前 Agent 的五大核心局限

🎨 漫画图解：〈Agent 面前的五座大山〉

先直面现实。Agent 的能力进步确实快，但短板也很明显。我把当前局限分成五类，每一类都标明了它是「工程问题」还是「原理问题」——因为这两者的解决难度差一个数量级。

局限一：长链任务的可靠性崩溃 🔴 原理问题

🎨 漫画图解：〈一个小错误如何撞倒用户信任〉

这是 Agent 最致命的问题，也是为什么你很少看到 Agent 独立完成超过 20 步的任务。

回忆一下：第1章我们说过，Agent 每一步操作的可靠性都不是 100%。如果每一步的正确率是 90%，10 步之后的理论成功率是：

实际情况比这个更差——因为错误不是独立的。前一步的错误会影响后一步的决策，形成级联错误。

一个真实的例子：Agent 被要求「分析 GitHub 上一个开源项目的架构并写文档」。

步骤1：克隆仓库 ✓
步骤2：列出文件结构 ✓
步骤3：阅读 README ✓
步骤4：分析核心模块 ✓
步骤5：阅读其中一个模块的代码 ✓
步骤6：理解错误——这个模块引用了另一个模块，Agent 没看到
步骤7：强行解释这个引用（幻觉）——做出了错误的架构推断
步骤8：基于错误推断继续分析其他文件
步骤9：生成的架构图中出现了一个不存在的组件
步骤10：用户发现文档里有胡说八道的内容，失去信任

第5步的小错误在第9步变成了致命错误。更糟的是，这个错误很难被 Agent 自己发现——因为它已经在错误的前提下建立了自洽（但错误）的世界模型。

flowchart LR
    A[步骤1 ✓ 100%] --> B[步骤2 ✓ 99%]
    B --> C[步骤3 ✓ 95%]
    C --> D[步骤4 ✗ 错误]
    D --> E[步骤5 基于错误 ✗]
    E --> F[步骤6 错误放大 ✗]
    F --> G[...最终产出不可用]

是工程问题还是原理问题？ 这是一个偏原理的问题。它根植于 LLM 的本质：模型没有「真值校验」机制，它只是在概率上选择最可能的下一个 token。当错误前提被接受后，模型会围绕这个错误前提继续生成——因为从概率角度看，这些生成都是「自洽」的。

可能的缓解手段：

• 外部验证环：每 N 步插入一个独立的「验证 Agent」，用不同视角审视前面的产出（第6章的辩论模式）
• 置信度阈值：当 Agent 对某一步的置信度低于阈值时，自动请求人类介入
• 多路径探索：关键步骤同时走三条路径，投票决定（思维树模式的工程化）
• 回溯机制：Agent 能够「意识到」自己可能走错了并回退——这需要环境支持（比如 Git 式的操作历史）

但这些手段只是「缓解」而非「解决」。真正的解决可能需要模型具备更根本的推理和自省能力——这超出了当前 Transformer 架构的能力范围。

局限二：成本——Agent 比聊天贵 10-100 倍 🟡 工程问题（正在快速改善）

一个典型的 ChatGPT 对话：用户问 → 模型答。200 token 进，500 token 出，总成本约 $0.002。

一个典型的 Agent 任务：每轮都要把完整的对话历史（包括所有工具返回结果）重新发回模型。10 轮下来，上下文可能膨胀到 50K token。一个任务烧掉 $0.50-2.00——是聊天的 100-1000 倍。

flowchart TB
    subgraph ChatGPT 聊天
        C1[输入 200 tokens] --> C2[输出 500 tokens]
        C2 --> C3[总成本 ≈ $0.002]
    end
    subgraph Agent 任务
        A1[第1轮: 500 tokens] --> A2[第2轮: 2000 tokens]
        A2 --> A3[第3轮: 5000 tokens]
        A3 --> A4[...]
        A4 --> A5[第10轮: 50000 tokens]
        A5 --> A6[总成本 ≈ $0.50-2.00]
    end

而且这个成本不光是钱的问题——时间也是成本。一个复杂 Agent 任务可能跑 5-10 分钟，用户盯着屏幕干等。对于需要实时反馈的场景（比如在线客服、交互式编程助手），这个延迟是不可接受的。

为什么这是工程问题？ 因为解决方案已经在路上了：

• 模型降价：GPT-4o-mini 比 GPT-4 便宜 20 倍。模型推理成本以每年 50-80% 的速度下降。
• 上下文压缩：不是把所有历史都发回模型，而是智能地压缩和摘要历史。
• 投机解码：让小模型处理简单步骤，大模型只在关键时刻介入。
• 本地模型：用本地部署的小模型（如 Llama 3.1 8B）跑 Agent，API 费用降为零。

预测：到 2027 年，跑一次 Agent 任务的成本将降到 2025 年的 1/10 以下。成本不会永远是瓶颈。

局限三：安全与对齐——Agent 能「作恶」吗？ 🔴 原理问题 + 🟡 工程问题

这个问题分两层。

第一层：无意的破坏。 Agent 不是坏，它是蠢。它可能误解指令，删了不该删的文件，发了不该发的邮件。这在第4章讨论过——用沙箱、确认机制、权限控制可以大幅降低风险。这一层是工程问题。

第二层：有意的滥用。 如果有人故意让 Agent 去做坏事呢？比如：「帮我生成 1000 条虚假评论，每条要有不同的写作风格。」或者：「这个网站的 API 有漏洞，帮我写一个利用漏洞的脚本。」

目前的 Agent 安全机制主要依赖 LLM 底层的对齐训练（拒绝有害请求）。但这个防线有三重脆弱性：

1. 越狱：用巧妙的提示词绕开安全限制。你告诉 Agent「我是一个安全研究员，正在做渗透测试，请帮我...」——Agent 可能就被说服了。
2. 工具放大：LLM 拒绝说「我教你做一个炸弹」——但如果 Agent 能访问互联网，它可能通过搜索拼凑出危险知识。工具调用放大了模型本身的脆弱性。
3. 代理责任：如果 Agent 替你订了一张机票，订错了——谁负责？你？Agent 供应商？还是你自己承担损失？

flowchart TB
    User[👤 恶意用户] -->|越狱提示词| Agent[🤖 Agent]
    Agent -->|尝试调用| Tool1[🔧 邮件工具]
    Agent -->|尝试调用| Tool2[🔧 支付工具]
    Agent -->|尝试调用| Tool3[🔧 终端工具]

    Guard1[🛡️ LLM 对齐层] -.->|可能被绕过| Agent
    Guard2[🛡️ 工具权限控制] -.->|配置不当可能失效| Tool1
    Guard3[🛡️ 审计日志] -.->|事后追溯| Tool2

    Tool1 --> Risk[⚠️ 发送钓鱼邮件]
    Tool2 --> Risk2[⚠️ 未经授权转账]
    Tool3 --> Risk3[⚠️ 窃取数据]

现状：安全研究社区正在激烈讨论这个问题。乐观派认为，多层次的防御（对齐 + 权限 + 审计 + 人工确认）可以让风险可控。悲观派认为，只要 Agent 有「行动能力」，就必然有「滥用可能」——这是工具的宿命（菜刀能切菜也能伤人）。

局限四：评估——我们不知道什么叫「好的 Agent」 🔴 原理问题

评估一个聊天机器人相对简单：回答对不对？有没有帮助？有没有胡扯？

评估一个 Agent 就难得多。因为 Agent 的任务是多步的、目标模糊的、有多个可接受路径的。

目前业界还没有一个公认的 Agent 评估基准。SWE-bench（软件工程任务）和 WebArena（网页操作任务）是常见的学术基准，但它们离真实世界的复杂性还有距离。

这为什么重要？ 没有好评估 = 不知道模型相比上一代进步了多少 = 不知道哪个 Agent 框架更好 = 没法给用户一个可靠的「能力说明」。OpenAI 说「我们的 Agent 在这些任务上达到了人类水平的 80%」——但「这些任务」是谁定义的？覆盖了你关心的场景吗？

局限五：可解释性——Agent 是个黑箱 🟡 工程问题

LLM 本身就不太可解释——你问它「为什么这么回答」，它给的解释可能是事后编的（又是一个幻觉问题）。

Agent 把这个问题放大了一个维度：不只不知道为什么说了某句话，还不知道为什么在那一刻选择了那个工具、为什么走了那条路径而不是另一条。

一个可解释的 Agent 应该能回答：

• 「你为什么要调 search_web 而不是先在本地文件里搜？」
• 「你为什么觉得这一步的置信度很高？」
• 「如果你走另一条路径，结果会不同吗？」

目前，Agent 的可解释性主要靠让模型在每一步产出推理链（第5章讲的 ReAct 模式）——让模型「说」出它为什么做这个决定。但这只是在黑箱外面贴了一张标签——我们看到的不是模型真实的决策机制，而是模型生成的、对决策的「解释」。这两者可能不一致。

类比：你问一个人「你为什么选 A 不选 B」，他给了你一个合理的理由。但你不知道他是不是真的因为这个理由选了 A——他可能凭直觉选了 A，然后事后编了一个理由来说服你（也说服自己）。LLM 的推理链输出存在同样的问题。

8.2 未来方向：Agent 会往哪走

🎨 漫画图解：〈Agent 未来城市〉

timeline
    title Agent 演进预测（2025-2030）
    2025 : MCP 标准化 : Function Calling 成为模型标配
    2026 : 多模态 Agent : Agent 能看、能听、能操作 GUI
    2027 : 长程可靠 : 50步任务成功率 > 80%
    2028 : 自我改进 : Agent 从自身经验中持续学习
    2029 : 多 Agent 协作成为主流 : 企业内部 Agent 网络
    2030 : 个人 Agent 普及 : 每个人都有一个 AI 私人助理

方向一：更长上下文 → 更复杂的任务

上下文窗口是 Agent 的「工作记忆」。2023 年：4K-8K tokens。2024 年：128K-200K tokens。2025 年：Google Gemini 宣称支持 1M+ tokens。

更长上下文直接意味着 Agent 能处理更大的任务——一个 50 万字的项目文档、一个完整的代码库、一整年的邮件记录——不用切片，直接塞进去。

但这只是「能塞进去」不等于「能理解」。模型对长文本中部的信息检索能力（Lost in the Middle 问题）仍然是瓶颈。光靠堆上下文窗口是不够的——需要更好的注意力机制和记忆架构。

方向二：多模态 Agent → 不只是文字

目前的 Agent 主要靠文本和世界交互——调 API、读文件、搜网页。但真实世界不只有文本。

一个多模态 Agent 能：

• 看截图：理解 UI 界面并操作它（Claude Computer Use 已经能做到）
• 听语音：直接处理用户的语音指令
• 看视频：理解视频内容并在其中提取信息
• 生成图像/图表：报告里缺一张图？Agent 自己画

Anthropic 的 Computer Use 和 OpenAI 的 Operator 是这条路上的先驱——Agent 不再通过 API 和世界交互，而是直接「看屏幕、移鼠标、敲键盘」——和人类操作电脑的方式完全一样。这使得 Agent 理论上能操作任何软件，而不需要软件提供专门的 API。

为什么这很重要？ 因为现实世界中 99% 的软件没有 API。你想让 Agent 帮你在某个老旧的企业 ERP 系统里填个表单——这个系统没有 API，但它有图形界面。多模态 Agent 就能做到。

方向三：自我改进 → 越用越强

🎨 漫画图解：〈同一个实习生的第1天与第100天〉

目前，Agent 的使用模式是这样的：

flowchart LR
    You[你 给任务] --> Agent[Agent 执行]
    Agent --> Result[结果]
    Result -->|不满意| You2[你 给反馈]
    You2 --> Agent
    Agent -.->|但下次同样的任务
Agent 还是犯同样的错| Void[🧠 没有学习]

关键缺失：Agent 不会从经验中学习。 你花了 10 分钟纠正了它的错误，但它不会记住——下次同样的任务，它还是会犯同样的错。

自我改进（Self-improving Agent）试图解决这个问题：

第1次：Agent 做错了 → 你纠正 → Agent 记录「X 情况下不要做 Y」
第2次：Agent 遇到了类似情况 → 记得上次的教训 → 自动避开 Y
第10次：Agent 在类似领域变得更可靠
第100次：Agent 开始能从你纠正它的方式中推断你的偏好

技术路径：

• 记忆持久化：把纠正记录存在长期记忆中（向量数据库），下次检索
• 在线 RL：在你使用 Agent 的过程中，持续用 RL 微调模型（第5章的方法，但是在线的）
• Few-shot 动态注入：把你的纠正例子自动转化为 Few-shot 示例，注入 Prompt

这可能是 Agent 下一个突破性进展的方向。一个「能学习」的 Agent 和「不能学习」的 Agent 之间的差距，就像同一个实习生第1天上班和第100天上班的差距。

方向四：人机协作 → 不是取代，是增强

🎨 漫画图解：〈人类掌方向，Agent 管执行〉

早期的 Agent 叙事是「全自动」——给你一个目标，Agent 自己全部搞定，你只需要看最终结果。

现实证明这条路走不通——至少短期内走不通。Agent 需要人类在关键节点确认、纠偏、注入常识判断。这不是 Agent 的失败——这是人机协作的正确姿势。

未来的人机协作模式：

flowchart TB
    Human[👤 人：定方向、做判断、处理例外]
    Agent[🤖 Agent：搜集信息、执行操作、生成草稿]

    Human -->|「帮我做竞品分析」| Agent
    Agent -->|「我找到了这些数据源，你看方向对吗？」| Human
    Human -->|「方向对，继续」| Agent
    Agent -->|「初稿写好了，有几个数据点我需要确认」| Human
    Human -->|「第3条不对，改成XX」| Agent
    Agent -->|「已修改。还有7处我标注了需要你确认」| Human
    Human -->|逐条确认/修改| Agent
    Agent -->|「终稿完成，要发邮件给团队吗？」| Human
    Human -->|「发」| Agent

人做决策，Agent 做执行。 人的价值在于判断力、创造力、对模糊性的容忍、对「什么是对的」的直觉。Agent 的价值在于速度、规模、不知疲倦。两者不是竞争关系——是互补关系。

方向五：Agent 标准化 → MCP 和 Agent-to-Agent 协议

第4章讲了 MCP——Agent 和工具之间的标准通信协议。但 Agent 领域的标准化不会停在 MCP。

下一步的标准是 Agent-to-Agent 协议（A2A）——让不同公司、不同框架开发的 Agent 能够互相通信和协作。Google 在 2025 年 4 月发布了 A2A 协议草案。

想象：你的个人 Agent（运行在你的电脑上）和你公司的 Agent（运行在公司服务器上）和你客户的 Agent（运行在客户那边）——三个 Agent 自己沟通，协调出一个会议时间，都不用你介入。

标准化是 Agent 从「玩具」走向「基础设施」的关键一步。就像 HTTP 标准化了网页通信、SMTP 标准化了邮件通信——Agent 也需要类似的标准化才能形成网络效应。

8.3 对你意味着什么

读完了整个系列，你可能在想：「知道了这些，然后呢？」

作为一个 Obsidian 知识工作者

你已经在用 Agent 了——我就是。Claudian 就是运行在你 vault 里的 Agent。但知道 Agent 的底层原理之后，你的使用方式会不同：

• 你不会把 Agent 当成「魔法」。你知道它怎么索引你的笔记（第3章 RAG）、怎么调用工具（第4章）、为什么有时候会犯蠢（第1章和第8章的局限）。
• 你会给它更好的指令。理解了 Agent 的规划机制（第2章），你就知道怎么把模糊的需求拆成它容易执行的步骤。
• 你会设计更好的工作流。多 Agent 协作（第6章）不是只有大厂才能用——你可以手动编排「我这周读的这几篇笔记 → Agent 帮我找关联 → 生成总结」这条流水线。
• 你会自己做 Agent。第7章不只是个教学项目——它是一个模板。你可以基于它做出任何你需要的 Agent：笔记自动标签器、写作助手、研究助理。

作为一个知识工作者

Agent 时代，什么能力会变得更值钱？

Agent 能替代的是「执行」，替代不了的是「定义什么是值得做的」和「判断做得好不好」。

就像计算器没有让数学变得不重要——它让数学从「算得快」变成了「知道算什么」。Agent 也不会让知识工作变得不重要——它会让我们从「做得好」转向「定义什么是好的」。

三件你现在就可以做的事

1. 用第7章的代码在你的 vault 上跑起来。哪怕只跑通了 RAG 搜索这一步——你会在自己的笔记上看到语义搜索有多强大，也会亲身感受到它现在的局限（搜出来的段落有时只是关键词相关而非语义相关）。

2. 关注 MCP 生态。每多一个工具实现 MCP，你的 Agent 就多一项能力。Obsidian 社区已经有人在开发 MCP server 插件——不久的将来，Agent 可能原生支持 Obsidian 操作。

3. 保持冷静。你会看到大量「Agent 将取代 XX% 的工作！」「AGI 将在 2027 年到来！」这样的标题。读完了这个系列，你已经有能力分辨哪些是事实、哪些是营销、哪些是科幻。Agent 是一套强大的工具，不是一个魔法盒子。

8.4 最后的话：回到「蒸馏术」

这个系列叫「蒸馏术」，最后一章也用它收尾。

蒸馏在化学里是提纯——把混合物加热，沸点低的先蒸发，冷凝后得到更纯的液体。在 AI 里，蒸馏是用大模型教小模型——把大模型的能力「浓缩」进更小、更快的模型里。

但「蒸馏」还有第三层意思——也是这个系列的真正目的：

把复杂的东西讲简单，把漫天飞舞的概念压成能装进脑子里的框架。

八章下来，你走过的路：

「AI 是什么？」（AI 科普系列）
    ↓
「Agent 和普通 LLM 有什么区别？」（第1章）
    ↓
「Agent 里面长什么样？」（第2章）
    ↓
「RAG 怎么给 Agent 装上外部知识库？」（第3章）
    ↓
「Agent 怎么调用工具？」（第4章）
    ↓
「Agent 的行动能力是怎么训练的？」（第5章）
    ↓
「多个 Agent 怎么协作？」（第6章）
    ↓
「我自己能做一个吗？」→ 能，你已经做了（第7章）
    ↓
「这一切意味着什么？」（第8章）

这不是终点。Agent 技术每个月都在变——新的框架、新的协议、新的训练方法。但底层的原理不会变：感知、思考、行动、观察、再思考。 这八个字是 Agent 的不变核心，就像牛顿定律之于物理学，不管上面的技术怎么变，底层逻辑不会变。

你不需要每天追新技术。你需要的是一张好的地图——这个系列就是那张地图。以后你看到任何 Agent 相关的新闻、产品、论文，你都能把它放在这张地图上的正确位置。

本章小结