从陪聊到掌权：AI应用的七种面孔

1问题

想象你在用手机地图规划一条从家到公司的路线。最笨的办法是，你每走一步都问 AI：“前面左转对吗？”然后等它回复“对”，你再输入下一个指令。这就像早期的 LLM 对话系统，聪明但迟钝。更高级的情况是，你把车钥匙交给一个全自动司机，你只告诉它目的地，中间怎么绕路、怎么避让，你一概不知，直到到达终点才看到结果。现在的商业世界里，到处都是这两种极端：有的像话痨客服，有的像神秘黑盒。厂商们把各种功能包装成“聊天机器人”、“副驾驶（Copilot）”、“智能体（Agent）”、“工作流”等不同名字卖给你。读者面临的困境是：这些花哨的名字到底是真正不同的技术架构，还是只是市场部的营销噱头？如果分不清，你就没法判断哪个工具适合解决什么复杂问题——你可能用了一个需要反复确认的“副驾驶”，去处理本该全自动完成的任务，导致效率极低；或者用了一个全自动的“智能体”，去处理需要人类精细把控的创意工作，结果完全失控。

2翻译

要解开这个谜团，我们需要看透那些术语背后的“骨架”。作者把视角从“它能做什么功能”转到了“它是怎么控制执行的”。我们回到刚才开车那个例子。如果你发现这些名字其实指向几种固定的结构模式，事情就清晰多了。首先，有个叫“LLM 聊天”的东西，它的骨架是单步执行，用户每说一句话，模型回一句，控制权全在用户手里。其次是“RAG（检索增强生成）”，这听起来很技术，但本质上它只是个加了外部图书馆的单步聊天机器，用来查资料准确度高点，但执行逻辑没变。再往后，出现了“AI 增强的工作流”，这就有意思了，它像是预先画好了流程图，AI 负责填充每个环节的内容，但流程怎么走是写死的，人不能随意插嘴。这里的关键转折在于“Copilot（副驾驶）”和“Coding Agent（编码智能体）”。Copilot 是一种特殊的助手，它在后台干活，但你必须一步步点头同意才能继续，它是个谨慎的合伙人。而真正的“智能体”范式，特别是编码领域的智能体，展示了一种名为“推理-行动循环”的结构：AI 自己思考下一步该干嘛，调用工具去试，看结果对不对，不对再改，直到搞定为止。在这个过程中，人类通常只看最后的结果，不干涉过程。作者分析了 22 个具体系统（包括知名大厂的产品和研究项目），发现不管名字多花哨，最终都能归结为这几种架构的组合。比如，“定制智能体”其实就是给了特定权限的智能体，而“Agentic RAG”则是让智能体自己去图书馆找书而不是被动等查询。通过这些分类，你可以清楚地看到，所谓的技术进步，本质上是“控制权”从人向机器的逐步让渡，以及“执行步骤”从单次向多步自动化演化的过程。这里有一个反直觉的发现：很多号称“自主智能体”的系统，在实际代码层面，往往只是简单地把几个脚本串联起来，并没有展现出真正的动态规划能力，它们更像是在披着智能体的外衣做传统编程。

3核心概念

为了让你能精准挑选工具，我们必须拆解支撑这些系统的三个核心构件。

第一个是执行控制权的归属。这是区分所有应用类型的灵魂所在。如果是“LLM 聊天”或“RAG”，控制权在人，AI 只是响应者。如果是“Copilot”，控制权是共享的，人掌握刹车和油门，AI 提供动力。如果是“智能体”，控制权转移给了 AI，人只设定目标和审查结果。理解这一点，你就能明白为什么有些场景（如医疗诊断辅助）绝不能用全自动智能体，因为控制权不能完全交出。

第二个是工具调用的机制与频率。旧的路径里，工具（如搜索、数据库）是被动的等待指令。而在新的“智能体”架构中，工具变成了手脚。关键在于“推理-行动循环”：AI 不仅要生成文字，还要生成“调用某个工具”的代码或命令。比如，一个财务分析智能体，它会先“推理”出需要今天的股价，然后“行动”去抓取数据，再“推理”是否需要对比去年数据，再“行动”。这种多步、依赖反馈的循环，是高阶智能体的标志，区别于一次性回答问题的简单应用。

第三个是架构层面的路由策略。这是很多外行容易忽略的设计选择。特别是在“Copilot”和“编码智能体”之间，存在细微但致命的差别。Copilot 通常是同步的、线性的辅助，它嵌入在你的编辑器或文档里，随时待命。而现代编码智能体（如 GitHub Copilot Workspace 或 Devin 类原型）往往采用主从架构：有一个主控 Agent 负责拆解任务，然后派遣多个子 Agent 并行或串行去处理具体模块，最后汇总。这意味着，当你看到“Agent”这个词时，要问自己：它是直接跟我对话的单个大脑，还是一个调度员带领的团队？这个设计选择决定了系统的复杂度和错误处理能力。团队作战比单个大脑更能应对长链条任务，但也带来了协调成本。

4洞见

这篇论文真正的内核是：不要看广告语，要看控制权流向图。所有的 LLM 应用创新，本质上都是在调整“人类介入时机”和“机器自主步数”这两个旋钮，而非发明全新的魔法。

5博导审稿

这学生选题眼光不错，抓住了当前行业混淆视听的痛点。他把一堆乱麻一样的产品标签理清了，这点很有诚意。但是，他对“智能体”的定义可能还是太偏向工程实现了，忽略了认知层面的差异。比如，他提到的“推理-行动循环”，在很多现有系统中只是伪装的硬编码流程，并没有真正的动态环境交互能力，这部分他没有深入质疑，显得对现状过于宽容。另外，实验部分主要基于供应商文档和产品描述，缺乏对底层代码或实际运行日志的深度审计，数字经不起追问。比如他说某些系统是“自主执行”，但如果我们追踪其失败案例的自愈率，可能会发现它们远没那么智能。写作上条理清晰，但略显干巴。判决：weak accept。建议补充对“虚假自主性”的深度批判章节，否则容易沦为产品说明书的整理汇编。

6启发

这意味着你可以____。1. 迁移：在你正在设计的系统中，先画出“控制权流向图”。如果目前是全自动，试着加入“Copilot 模式”的检查点，看看能否在不大幅改动代码的情况下，提升人类信任度。2. 混搭：把你现有的“RAG 知识库”接入到一个“小规模的推理-行动循环”中。不要让它只回答问题，而是让它根据答案去触发后续的通知或数据更新动作，瞬间从一个查询库变成一个工作流引擎。3. 反转：默认假设是“智能体越自主越好”。尝试反转一下，在一个高敏感度的金融审批场景中，设计一个“反向限制”的智能体：它只能提出建议，且必须附带三种备选方案供人类勾选，通过限制其自由度来降低合规风险，这可能比盲目追求自动化更有价值。