跳到主要内容

第30章:应用演进小结

回顾第七部分走过的路,我们从一个简单的对话窗口出发,一步步走到了多智能体协作系统。每一次演进都不是为了炫技,而是被现实问题逼出来的。本章用宏观视角梳理这条演进链,诚实评估当前的能力边界,并展望下一波浪潮。


30.1 完整演进图

每一步都是被问题逼出来的

第一步:Chat(对话)

最初,LLM 只是一个文本输入/输出的接口。用户提问,模型回答。这足以处理解释概念、写文章、翻译等任务。

但问题随之而来:模型无法执行任何外部操作。想查天气、查数据库、调 API?对不起,模型只能描述"你可以去做 X",却无法真正去做。

第二步:Function Call(函数调用)

为了让模型"能做事",引入了 Function Call 机制。模型不再只输出文字,而是可以输出结构化的调用指令,由宿主程序执行后再把结果返回给模型。

用户输入 → 模型决策 → 调用函数 → 获取结果 → 模型输出最终答案

这解决了"不能操作外部系统"的问题。但新问题出现了:每个应用都要自己定义一套工具集,格式各异,生态碎片化

第三步:MCP(Model Context Protocol)

MCP 是工具调用的标准化协议。它定义了工具如何声明自己、如何被调用、如何返回结果——就像 USB 统一了设备接口。任何支持 MCP 的模型都能无缝接入任何 MCP 工具服务器。

这解决了碎片化问题。但新问题是:单轮工具调用不够用,复杂任务需要多步推理和动态决策

第四步:Agent(智能体)

Agent 引入了"思考-行动"循环(ReAct 框架):模型不断推理当前状态,选择下一步工具,执行后观察结果,再继续推理,直到任务完成。这是从"执行单条指令"到"完成目标"的质变。

但新问题是:Agent 是无状态的,每次启动都从零开始;同时,单一 Agent 能力有限,复杂任务超出其能力范围

第五步:Skills(技能库)

为了让 Agent 能处理更专业的垂直任务,引入了可复用的 Skill 模块——预先定义好的能力包,Agent 可以按需调用。这提升了可靠性和可维护性。

第六步:Multi-Agent(多智能体)

面对真正复杂的任务(如"帮我分析整个代码库并生成迁移方案"),单一 Agent 力不从心。Multi-Agent 架构让 Orchestrator 将任务拆解,分发给多个专业 Sub-Agent 并行执行,再汇总结果。

但新问题出现了:协调本身变得复杂,通信开销上升,单点失败会级联传播

演进全景表

阶段核心能力解决的问题引入的新问题
Chat文本理解与生成知识问答、内容创作无法执行外部操作
Function Call调用外部工具接入真实系统(API、数据库)工具定义碎片化
MCP标准化工具协议生态互通、工具复用单步调用不够复杂任务
Agent多步推理循环完成目标而非执行指令无状态、单点能力瓶颈
Skills可复用能力模块垂直领域可靠性提升技能组合的协调问题
Multi-Agent并行协作大规模复杂任务分解协调开销、级联失败

:::info 演进的本质 每一步演进都遵循同一个模式:解决"能做什么"的限制,但引入"如何可靠地做"的挑战。从 Chat 到 Multi-Agent,能力半径在扩大,但可靠性工程的难度也在指数级增长。 :::


30.2 当前能力边界

诚实地评估当前 LLM 应用的能力,比盲目乐观或悲观都更有价值。

能做好的(成熟可用)

代码辅助

这是目前最成熟的应用场景。模型能理解代码上下文、补全函数、解释错误、生成测试用例。GitHub Copilot、Cursor 等工具已被数百万开发者日常使用,可测量的生产力提升明显(多项研究显示效率提升 30%–55%)。

文档写作与总结

给定足够的上下文,模型能生成高质量的技术文档、会议纪要、邮件草稿。这类任务有明确的输入/输出格式,且错误可被人类轻松发现并纠正。

信息检索整合

结合 RAG(Retrieval-Augmented Generation)的 Agent 能从大量文档中检索相关片段,并综合成有条理的回答。这在企业知识库、客服系统中已大规模落地。

结构化数据处理

将自然语言转为 SQL 查询、JSON 提取、表格分析等任务,模型表现稳定。前提是输入格式清晰,输出有 schema 约束。

做得不稳定的(需要人工监督)

长期规划

让模型制定并执行一个跨越数十步的计划,成功率会随步骤增加而显著下降。误差积累(error compounding)是核心问题:第 3 步的小错误到第 10 步可能已酿成大偏差。

复杂 Multi-Agent 协调

当多个 Agent 需要协作完成相互依赖的子任务时,协调复杂度急剧上升。一个 Sub-Agent 的输出格式稍有偏差,就可能导致下游 Agent 失败。当前系统往往需要大量"胶水代码"来处理边界情况。

高风险操作

删除文件、发送邮件、提交代码、执行金融交易——这些操作的错误代价很高,当前 Agent 系统的可靠性还不足以在无监督状态下执行。

:::warning 可靠性是核心瓶颈 当任务成功率为 pp,执行 nn 步的总成功率约为 pnp^n。若每步成功率为 95%,10 步任务的总成功率只有 0.951060%0.95^{10} \approx 60\%。这解释了为什么复杂 Agent 任务在实践中常常令人失望。 :::

还做不到的(当前技术边界)

持久化自主行动

现有 Agent 本质上是无状态的会话系统。启动一个任务、执行、结束——没有跨会话的记忆,没有"后台持续运行"。要真正自主地执行"监控这个系统一周,有异常就处理"这类任务,还缺乏可靠的基础设施。

真正理解因果关系

模型擅长识别相关性,但对因果推理(counterfactual reasoning)存在系统性缺陷。"如果我不做 X,结果会怎样?"这类反事实问题,模型往往给出听起来合理却经不起推敲的答案。这限制了模型在科学发现、策略制定等需要深层因果理解的领域的应用。


30.3 未来方向:Computer Use / 持久化 Agent

Computer Use:跨越 API 的边界

现有 Agent 依赖工具调用——这意味着系统必须提前为 Agent 准备好 API 接口。但现实中大量软件没有 API:遗留系统、桌面应用、需要人机交互的流程。

Computer Use(Anthropic 为 Claude 推出的能力)让模型能像真实用户一样操作计算机:看屏幕截图 → 决定点击哪里 → 执行鼠标/键盘操作 → 观察结果。

截图 → 视觉理解 → 生成操作指令(click, type, scroll)→ 执行 → 观察新截图 → 循环

这使 Agent 能操作任何有 UI 的软件,突破了 API 边界。代价是:速度慢、错误率高、难以调试。

OpenAI Operator 采用类似思路,专注于网页操作:自动完成表单填写、网页导航、购物结账等任务。

持久化 Agent:从"会话"到"长期雇员"

当前 Agent 像一个只在你打电话时工作的助理——挂断就忘了一切。持久化 Agent 的愿景是:像一个真正的团队成员,能跨越数天、数周持续执行任务。

关键技术挑战包括:

挑战问题描述当前方案
记忆管理如何在长期运行中保留重要上下文而不超出 context 限制外部记忆存储 + 检索(类 RAG)
状态持久化进程中断后如何恢复检查点(checkpoint)机制
错误恢复某一步失败后如何继续重试策略 + 人工介入接口
权限管理用户愿意授权多少?如何防止越权?最小权限原则 + 审计日志

两个核心挑战

可靠性:一个步骤失败如何恢复?

长期任务的可靠性问题比单次任务严峻得多。设想一个运行 3 天的数据分析 Agent,第 2 天第 17 步失败了——是重试、回滚、还是跳过继续?这需要健壮的事务模型,而当前的 Agent 框架大多缺乏这一层。

可信度:用户愿意授权多少?

这是比技术更深层的问题。即便 Agent 技术可靠,用户愿意让一个 AI 系统自主发送邮件、删除文件、进行支付吗?可信度的建立需要时间和透明度——清晰的操作日志、可随时中断的控制权、以及足够多的成功案例积累。

:::tip 可信度是渐进建立的 历史上每一种新技术的信任都是渐进建立的:人们先在低风险场景中接受自动化(如自动驾驶先用于辅助,后用于全自动)。Agent 的可信度建立也将遵循同样路径:从"只读操作"到"可撤销操作",再到"不可逆操作"。 :::


本章小结

维度核心观点
演进逻辑Chat → Function Call → MCP → Agent → Skills → Multi-Agent,每步被上一步的局限性驱动
成熟场景代码辅助、文档写作、RAG 信息检索、结构化数据处理
待成熟场景长期规划、Multi-Agent 协调、高风险操作
技术边界持久化自主行动、深层因果推理
未来方向Computer Use(突破 API 边界)、持久化 Agent(跨会话长期执行)
核心挑战可靠性(错误恢复)和可信度(授权边界)是比算法更难的问题

第七部分至此收尾。从一个对话框,到能操作桌面、跨会话自主运行的 Agent,这条演进线还远未走完。

在第八部分,我们将转向 LLM 的另一个关键维度:训练与对齐——模型是如何从"能说话"变成"说有用的话、说安全的话"的,以及 RLHF、Constitutional AI 等技术背后的机制。