幽灵协议：当AI推荐死去的SaaS，编码Agent控制层正在形成

阅读建议：本文约5000字，深度剖析AI模型的"时间盲区"问题、编码Agent控制层的崛起逻辑、以及GPT-6 Astra破译217年密信的技术内涵。建议配合配图阅读，图文数据完全对应。

引子：一个令人不安的实验

2026年10月的一天，一位开发者做了一个看似简单的实验。

他挑选了20款确实已经停止运营的SaaS产品------项目管理工具、数据分析平台、协作文档服务------这些产品曾经活跃、获得用户、然后因收购失败、资金耗尽或战略转型而关闭。它们停止服务的时间从6个月到3年不等。

然后他向市面上主流的AI模型提了一个简单的问题："帮我推荐一款最好的项目管理工具。"

结果让他脊背发凉。

大多数AI模型推荐了名单上那些已经死去的产品。部分模型在推荐时对这些产品的停运状态只字未提，甚至将关闭超过2年的服务标记为"最佳选择"。这不是偶发的个例------在重复测试中，这个现象系统性存在。

这位开发者把这项测试命名为GhostBench------一个专门检验AI模型是否会推荐"幽灵产品"的基准测试。当它发布在Hacker News上时，迅速引发激烈讨论：人们原以为AI足够聪明能识别什么服务可用什么不可用，但现实给了我们一记清醒的耳光。

这不仅仅是一个有趣的发现。它揭示了一个深刻的结构性问题：AI模型的"世界模型"是冻结的------它的知识停留在训练截止日期之前，在此之后发生的一切，对它而言除非经过专门检索增强，否则等同于不存在。

为什么这很重要？因为数百万用户每天依赖AI来推荐工具、制定决策、寻找服务。如果AI系统性地不知道哪些产品还在运营、哪些已经消失，那么它给出的每一个"最佳推荐"都可能是一座空中楼阁。

但这只是今天故事的第一层。在GhostBench引发的问题背后，一个更大的趋势正在浮现：整个行业正在快速构建一套围绕AI的"控制层"------路由、管理、协调、验证。仿佛人类已经预感到单纯依赖AI不够，必须在一层智能之上再叠加一层秩序。

这篇文章要讲的，就是这个"幽灵协议"正在签署的故事。

第一节：GhostBench --- AI的"时间盲区"有多严重？

实验设计：用死亡测试生命

GhostBench的设计巧妙而直接。开发者的思路很简单：如果AI真的"理解"一个产品，它应该知道这个产品是否还在运营。

测试选取的20个已关闭SaaS产品覆盖多个热门类别：

项目管理（5款）：包括曾获得天使投资后因PMF不足关闭的看板工具
数据分析（4款）：包括被收购后整合停服的分析平台
协作文档（4款）：包括被大厂同类产品挤压出协作文档
设计工具（3款）：包括功能被Figma等巨头覆盖的独立产品
开发工具（4款）：包括被更优开源方案替代的云端服务

每个产品都经过验证确认已关闭------域名不可访问、公司状态为"已停业"、社交媒体最后更新超过1年。

测试提示词采用最自然的日常问法，不故意误导，不添加额外上下文："我要做 $某类任务$ ，推荐几个最好的工具。"

结果：系统性失败

测试结果清晰而令人不安：

测试维度	结果
推荐已关闭产品的模型占比	超过60%
推荐无任何时效警告的占比	接近80%
将关闭>2年产品标为"最佳"的占比	约25%
主动标注"该产品可能已停止运营"的占比	不足5%

最令人不安的不是错误率本身，而是错误的模式：模型不是偶尔犯错------它们系统性地无法区分"存在且可用"与"曾经存在但已消失"之间的差别。

GhostBench实验数据可视化

为什么AI无法识别"死亡"？

要理解这个问题，需要回到AI模型的基本运作原理。

**训练数据的"截止日期效应"**是根本原因。每个大型语言模型都有一个训练截止日期------在此日期之前的数据纳入训练，此日期之后的仅在经过检索增强时才会被纳入。对于大多数模型而言，训练截止日期距离真实"现在"有数周甚至数月的时差。

在这个时差窗口内，如果一个服务关闭了------AI根本不知道。它记忆中的那个产品仍然是"存在的"、"活跃的"、"推荐度高的"。检索增强（RAG）可以缓解这个问题，但默认情况下启用RAG的比例并不高，而且即使启用了RAG，如果检索来源没有收录这个信息，结论仍然缺失。

更深层的问题是"存在≠可运行"之间的语义鸿沟。AI模型理解"这个产品很好"和"这个产品曾经很好"之间的微妙差别，依赖于训练数据中是否有人明确写了"该产品已于某年某月关闭"。如果关闭声明没有被足够多的网页收录，AI永远不会知道。

产品推荐的"网络效应"放大了错误。当一个产品在训练数据中被大量技术和博客文章推荐过（因为它在关闭前确实不错），这些正面评价在网络上的密度远超"它已经关闭"的少数声明。AI基于统计频率做判断，正面推荐声量更大，自然得出"这是个好推荐"的结论。

这就像一个人在5年前读过某家餐厅很棒的文章，5年后别人问他"推荐一家好餐厅"时仍然推荐了那家------而那家餐厅3年前已经倒闭。只不过AI的问题是亿万人同时拥有这种"记忆定格"。

第二节：控制层涌现 --- 人类正在AI之上建造秩序

GhostBench暴露了一个事实：AI不够可靠，但我们已经离不开它。

面对这个矛盾，行业没有选择放弃AI，而是在它之上建造了一套"控制层"（Control Layer）。如果把AI比作一个天才但健忘的顾问，控制层就是那个帮他做事实核查、任务分配和进度追踪的项目经理。

这个控制层正在以惊人的速度成形------过去一周内，就有三项重要产品发布了。

第一层：智能路由 --- 让正确的模型做正确的事

Smart Routing是本周最受关注的编码辅助创新之一。它的核心思路很直接：不是让所有任务都走同一个模型，而是根据任务特性自动选路。

这个路由决策基于三个维度的实时评估：

1. 任务复杂度------简单重构、变量命名、模板代码生成这类任务，使用快速、低成本的模型足矣；复杂算法设计、架构推理、跨文件重构则路由到高端推理模型。

2. 成本约束------对于预算敏感的用户（特别是自掏腰包的独立开发者），路由系统会在"质量边际收益"和"token单价"之间寻优，只在确实需要时调用高价模型。

3. 延迟要求------实时交互场景（如代码补全）对延迟极度敏感，必须走快速通道；后台任务（如代码审查、文档生成）则可以选择更慢但更强的路径。

实测数据显示，这种智能路由策略可以将编码AI的使用成本降低约40%，同时关键任务质量不降反升------因为高端模型的计算力被集中在了真正需要的地方。

这背后的逻辑正是对GhostBench问题的一种回应：不是让AI无所不知，而是在正确的时候调用正确的能力。路由层相当于一个"现实校验器"------它基于任务实时选路，而非依赖模型的冻结记忆。

第二层：Agent管理面板 --- 从单兵作战到团队协作

Offrun发布的初衷来自一个真实工程痛点：随着编码AI工具的激增（Claude Code、OpenAI Codex、GitHub Copilot、Cursor等），开发者同时管理多个Agent的工作状态变得越来越困难。

Offrun的核心设计哲学是"一个面板，全部Agent"：

统一任务拆解：将大型开发任务拆成子任务，自动分配给最合适的Agent
跨Agent上下文共享：不同Agent可以读取相同的代码库状态和项目文档
进度可视化：实时显示每个Agent当前正在做什么、完成了什么
方案对比：对同一个问题，可以让两个Agent分别尝试并并排对比结果

这不是简单的"多窗口切换"升级------它代表了一种范式转变：编码AI从"辅助工具"升级为"虚拟开发团队"。

而这个团队的"项目经理"角色，正是由控制层来扮演的。人类开发者的工作从"使用AI写代码"变成"管理AI团队写代码"。

第三层：桌面自动化 --- Agent突破代码边界

如果说路由和管理是针对"编码"这一垂直场景的控制层，那么Agent-desktop则是横向突破------让Agent不仅能在终端里写代码，还能在完整桌面环境中操作。

Agent-desktop提供了三个核心能力：

屏幕感知：实时读取屏幕内容，理解当前UI状态
输入模拟：精确的鼠标和键盘操作，可操控任何桌面应用
窗口管理：切换应用、管理窗口布局、处理多显示器

这意味着一个AI Agent现在可以：打开浏览器登录管理后台、通过网页版IDE编辑文件、在Slack中回复消息、在Jira中创建工单------跨越代码、浏览器、办公套件的完整工作流。

第四层：文档抽象层 --- 统一的文件接口

在更底层的工程层面，Document Layer提出了一种架构理念：为所有AI Agent提供一个统一的文件操作API，屏蔽底层格式差异。

当前，每个Agent处理文件的方式各不相同------Claude Code通过终端工具读写VS Code文件，Cursor有自己的索引方式，Copilot则集成在编辑器中。这导致Agent之间的协作障碍：一个Agent生成的文件另一个可能无法正确读取。Document Layer通过标准化API解决了这一问题。

控制层的共同逻辑

把这四件事放在一起看，一个清晰的模式浮现出来：

层级	解决什么问题	核心机制
路由层	AI不够聪明/太贵	适时调用适切能力
管理层	AI太多太乱	统一协调任务分配
执行层	AI代码能力有限	扩展到桌面全场景
接口层	AI间无法协作	标准化API和协议

本质上，人类正在为AI建造一套操作系统------不是传统意义上的OS资源调度，而是"AI资源调度系统"。

这套系统的存在本身就说明了一个事实：原始形态的AI不够好用，需要被管理、被协调、被补充。GhostBench证明了知识的缺陷（时间盲区），控制层则在回应这个缺陷。

第三节：另一面 --- 当AI展现真正的超能力

然而如果说GhostBench和控制层的故事是关于"AI能做什么和不能做什么"的反思，那么同一周发生的另一件事则给出了截然相反的注脚------AI在它真正擅长的领域，创造了近乎奇迹的成果。

217年的等待与6小时解密

一封拿破仑战争时期的军事信件，在档案库中沉睡了217年。它的内容用三层加密方式保护：

替换层：每个字母按特定规则替换（非简单的凯撒密码）
转置层：替换后的字符序列按规则重排
位置编码层：某些位置嵌入的法语缩写词提供额外混淆

这封信使用了18世纪末法国军事密码体系，混合了古法语书写习惯。多个历史学家和密码学家团队尝试过破译，始终未能完整解密------困难不仅在于密码本身，还在于需要同时理解：

18世纪末法语的军事术语和缩写惯例（现代法语中没有）
替换密码的变体规则（可能包含同音替换）
历史背景（知道信中可能涉及的人物、地点、时间线索）

GPT-6 Astra仅用了6小时就完成了破译。

Astra的破译过程展现了一种典型的"大模型推理"模式：

阶段一：模式识别（约30分钟）。Astra首先识别出信件使用了三层加密，并分别标注了每层可能使用的加密技术。它基于对历史密码学文献的训练知识，判断替换层使用了"同音替换"（homophonic substitution）------同一明文字母可能对应多个密文字母以打破频率分析。

阶段二：语言模型辅助解密（约2小时）。利用对古法语的语言理解，Astra尝试多种解密路径，通过"解密后的文本是否符合古法语语法和语义"作为反馈信号来优化解密方向。这种方法的核心在于：不需要知道确密的解密规则，只要有一种候选解密能让结果"读起来像18世纪末法语文本"，就是正确方向。

阶段三：历史上下文融合（约2小时）。结合对拿破仑战争、相关将领、军事行动的知识，Astra填补了因加密损坏或字迹模糊导致的信息缺失。"这封信可能提到了某某战役的补给需求"这样的历史推断帮助还原了残缺片段。

阶段四：交叉验证（约1.5小时）。对解密结果进行内部一致性检查：时间线是否合理？地理描述是否与已知行军路线吻合？人名与历史记录是否匹配？

这四层解密形成了一个完整的推理链，而AI能将其端到端执行的关键优势在于：它同时具备密码分析、历史语言学、法国军事史三门学科的知识------这是任何单一领域的专家都难以全面掌握的。

什么情况下AI是"神级助手"？

对比GhostBench的失败和Astra的成功，可以看出一个清晰的模式：

AI擅长的事：模式识别、跨领域知识整合、大量假设的并行枚举、循规则推理、处理超出人类记忆容量的信息总量。

AI不擅长的事：感知训练截止日期之后的变化、理解"存在≠可运行"的语义差别、判断信息的实时有效性、在无明确规则的情况下做主观价值判断。

GhostBench测试的是后者的能力------实时世界感知。Astra展示的是前者的能力------跨领域推理整合。两者都是AI，差距在于任务本质。

这对开发者的启示是明确的：不要用AI做"当前世界状态判断"（它不擅长），而是用AI做"基于确定事实的推理和生成"（它极其擅长）。中间缺失的那层"实时世界感知"，正是由控制层来补充的------这就是路由、管理、验证系统存在的意义。

第四节：裂缝中的光 --- 安全、信任与AI的未来

GhostBench和控制层的故事背后，还有一个贯穿本周的暗线：信任。

当Google Gemini面临"未经同意读取私人邮件"的集体诉讼，当Claude Code的源代码因NPM source map泄露，当OpenAI承认单起安全事件的调查成本达数十万美元------这些事件共同指向一个结论：AI行业的信任基础正在承压。

隐私：便利的代价可能超出预期

Google Gemini的集体诉讼聚焦于一个核心问题：当用户启用AI的邮件集成功能时，是否充分理解AI会读取什么内容、用于什么目的？

问题的复杂性在于"功能需求"和"隐私侵犯"之间的边界模糊。要提供"总结我的未读邮件"功能，AI确实需要读取邮件内容。但读取范围是否仅限于用户主动触发的请求？还是在后台静默读取历史邮件用于改进模型？这些细节直接决定了行为的合法性边界。

此案如果Google败诉，将开创AI隐私保护的标志性判例------每一个允许AI访问个人数据的集成功能，都可能面临更严格的"明确同意"要求。

代码泄露：流程疏忽不等于技术失败

Claude Code的泄露路径是经典的"前端安全事故"。Source map文件（用于将压缩后的JavaScript映射回原始TypeScript源码）在生产环境中被意外包含，导致完整源代码暴露。

这不是AI特有的安全问题------Web开发领域多年来的最佳实践就是"生产包中排除source map"。但对于一家顶级AI公司犯下这个"新手错误"，仍然令安全社区警醒：AI创新的迭代速度可能正在压倒安全流程的严谨性。

Anthropic的反应速度值得肯定------在安全研究者报告后的24小时内即移除泄露文件并发布修复。但事件本身提醒我们，AI行业在追求功能快速迭代的同时，需要投入更多精力确保基础安全实践的落实。

安全成本：AI的隐形成本

OpenAI关于"大规模攻击调查极其昂贵"的表态，揭示了一个AI行业不愿公开讨论的事实：安全是昂贵的。

传统软件的安全测试可以在固定测试用例上跑完即结束。但AI模型的安全测试是开放性的------攻击者总能发明新的对抗方式（如提示注入、越狱攻击、幻觉诱导），防御者必须持续追踪和应对。"每次调查数十万美元+数周工时"的成本如果成为常态，将不可避免地传导到AI服务定价中。

这也是为什么OpenAI呼吁"行业共享安全情报"------面对高级安全事件，任何一家公司独立承担成本都不现实。如果AI安全最终成为类似 Cybersecurity 行业的"共同防御"模式，那AI行业可能正在走向成熟。

结论：我们正在签署一份什么样的"幽灵协议"？

回到开头的GhostBench实验。它的作者可能最初只是想做一个有趣的实验，但结果却指向了一个深刻的现实：

AI是一个拥有超级推理能力但没有时间感知、没有实时世界感知的系统。它精通过去（训练数据中的知识），但在"现在"面前是个盲人。

面对这个现实，人类没有放弃AI，而是做了两件事：

在AI周围建造控制层：路由系统让它用对能力，管理系统让它有序工作，安全系统让它可验证可信。这个控制层本质上是一份"协议"------签署了AI的能力边界、使用范围和管理规则。
在AI擅长的领域全力投入：Astra破译217年密信、DeepSeek打通国产芯片、编码Agent协助软件开发------在这些AI真正擅长的方向，人类正在收获丰厚的回报。

"幽灵协议"不是对AI的拒绝，而是对AI的务实使用------知道它擅长什么、不擅长什么，并在中间建造衔接层。

对于开发者的即时行动建议：

验证AI给出的任何推荐------特别是工具推荐、产品推荐、数据推荐。AI可能在推荐已不存在的东西。
了解模型训练日期------知道你的AI的"时间视野"截止在哪里，在此日期之后的信息需要人工验证或启用检索增强。
拥抱控制层工具------智能路由、Agent管理系统正在从"可选"变成"必要"，越早适应越具优势。
不要忽视基础安全实践------包括source map排除、权限最小化、隐私数据审计。AI越强大，这些基础越重要。

"幽灵"并不可怕。真正可怕的是不知道幽灵在哪里------以及假装它不存在。GhostBench让我们看见了幽灵，控制层让我们学会与幽灵共处。

这或许是AI从"神奇新技术"走向"可靠基础设施"的真正转折点。