Anthropic 近期发布了一段内部对谈实录，三位负责 Claude Platform 的高管——Claude 管理式智能体产品经理杰西（Jess Yann）、Claude Platform 工程负责人凯特琳（Katelyn Lesse）、Claude Platform 产品负责人安吉拉（Angela Jiang）——围绕智能体技术的演进方向展开了深度对话。从半年前简单的 API 调用，到如今逐步形成一套独立、自主且具备协作能力的智能系统，AI 智能体正在从聊天工具演进为一种“看不见的操作系统”。以下是对谈的核心内容，聚焦智能体的身份认证、通信机制、协作策略、投资回报率以及未来发展趋势。

智能体基础设施的演进：从 API 到管理式智能体

半年前，Claude Platform 主要是一个具备推理能力、可获取 token 的 API，外加一些围绕模型的小工具，帮助用户提升能力、降低运营成本或加快响应速度。如今，平台已上线了更丰富的功能，能够帮助团队接管基础设施层面的复杂工程与脚手架工作，让团队以更低的成本将模型的智能真正应用于实际业务。

在客户反馈中，管理式智能体 是提及频率最高的主题，尤其是 记忆、结果与沙盒推演 这些核心概念。一位开发者的评价让团队印象深刻：“这套系统的抽象层次非常出色。”这句朴素的评价，反而让产品团队深受触动。

智能体的身份与权限：迈向独立身份体系

工作流在不断演化，但 智能体身份 这一概念始终贯穿其中。团队认为，未来智能体的身份可能会与具体工作流本身分离，智能体将拥有独立的身份标识。目前这一方向仍处于早期阶段，用户仍需对智能体给予较高的信任，但整体趋势正朝着这个方向演进。

具体流程可能是：智能体先充分理解用户想要达成的结果，再反向说明为完成该结果需要访问 A、B、C、D 等权限。用户可回应说 A、B、C 都可以，但 D 不行。智能体确认能否在允许范围内完成任务，如果可以，就为自己创建一个服务账号去执行，用户则可随时审计，确认其行为符合预期。

小提示： 在企业部署 AI 智能体时，建议提前规划好权限分级策略，避免因权限过宽或过窄影响智能体执行效率。

智能体之间的通信：API 与 MCP 服务器

智能体之间如何进行对话，是对谈的另一个重点。做法很直接：一个团队可以搭建一个智能体，再对外暴露一个 API 或某种接口，让其他智能体像人一样与它交互。已有团队在 Claude 管理式智能体的基础上，构建了一层轻量级的 MCP 服务器对外暴露，另一个智能体只需知道如何调用，就能与这个智能体进行通信。

这种方式非常实用，也让许多富有创意的想法变为了现实。

智能体协作策略：竞争、对抗与顾问模式

多个智能体协作时，通常不是采用单一策略，而是几种策略组合使用。

• 竞争策略： 让多个智能体互相竞争，共同解决同一个问题，这种机制已被直接内置进脚手架。
• 对抗策略： 同时启动两个智能体，一个负责提出想法，另一个专门唱反调。
• 顾问策略： 当模型自身无法想明白时，主动求助，联系一个更聪明的伙伴来帮忙决策。

类似这样的创新会越来越多。随着扩展式架构不断成熟，团队会逐渐将不同策略融合起来，例如先用类似最优选择的扩展式方法探索多种路径，确定最合适的框架后，再针对该框架进行持续迭代优化。

企业应用案例：从知识传承到端到端开发

制造业中的经验传承

团队提到一个令人印象深刻的黑客松获奖项目，名称大概叫 Urrea。在制造业工厂里，通常需要一位真正懂设备的专家，去监听和判断某些机器的运行状态是在变好还是变坏，还要查阅设备具体部件的说明书。传统做法是依靠一个人花十几二十年积累经验，一旦退休，经验也就跟着消失了。Urrea 项目将标准作业流程上传进系统，接入工厂各处的监测信号，让智能体模拟专家的判断方式，相当于用一套可持续积累工厂知识的智能体系统，补上了老师傅退休后留下的空缺。

开发团队的端到端进化

在开发团队一侧，也有类似的进化。以前大家用智能体主要是为了编写代码，Claude Code 在这方面已经做得相当出色。现在有团队开始往前再走一步，从项目最开始就考虑清楚整个流程需要做哪些事情，如何搭建开发环境去测试代码，如何在前期把需求文档和 PR 写清楚，后期又怎么完成 QA 测试。已有大公司搭建了完整的智能体系统和平台来支撑这种端到端的定制化开发，Shopify 分享过内部的做法，项目名为 River，类似的例子还有不少。

投资回报率的衡量：从个人到跨团队流程

企业该如何衡量智能体带来的投资回报率，是很多公司关心的问题。团队建议用更简单的思路来思考：不要一上来就想着把公司里一百二十个流程全部智能体化，那样太庞大、太难推进。

更合理的做法是分三步走：

• 第一步：个人层面 —— 先看某一个人的工作速度能提升多少。
• 第二步：团队层面 —— 如果这一个人能先跑起来，就可以从个人推广到团队，在团队层面继续观察速度的提升。
• 第三步：跨团队流程层面 —— 再从团队推广到跨团队的整体流程。

一个真实的业务流程往往牵涉很多团队和个人，大家的标准作业流程和专业背景都不一样，平时靠各种拼凑的方式才能凑到一起。按照这三步走，公司才能把自己真正关心的每一项指标都点亮，最终走到那一百二十个流程的清单上。从投资回报率的角度看，衡量的重点应首先放在 速度和生产力 上。

常见问题： 很多企业担心智能体投入成本过高，无法量化回报。实际上，从个人效率提升开始验证，风险最小，也最容易看到直接效果。

工程团队的变化：能力增强，但结构不变

工程团队会因此变成完全不同的样子吗？团队给出的答案是：工程团队的人员构成，其实和六个月前、十二个月前相比没有太大变化，还是需要理解系统、知道怎么运维、知道出问题后谁该值班的那批人。区别在于，每一个人现在都被智能体大大增强了完成工作的能力。

以前的团队结构可能是一位技术负责人对系统设计有整体判断，一群工程师负责领任务、把活干完。现在，几乎整个团队的每个人，都对如何端到端搭建一个产品或系统有自己的判断，也清楚技术方案该长什么样，然后再去指挥自己的 Claude 把具体工作完成。团队的样子看起来差不多，但能完成的工作量已经完全不是一个量级。

失败模式：虚假的超级独立感

依赖智能体也会带来一些失败模式，比较典型的是一种 虚假的超级独立感。因为现在人人都能自己动手搭建系统，一个人可以同时启动十个原型方案，让它们各自跑起来，最后挑跑得最好的那一个，而不需要像以前那样先认真思考挑哪个方向最合适。

这确实让每个人都获得了很强的独立性，但从更系统、更整体的角度看，把这些各自为战的产出重新协调到一起，反而变得更难。如果只是给每个人都放开手脚，却没有把大家往同一个方向去组织，就容易出现一种蔓延式的失控。这种局面有好也有坏，但确实是需要警惕的失败模式之一。

未来方向：从工具进化为操作系统

再往后看，智能体开发的方向会走向哪里。团队认为，未来会更深地嵌入到组织内部，深到甚至感觉不到自己在用某个具体的工具。

现在大家还习惯于为了某类任务去找某个智能体工具——这个工具擅长这个，那个工具擅长那个。未来更可能出现一种共同的基底，界面还是大家熟悉的界面，但用户只需要标记一下想要哪个智能体，随时启动、随时关闭，剩下的大量工作会在看不见的地方自己完成，甚至可能反过来主动找上用户。例如，提前发现某个服务出了问题，自己去排查、自己去修好，把对应的 PR 准备好等着用户回顾。如果用户告诉它类似的小事以后不用再来打扰，它下次就会直接处理并上线。

整体感觉更像是一层看不见的基底，用户在上面自然而然地工作。在这样的世界里，每个人都能搭建面向团队的智能体，它不完全是多了一个队友的感觉，而是某种团队协作方式本身长出了对应的智能体，能理解两个人各自的偏好。如果换成三个人的团队，它又能理解这三个人略有不同的偏好，把中间的空隙自动补上。界面和交互方式还会延续现在熟悉的样子，但整体感觉会更像一个 操作系统，而不是一个个需要主动去找的具体工具。

Claude Platform 的落地计划：结果导向

Claude Platform 接下来打算怎么把这套愿景落地？团队提到最近一直在推的一个重点概念是 结果。Claude 管理式智能体里已经上线了这个功能：用户告诉 Claude 什么样的结果算是好结果，给出一份评分标准，再设定允许它尝试多少次才停止。

随着这个概念继续演化，未来会越来越接近这样一种状态：用户直接告诉 Claude 自己想要什么结果，给出一个预算，然后就可以放手不管了。平台想做的事情，就是把这个过程变得足够简单，让用户每天都能随手启动一个智能体去处理具体任务。

例如，今天需要把面试记录整理成一份反馈材料，用户只需要说清楚希望这份笔记长什么样，愿意花多少成本，剩下的事情交给智能体去完成，最后拿到想要的结果。让用户不用再费力思考如何把这件事做出来，正是团队想要填上的那个空缺。

小提示： 在使用结果导向功能时，建议先在小任务上测试评分标准，确保智能体对“好结果”的理解与用户一致，再逐步推广到更复杂的任务。

结语

从这场对谈可以看出，AI 智能体技术正在从单纯的工具，逐渐演变为组织运作中不可见但不可或缺的基础设施。无论是身份独立、智能体间通信，还是多智能体协作策略，都在朝着更自主、更高效的方向发展。对于企业而言，从个人效率提升开始，逐步扩展到团队和跨团队流程，是衡量智能体投资回报率的务实路径。而未来的智能体，将更像一层看不见的操作系统，帮助人们更自然地完成工作，甚至主动发现问题并解决问题。