范式转移：为什么 Copilot 走到了尽头 / The Copilot Ceiling
第 1 章 范式转移：为什么 Copilot 走到了尽头
2024 年 3 月，一个叫 Devin 的 AI 工程师在演示视频里接了一个 Upwork 任务：修复一个开源仓库里 5 个相互依赖的 Bug。视频里它打开浏览器、克隆仓库、阅读代码、写补丁、跑测试、重构、重测，最后交付了一份 Pull Request。整个过程没有人类插手，总耗时约 45 分钟。
同一个月，《新程序员》杂志的技术编辑老周在用 GitHub Copilot 写一篇关于 React Server Components 的文章。他让 Copilot "帮我调研一下 RSC 在 2024 年的最新进展"，Copilot 礼貌地给了一段总结，引用了 2022 年的一篇博客。老周追问："能不能看看 Astro 和 Next.js 在 RSC 上的对比？"，Copilot 又给了一段，但要他贴代码；贴完之后说："看起来 Astro 使用了 islands 架构……"，然后问他下一个问题是什么。
老周在第 5 轮对话时关掉了 Copilot，打开了 ChatGPT，手动规划了 8 步搜索策略，花了 3 个小时才拿到一份像样的报告。
这不是个例。这是范式的必然崩溃。
1.1 一个研究任务的崩溃实录：Copilot 模式的死循环
为了让论证有据可查，我们先做一次现场实验。
任务很简单，也很真实："帮我整理一份 2024 年中国新能源汽车市场的竞争格局报告，要求包含头部 5 家企业的市场份额、主要技术路线差异、用户反馈亮点与槽点，最后给出一份给投资人的一页纸结论。"
我们用市面上三款代表性的 Copilot 模式产品——GitHub Copilot Chat、Microsoft 365 Copilot、文心一言 4.0——按普通用户的直觉使用方式，进行了同样的对话。
1.1.1 第 1-2 轮：体感还不错
第一轮你问："请帮我整理 2024 年中国新能源车市竞争格局。"
三个产品都在 8 秒内吐出了一份漂亮的大纲——比亚迪、特斯拉、理想、蔚来、小鹏，五家企业的份额罗列，并附了"建议关注以下问题"之类的话术。这一刻你甚至会想，AI 真的进步巨大。
第二轮你追问："市场份额数据能给到 2024 Q3 吗？"
这是关键拐点。Copilot 类产品的训练数据普遍截止于 2023 年底或 2024 年中（具体日期因厂商策略不同），并且它们不会主动告诉你这个边界。Chat 模式给出了一个"看起来很合理"的数字——比亚迪 32%、特斯拉 8%……而当你需要验证时，才发现这些数字有的来自 2023 年的乘联会数据，有的来自不同口径的预测报告，没有任何来源链接。
到这里，Copilot 已经悄悄完成了一次"幻觉"（hallucination）——只不过穿上了引用编号的外衣。
1.1.2 第 3-4 轮：上下文开始漂移
第三轮："理想和蔚来在 800V 高压平台上的差异是什么？"
第四轮："把前面所有信息整理成 Markdown 表格。"
问题开始堆叠。你注意到一个诡异的现象：在第四轮里，Copilot 似乎已经"忘记"了第二轮你追问的市场份额数据——它给的表格里，市场份额那一列的数字和第二轮不一样。再追问一次，它又变了。
这不是 Copilot 的"bug"，而是 LLM（Large Language Model，大语言模型）在意图管理（intent management）上的结构性短板：当对话窗口超过 4-5 轮，多个意图被叠加之后，模型会把"用户真正想要什么"和"用户最近问过什么"混淆起来。你看到的是漂移，本质上是模型在没有外部记忆结构的情况下做长链推理，认知负担过重。
1.1.3 第 5-7 轮：开始"踢皮球"
第五轮你提了一个新需求："请补充理想 MEGA 这款车的用户反馈，特别是负面评论。"
Copilot 给了一段"用户普遍反馈 MEGA 外观有争议"的敷衍答案。你追问："我要的是真实差评，最好是车主的原话。"
Copilot 回答："很抱歉，我无法直接访问互联网获取最新的用户评论。建议您参考汽车之家、懂车帝等平台。"
在第 5-6 轮之后，Copilot 类产品几乎一定会退化为"建议你去搜索"的状态。 它们不主动调用工具（即使有工具调用能力），它们不主动分解任务，它们不主动告诉你"这件事我不能做"。
这不是工具问题，是角色问题。Copilot 的设计哲学是"你说我做"，它默认你作为用户是规划者、拆解者、决策者。它只负责响应。
1.1.4 第 8 轮：你开始累，AI 也开始累
到第 8 轮时，老周类的用户会有一个明显的感受："我比写完一份报告还累。"
为什么？因为他在承担整个任务的项目经理角色：
- 要分解任务（"先问市场份额，再问技术路线，再问用户反馈，最后要投资建议"）
- 要管理上下文（"刚才的份额数据是错的，以这个为准"）
- 要验证准确性（"这个数字哪儿来的？"）
- 要整合输出（"前面说的和这一段矛盾，重新整理"）
- 要识别能力边界（"它不会联网，我得自己去搜"）
而 Copilot 本质上只承担了"打字员"角色。它每次响应都是独立的。它不知道"这个任务的整体进度在哪里"、"前面哪一步出错了"、"哪些事情还没做"。
这就是我们要论证的第一个核心判断：Copilot 不是因为"不够聪明"而失效，而是因为它从未被设计来承担"项目管理"这个角色。 这不是模型能力问题，是产品范式问题。
1.1.5 复盘：同样的任务，Agent 模式如何展开
我们用同样任务跑了一款 Agent 模式产品（基于 Manus 2025 年的工作流）。输入同样的需求，Agent 在无人干预的情况下：
1. 自主规划：把任务拆成"市场数据收集 → 技术路线对比 → 用户评价抓取 → 数据交叉验证 → 投资结论生成"5 个子任务 2. 主动调用工具：用浏览器访问乘联会官网、中汽协、车质网、汽车之家，抓取 2024 Q3 数据 3. 多轮反思：发现乘联会数据和券商研报数据不一致时，主动搜索第三方信源做交叉验证 4. 实时记忆：把中间结果写进自己的"任务进度文件"，而非依赖对话窗口 5. 输出对齐：根据"投资人视角"的指令，主动调整了术语密度和结论颗粒度
总耗时约 18 分钟。生成 23 页报告，附带 14 个数据源链接，每个关键数据后都有来源标注。
同样的任务，工作量从"人累 AI 闲"变成了"AI 累人闲"。 这个对比不是技术胜利，是角色重定义——AI 从"打字员"变成了"初级分析师"。
---
1.2 Copilot 范式的三大天花板
现在我们把 Copilot 为什么"不够用"做一次系统性的拆解。我把它归类为三个层次的天花板：技术天花板、角色天花板、架构天花板。这三层从下到上递进，最终决定了 Copilot 模式的极限。
1.2.1 技术天花板：上下文窗口与"软遗忘"
LLM 的上下文窗口（context window）虽然在过去两年从 4K 增长到了 200K 甚至百万级别（Gemini 1.5 Pro 在 2024 年宣称支持 100 万 token），但窗口大小不等于有效记忆。
我们在内部测试中观察到一条经验曲线：当对话轮次超过 6-8 轮，或者 token 总量超过窗口的 30%-40% 时，模型的"早期信息保持度"会显著下降。这个现象在不同模型上略有差异，但趋势一致。
原因有三：
- **注意力稀释（Attention Dilution）**：Transformer 的注意力机制是 O(n²) 的计算复杂度。当序列变长，每个 token 分配到的注意力权重被稀释。
- **位置编码偏差（Positional Encoding Bias）**：多数模型的 position embedding 对开头和结尾的信息保留度更高，中段容易丢失。
- **训练目标的短视性**：模型在预训练阶段主要看到的是单次回答任务，没有针对"长程任务状态管理"做专门优化。
更糟糕的是：用户感知不到这种遗忘。 模型不会说"对不起，我已经忘记第三轮的数据了"。它会基于不完整的上下文编造一个看起来一致的答案。这就是所谓的"软遗忘"——不是显式丢失，而是隐性失真。
GitHub Copilot Chat、Microsoft 365 Copilot、文心一言等主流 Copilot 产品都没有解决这个问题。它们的解决方案是把长对话切成多轮短对话，让用户感觉"每轮都是新的"——但实际上，问题从来不是"对话太长"，而是"任务需要的状态太多"。
1.2.2 角色天花板：主动性的零度
Copilot 的设计哲学有一个被广泛忽视但极其根本的预设：用户永远是规划者，AI 永远是被动响应者。
这个预设体现在产品设计的每一个细节上：
- 输入框是空的，等用户输入——AI 不会主动问"请问您接下来需要做什么？"
- 每次响应的长度被设计为"回答问题"，而不是"推进任务"
- 没有"任务进度"概念——AI 不知道一个项目由几个子任务组成、当前处于哪个阶段
- 反馈按钮（点赞/点踩）是设计来优化单次响应的，不是设计来优化长期目标的
这种设计哲学可以追溯到 1950 年代人机交互领域的"直接操控"（Direct Manipulation）传统——Shneiderman 在 1983 年提出的经典范式：用户操作对象，对象立即响应，过程可见、可逆。Word、Excel、Photoshop 都是这个范式的胜利。
但 Shneiderman 范式有一个隐含假设：用户对任务有完整的心智模型（mental model）。 用户知道自己要做什么、下一步做什么、做完意味着什么。
而 LLM 时代的新型任务——"帮我整理新能源车市报告"、"帮我分析竞品网站"、"帮我把这段 Python 代码重构并加上单元测试"——用户的心智模型往往是模糊的。用户知道自己要"一个报告"，但不知道怎么拆解；用户知道"代码要更好"，但不知道哪里不好。
Copilot 模式强制用户做自己不擅长的事：把模糊意图翻译成精确指令。 这就是为什么"Prompt 工程"在 2023-2024 年突然变成了显学——本质上，它暴露的是 Copilot 模式的能力短板。
相比之下，Agent 模式的设计哲学是反过来的：用户表达目标，AI 承担规划。 用户说"整理报告"，AI 自己决定要先做什么、要访问哪些数据、要如何验证。这就是范式转移的本质。
1.2.3 架构天花板：工具调用的"浅尝辄止"
2023 年起，几乎所有主流 LLM 都具备了 Function Calling（函数调用）能力——理论上，AI 可以调用搜索引擎、读写文件、执行代码、操作浏览器、查询数据库。
Copilot 产品虽然集成了这些能力，但用得非常"浅"。我们来看几个典型场景：
- **GitHub Copilot Chat**：可以"@workspace"让 AI 读取仓库代码，但只能读取单个文件，不能跨多个文件做语义检索；可以执行 Terminal 命令，但需要用户确认每一步；不能自主循环执行"读 → 改 → 测"的迭代。
- **Microsoft 365 Copilot**：可以在 Word/Excel/PowerPoint 之间跳转，但每个跳转都需要用户显式触发；它不会主动发现"Excel 里有一个错误数据，应该去 Word 里核对"这种跨文档关联。
- **文心一言 / Kimi / 智谱清言**：可以调用搜索插件，但调用一次就结束；不会根据搜索结果决定是否需要再搜一次；不会保存中间结果供后续步骤使用。
为什么 Copilot 不深挖工具调用？ 三个原因：
1. 安全顾虑：自主调用工具涉及"权限边界"问题。Copilot 模式的设计者本能地倾向于"少做少错"，把决策权留在用户手里。 2. 产品定位：Copilot 被定位为"辅助"而非"执行"，深度工具调用会让产品越过"辅助"的语义边界，威胁到既有 SaaS 产品的角色定位（试想 Excel 突然自己写公式修改数据，对微软来说是个微妙的商业问题）。 3. 技术债：深度工具调用需要可靠的"任务状态管理"基础设施——进度记录、错误恢复、上下文持久化。这些能力在 Copilot 模式下没有工程实现的优先级。
这三条加起来，决定了 Copilot 的工具调用能力注定是"演示级"的——发布会上很惊艳，日常用起来很鸡肋。
Agent 模式打破了这个天花板。 Agent 把工具调用作为"一等公民"：工具调用是默认行为，不是可选行为；错误恢复是内置能力，不是用户责任；状态持久化是基础设施，不是用户操作。
---
1.3 从 HCI 视角看"工具 vs 队友"
为了把"Copilot 到 Agent"的迁移讲得更透彻，我们回到人机交互（Human-Computer Interaction, HCI）的理论框架里，重新审视这个问题。
1.3.1 从直接操控到委托执行
过去 50 年的 HCI 演进史，大致可以分三个阶段：
| 阶段 | 时间 | 核心范式 | 代表系统 | 用户角色 | |------|------|----------|----------|----------| | 命令行 | 1960-1985 | 命令输入 | UNIX, DOS | 程序员 | | 图形界面 | 1985-2010 | 直接操控 | Mac OS, Windows | 操作者 | | 对话界面 | 2010-2020 | 自然语言 | Siri, Alexa | 提问者 | | 代理界面 | 2023- | 委托执行 | Cursor, Devin, Manus | 委托者 |
注意最后一行的变化：用户从"操作者"变成了"委托者"。这是 HCI 历史上第一次，用户不再直接控制系统，而是控制系统代表自己行动。
委托范式（Delegation Paradigm）对交互设计提出了全新要求：
1. 意图对齐（Intent Alignment）：用户用模糊的自然语言表达目标，系统需要还原出可执行的具体意图。 2. 进度可见（Progress Visibility）：用户看不到执行过程，但需要知道"现在走到哪一步了"。 3. 异常介入（Exception Intervention）：系统执行中遇到需要人类判断的问题，必须能优雅地把控制权交还给用户。 4. 结果验收（Outcome Acceptance）：用户需要快速判断最终结果是否符合预期，决定是否采纳。
这四点是 Copilot 模式几乎都没有认真解决的——因为 Copilot 是"对话范式"的产物，它假设每一轮交互都是独立的。Agent 模式则把整个委托过程视为一个完整的"任务会话"（task session），有开始、有中间、有结束、有验收。
1.3.2 Norman 的 7 个交互原则在 AI 时代的失效
Donald Norman 在 1988 年提出的 HCI 设计原则至今仍被奉为圭臬，包括：
1. Visibility（可见性） 2. Feedback（反馈） 3. Constraints（约束） 4. Mapping（映射） 5. Consistency（一致性） 6. Affordance（可供性） 7. Signifiers（符号性）
这些原则在"直接操控"时代几乎是完美的。但当 AI 介入后，出现了根本性的张力：
- **可见性与复杂度矛盾**：用户希望看到 AI 在做什么，但 AI 执行任务的细节往往是噪音（如 200 行 Bash 命令的逐行输出）。完全可见等于完全不可读。
- **反馈与延迟矛盾**：直接操控要求"立即反馈"，但 AI 执行复杂任务常常需要分钟级甚至小时级的时间。等待中没有反馈会让用户焦虑。
- **约束与自主性矛盾**：传统 HCI 用约束保护用户不犯错，但 AI Agent 需要自主空间才能完成任务。约束过强等于退化为 Copilot。
这意味着 AI 时代的 HCI 需要一套新的设计原则——不是否定 Norman，而是在他的基础上叠加一个"代理层"。我们会在第 12 章详细讨论这套原则。这里先按下不表。
1.3.3 "队友"隐喻的胜利与陷阱
2024 年起，几乎所有 AI 产品都开始使用"队友"、"伙伴"、"副驾驶"等隐喻来描述自己——Copilot（副驾驶）、Cursor（编辑器里的 AI pair programmer）、GitHub Copilot Workspace（协作空间）。
但这些隐喻大多数停留在营销层面，没有落到交互设计深处。真正的"队友"需要满足几个条件：
1. 共享目标（Shared Goals）：队友知道我们要一起达成什么，不只是当前被分配的任务。 2. 情境理解（Situational Awareness）：队友知道整个项目的上下文，不只是自己手头这块。 3. 主动提议（Proactive Initiative）：队友会主动说"我注意到这里有个潜在问题"，而不是只回答"你要我做什么"。 4. 能力诚实（Competence Honesty）：队友会说"这件事我做不了"或"我需要更多信息"，而不是硬撑。 5. 可被指导（Coachable）：队友接受反馈并能据此调整，不是教条的。
Copilot 模式满足了第 5 条，部分满足了第 1 条。后三条基本不满足。
Agent 模式必须把这五条都做到——否则就是"假装是队友的工具"。这也是为什么我们看到 Manus、Devin 这类产品在"自主性"上持续加码，但在"可控性"上小心翼翼。本质上是在拿自主性换取队友感，同时用工程手段保留可控性。
---
1.4 2023-2025 年代表性产品的范式迁移轨迹
理论讲完了，我们看一下真实的产业演化。这条迁移路径不是设计出来的，是被用户逼出来的。
1.4.1 GitHub Copilot（2021-2023）：内联补全的黄金时代
2021 年 10 月发布的 GitHub Copilot 是 Copilot 范式的奠基者。它的核心交互极其简单：在你写代码的过程中，按 Tab 键接受 AI 的内联补全建议。
这个产品的成功让很多人误以为"AI 写代码"的核心场景就是"自动补全"。事实上，Copilot 之所以能爆火，是因为它精准地嵌入了开发者最高频、最碎片化的工作流——你写一行的工夫，它给个建议，接受/拒绝都在 100 毫秒量级内完成。
但这个设计的边界也很快暴露：当用户尝试用 Copilot 做"完整功能开发"时，体验立刻崩塌。你不会用一个内联补全工具去"帮我开发一个登录页面"——这不是工具的错，是交互形态的错。