智能体堆栈的赌注

以下文章最初发表在《Elevate》通讯上，经作者许可在此转载。

揭开当今大多数“生产级智能体”的引擎盖，你看到的并非智能。相反，你会发现定制的管道、脆弱的会话逻辑、共享的服务账户，以及一个靠希望维系的安防模型。这一切本可以变得更好。

如果你在过去18个月里将智能体投入生产，你早已知道模型和工具已经取得了显著进步。你也知道，那些仍在折磨你值班团队的难题，并非靠提示就能解决。我们正面临一个堆栈天花板，它悄然制造了一个治理和可靠性鸿沟，下一代智能体系统无法跨越。

目前，行业处于我称之为“过度授权”的状态：自主系统被授予广泛权限去完成任务，然后任其在运行时和在生产环境中发现——模式漂移、API变更，或下游服务开始返回不应泄露的个人身份信息。智能体标记任务为“完成”，却留下一串损坏的状态。人类在周一才发现问题。

这不是构建智能体的人们的失败，而是他们所构建的堆栈的失败。

以下是每个严谨团队在未来12个月内必须做出的四个架构选择。

1. 智能体需要身份，而非共享凭证

每个将智能体投入生产环境的工程师都熟悉这种特殊的恐惧：你拥有执行有用工作的智能体，却几乎无法看到它们接触了哪些工具、移动了哪些数据，或使用了哪些凭证。我称之为治理债务——安全与审计风险的无声积累，最终迫使全面重写，通常发生在第一个事件升级到首席信息安全官之后。

根本原因是当今大多数智能体都是幽灵。它们没有身份。它们借用服务账户、继承人类的OAuth令牌，并在应用代码和提示中“承诺”遵守规则。在真实的企业环境中，提示中的承诺并非策略。

我的赌注是，智能体身份必须从应用层下移到平台层。

区别在于附加式安全与嵌入式安全。附加式安全看起来像每个工具调用前的中间件，礼貌地要求智能体守规矩：易于绕过，延迟成本高，且对你现有的身份与访问管理来说不可见。嵌入式安全则像焊在钢架上的读卡器。智能体有一个独特、不可伪造的身份，在网络和平台级别得到识别，并在源头执行策略。如果智能体尝试访问未授权的数据库，连接永远不会打开。没有中间件，没有模糊地带。

正确实施后，这将把“一支由负债组成的舰队”转变为更像管理劳动力的东西：每个动作可归因，每个权限可审计，每个智能体可通过一次调用撤销。

2. 智能体需要通用上下文，而非刮取的窗口

上下文管理是每个构建者正在支付的税。团队正在耗费大量工时（和令牌）在无差异的管道上——自定义序列化、定制会话存储、手工记忆层——仅仅为了让智能体在执行多步骤任务时不忘目标。

更糟的是，智能体能获取的上下文通常是孤立的。基于浏览器的智能体只能看到当前标签页；桌面封装器只能看到用户拖入的文件。两者都无法轻易地同时跨系统推理——这些系统是业务真正所在的地方：客户关系管理、企业资源计划、数据仓库、工单系统、转录、项目计划。

智能体需要在平台级别整合的通用上下文。如果我们不解决这个问题，我们应该诚实地承认，智能体AI的天花板不过是“稍微好一点的电子表格自动完成”，我们应该停止撰写关于它的愿景文章。

3. 智能体需要能够承受笔记本电脑合上

这里是不太舒服的版本：当今许多作为“智能体”发布的东西，实际上还未准备好跨企业部署。

我想精确一些，因为过去六个月前沿确实取得了进展。像Claude Code、OpenClaw和类似平台的环境是强大的——持久任务状态、定时执行、多智能体协调、以及能够在断连后生存的长时间会话不再是幻想。这些不是玩具。问题已经向前推进了。

现在的问题是，智能体能否持续运行一周而非一小时？能否跨三次交接、两次凭证轮换和一个审批关口，而无需人类监视会话？它在星期二完成的工作能否在星期五被当时不在场的人审计？一个能经受住WebSocket断开的会话只是基本要求。而能经受住一个季度的任务才是企业真正需要的门槛。

真正的工作不适用于会话，且大部分工作也不适用于一天之内。采购工作流程跨越数周和十几次交接；合规审计持续一个月；事件调查超过三个值班轮次。

当今大多数智能体面临硬性天花板——有时基于时间，有时基于令牌，有时基于治理——当它们触及时，任务失败，人类从脚本结束处收拾残局。

企业级自主性需要持久的、云原生的执行，其基准远高于“会话保持连接”。具体来说，这意味着：

• 状态和检查点默认能在重启、断连、重新部署和模型版本变更后幸存——而非依靠本地Redis和祈祷作为附加。
• 上下文超越窗口：长期记忆、摘要、智能体实例间的交接，使得持续数周的任务不会因为单次运行耗尽令牌而死亡。
• 任务超越会话：能够跨越数天、交接和凭证轮换持续工作的智能体，并留下在你睡觉时发生事情的可审计轨迹。
• 一流的人机协作原语：智能体能暂停并请求权限执行新操作，而非默默自认为有权限。
• 带护栏的持久性。这才是门槛。达不到这点，你只是在构建碰巧运行很久的演示。

4. 智能体需要平台

我在最优秀的团队中常见到的最可悲的模式是：才华横溢的工程师将带宽消耗在堆栈问题上，而这些并不使他们的产品差异化。自定义记忆、自制评估框架、自建可观测性、手写重试逻辑、几乎能用的追踪系统。这些都不是智能体时代的难点，也不是用户付费给你的原因。

真正的价值在于领域推理和业务逻辑——那些对你的公司、你的客户、你的监管环境特有的判断。所有底层应该是你构建其上的平台，而不是你需要构建的管道。

这就是为什么开源原语成熟现在如此重要。开源编排框架的存在，正是为了不让脚手架被任何单一供应商的路线图锁定。适用于云计算、容器和持续集成/持续交付的模式——从开源原语本地开始，准备好扩展时升级到托管平台——正是智能体平台需要复制的模式。

团队应该能够在笔记本电脑上使用与生产环境相同的构建块进行原型设计，并在无需重写的情况下跨越边界。

这才是让团队停止与管道斗争，回归到产品上的工程标准。

五年展望

在未来五年中领先的团队，并非靠更聪明地编写样板代码脱颖而出。他们通过选择合适的智能体基础，并将其工程工时投入到只有他们能解决的问题上而领先。

每个月花在重建通用堆栈（身份、上下文、持久化、编排）上的时间，都是没有花在真正让你的智能体值得部署的逻辑上的时间。

智能体堆栈必须成为一个已解决的问题。唯一真正的问题是，你是想再次自己解决它，还是构建在一个从头就为智能体设计的平台上。

我的赌注是后者。我认为你也应该这样。