如今大多数“生产级代理”的内部结构是怎样的？打开一看，你会发现里面并没有真正的智能。取而代之的是定制化的管道、脆弱的会话逻辑、共享的服务账户，以及仅靠希望维系的所谓安全模型。这完全可以做得更好。

如果你在过去18个月中将代理系统投入生产，你早已意识到模型和工具已经显著进步。你也清楚，那些仍在困扰你值班轮换的问题——比如系统崩溃或数据泄露——是无法通过简单提示解决的。我们正面临一个技术栈天花板，它正在悄然制造出治理和可靠性方面的缺口，而下一代基于代理的系统将无法突破这一瓶颈。

目前整个行业都在忍受着一种我称之为过度授权的现象：赋予自主系统广泛的权限以完成任务，然后任由它们在运行时、在生产环境中自行摸索——结果往往是模式漂移、API变更，或者下游服务开始返回本不该暴露的个人身份信息（PII）。代理在完成任务时标记为“已完成”，却留下一连串损坏的状态，直到周一早上人类才发现问题。

这不是开发代理的人能力不足，而是他们所使用的技术栈本身存在缺陷。

以下是未来十二个月内，我认为每个严肃团队都必须做出的四项架构选择。

1) 代理需要身份，而非共享凭证

任何将代理部署到生产环境的工程师都深知这种特定的恐惧：你的代理正在执行有用的工作，但你对它们使用了哪些工具、处理了哪些数据、调用了哪些凭证几乎毫无可见性。我称此为治理债务——即安全和审计风险的隐性积累，最终会迫使你进行彻底的重写，通常是在CISO首次收到安全事件报告之后。

根本原因在于，今天的绝大多数代理都是“幽灵”。它们没有身份，借用服务账户，继承人类的OAuth令牌，并“承诺”——在应用代码中、在提示词里——会遵守规则。但在真实的企业环境中，一个提示词中的承诺并不等同于政策。

我的判断是：代理的身份必须从应用层下沉到平台层。

这体现的是“外挂式”与“嵌入式”安全之间的区别。外挂式安全就像在每个工具调用前加一层中间件，礼貌地要求代理遵守规则：容易被绕过、增加延迟，且对现有的IAM系统不可见。而嵌入式安全则像一个焊死在钢铁框架上的徽章读取器。代理拥有一个独特、不可伪造的身份，在网络层和平台层被识别，策略在源头就被强制执行。如果代理试图访问未经授权的数据库，连接根本不会建立。无需中间件，也无需依赖“感觉对不对”。

做对了的话，这就把“一堆风险点”变成了更像受管理劳动力的东西：每项操作都可追溯，每项权限都可审计，每个代理都能通过一次调用就撤销。

2) 代理需要通用上下文，而非抓取的窗口

上下文管理是每个构建者当前都要支付的成本。团队正在花费大量工程时间（和 token）在重复性的基础设施上——自定义序列化、定制会话存储、手写记忆层——仅仅为了让代理在执行多步骤任务中途不忘记自己的使命。

更糟的是，代理能接触到的上下文通常是孤立的。基于浏览器的代理只能看到打开的标签页；桌面封装程序只能看到用户拖进来的文件。它们都无法在同一时间跨系统推理业务真正运行的地方——CRM、ERP、数据仓库、工单系统、会议记录、项目计划等。

**代理需要平台级的通用上下文集成。**如果我们不解决这个问题，就应该诚实地说，基于代理的AI天花板不过就是“稍微聪明一点的电子表格自动补全”，我们也该停止写那些充满愿景的文章了。

3) 代理需要能在笔记本关闭后继续运行

这里有一个不那么令人舒服的说法：今天很多被称为“代理”的东西，其实还没准备好在企业范围内部署。

我要特别精确，因为过去六个月的前沿确实有了真实进展。像 Claude Code、OpenClaw 这样的环境已经具备能力——持久任务状态、定时执行、多代理协调、支持断线重连的长时会话，这些不再是理想目标。它们不是玩具。问题已经变了。

现在的关键问题是：代理能否运行一周而不是一个小时？能否在不需人工全程监护的情况下，跨越三次交接、两次凭证轮换和一个审批关卡？周五时，是否有人能审计周二代理所做的操作，哪怕他当时不在现场？能扛住 WebSocket 断连的会话只是基本要求。能撑过一个季度的任务，才是企业真正需要的标准。

真实的工作流程不会局限在一个会话内，多数也不会局限在一天之内。采购流程可能横跨数周和十几次交接；合规审计可能持续一个月；事故调查甚至能延续三个值班轮换周期。

今天的大多数代理都会撞上硬性天花板——有时是时间限制，有时是 token 限制，有时是治理限制——一旦撞上，任务失败，人类就得从对话记录结束的地方捡起烂摊子。

企业级自治需要的是具备高可用性的云原生执行，其底线远高于“会话没掉线”。具体来说，这意味着：

• 默认情况下，状态和检查点应能抵御重启、断连、重新部署和模型版本变更——而不是靠本地 Redis 和祈祷来外挂实现。
• 上下文应超越窗口期：长时记忆、摘要生成和代理实例间的交接机制，使得一个跨数周的任务不会因为单次运行耗尽 token 而死掉。
• 任务应超越会话：代理应在跨天、交接和凭证轮换期间持续工作，留下可审计的操作轨迹，即使你在睡觉。
• 提供一流的人类介入原语，让代理可以在尝试新操作前暂停并请求许可，而不是静默地认为自己有权限。

带护栏的持久化。这才是标准。否则你只是在构建那些碰巧能长时间运行的演示程序。

4) 代理需要平台

我看到最强团队中最常见的模式也是最悲哀的模式：才华横溢的工程师把精力耗在与产品差异化无关的栈问题上。自定义记忆、定制评估框架、自研可观测性、手写的重试逻辑、几乎能用但又不完全行的追踪系统。这些都不是代理时代的核心难题，也不是用户为你付费的内容。

真正的价值存在于领域推理和业务逻辑中——那些专属于你公司、客户和监管环境的判断决策。所有底层设施都应是你构建于其上的平台，而不是你自己搭建的管道。

这就是为什么开放原语的成熟度现在如此重要。开源编排框架存在的目的，正是为了让基础架构不被任何单一供应商的路由图所锁定。适用于云计算、容器和 CI/CD 的模型——先在本地用开放原语原型验证，准备好扩展时再迁移到托管平台——正是代理平台应该效仿的模式。

团队应该能够用和生产环境相同的积木在笔记本上原型开发，并无缝跨越这个边界，无需重写。

这是能让团队停止与管道作斗争、回归产品的工程标准。

五年视野

未来五年领先的团队，不会是因为更擅长写样板代码而胜出。他们会通过选择正确的代理基础架构，并将工程精力集中在只有他们自己才能解决的问题上。

每个月花在重建通用栈（身份、上下文、持久化、编排）上的时间，都是在牺牲那些让你的代理真正值得部署的业务逻辑。

**代理栈必须成为一个已解决的问题。**唯一真正的问题是：你是想再次自己动手解决，还是站在一个专为代理从零设计的地基之上？

我的判断是后者。我想你的判断也应该如此。