Anthropic刚刚放出了一段内部对谈主角是三位负责Claude Platform的高管Claude管理式智能体产品经理杰西Jess Yann、Claude Platform工程负责人凯特琳Katelyn Lesse、Claude Platform产品负责人安吉拉Angela Jiang。三人聊了聊过去半年里智能体基础设施到底发生了什么变化包括身份、权限、记忆、智能体之间怎么互相通信企业该怎么算智能体的投资回报率以及人和智能体组成的团队要怎么设计才能跟得上模型能力的进化速度。半年前Claude Platform基本上就是一个可以调用推理能力、拿到token的API外加一些围绕模型做的小工具帮用户获得更强的能力或者降低成本提升速度。而现在平台已经上线了很多更丰富的功能能帮团队把基础设施层面的麻烦和脚手架工程的麻烦都接过去让团队用更低的成本把模型的智能真正用起来。关于客户反馈大家提得最多的是管理式智能体这块尤其是记忆、结果和沙盒推演这些概念。有一个说法让团队印象很深一位开发者说自己特别喜欢这套系统的抽象层次这句朴素的评价反而让产品团队很受触动。工作流在不断演化但智能体身份这个概念一直都在。团队认为智能体的身份未来可能会和具体工作流本身分开智能体自己拥有一份独立身份。现在这个方向还比较早期大家还在摸索有意思的用法用户也还需要对智能体给出比较大的信任。但趋势正在往这个方向走智能体先听清楚用户想要的结果然后回过头来说明为了完成这个结果自己需要访问A、B、C、D这几项权限用户可以回应说A、B、C都可以但D不行。智能体确认能不能在这个范围内完成任务如果可以就相当于给自己开一个服务账号去执行用户则可以随时审计确认它做的事情符合预期。这大概率会是身份层未来演化的方向。智能体之间怎么对话也是这次谈话的一个重点。做法很直接一个团队可以搭建一个智能体再对外暴露一个API或者某种接口让别的智能体像人一样跟它交互。已经有团队在Claude管理式智能体的基础上搭了一层很薄的MCP服务器对外暴露另一个智能体只需要知道怎么调用就能和这个智能体对话非常好用也让很多有意思的创意变成了现实。这类工作流之所以能在最近成立核心原因是模型本身变强了。以前想做这类事情往往需要在模型外面搭一整套复杂的脚手架和标准作业流程来保证步骤A做完才能进入步骤B。模型的不确定性在过去是个大问题现在的模型已经能在合理的边界内自己判断要走哪些步骤做哪些事情。同时模型也能持续运行更长时间基础设施也已经支持让一个智能体常驻在某个工作空间里被某个事件触发后自己跑上一段时间的工作流等真正完成了再回来汇报。这既是模型的进化也是基础设施进化的结果。几个月前很多团队还在给业务流程搭非常复杂的判断框架第一步必须先过AA再判断能不能进入B条件层层嵌套整个系统非常脆弱智能体很难真正发挥出应有的智能用户原本是想让流程更自动化、更好用结果却把模型框得死死的。随着模型变得更聪明工具调用能力更强推理也更深团队已经开始把这些限制性很强的框架部件一点点拿掉脚手架整体正在变得越来越薄。脚手架变薄之后反而出现了一种元脚手架暂时还没有统一的叫法未来也许会被称作类似鞍具这样的东西。多个智能体协作时往往不是单一策略而是几种策略组合使用。比如让多个智能体互相竞争共同解决同一个问题这种机制已经被直接内置进了脚手架里。还有一种做法是同时启动两个智能体一个负责提出想法另一个专门唱反调。团队最近还尝试了一种顾问策略模型如果自己想不明白就主动求助联系一个更聪明的伙伴来帮忙拿主意。类似这样的创新会越来越多随着这种扩展式的架构不断成熟智能体能解决的问题只会越来越复杂。团队会逐渐把不同的组合策略融合起来比如先用类似最优选择的扩展式方法探索多种路径确定最合适的框架之后再针对这一个框架做持续迭代。说到复杂问题团队提到了一个印象很深的黑客松获奖项目名字大概叫Urrea。制造业工厂里通常需要一位真正懂机器的专家去监听和判断某些设备的运行状态是在变好还是变坏还要去查阅这台设备具体部件的说明书。传统做法是工厂里靠一个人花上十几二十年攒下这份经验这个人一旦退休这份经验也就跟着消失了。这个项目把标准作业流程上传进系统接入工厂各处的监测信号让智能体去模拟这位专家的判断方式相当于把老师傅退休后留下的空缺用一套可以持续积累工厂知识的智能体系统补上了。在开发团队这一侧也有类似的进化。以前大家用智能体主要是为了写代码Claude Code在这方面已经做得很好。现在有团队开始往前再走一步从项目最开始就考虑清楚整个流程需要做哪些事情怎么搭建开发环境去测试代码怎么在前期就把需求文档和PR写清楚后期又怎么完成QA测试。已经有大公司搭建了完整的智能体系统和平台来支撑这种端到端的定制化开发Shopify分享过自己内部的做法项目名字叫River类似的例子还有不少这也是模型能力演化带来的结果之一。不过并不是所有组织都能顺利吃到这波红利。眼下最大的阻力集中在安全合规和评估这两块。很多团队现在的安全假设还停留在二十年前的水平而智能体正在从根本上改变一切随之而来的安全问题也需要重新审视。团队本身对什么样的智能体算安全、需要什么样的护栏已经有了比较成熟的判断但把这套判断推广出去、把安全检查清单重新修订一遍仍然是一段持续的过程。评估同样是绕不开的一环只有把评估体系搭好才能真正把这项技术的价值发挥出来。企业该怎么衡量智能体带来的投资回报率也是很多公司眼下很关心的问题。团队的建议是用一个更简单的思路去想这件事不要一上来就想着把公司里一百二十个流程全部智能体化那样太庞大也太难推进。更合理的做法是从个人开始先看某一个人的工作速度能提升多少听起来好像不够复杂但如果真的能让这一个人先跑起来就可以从个人推广到团队在团队层面继续观察速度的提升再从团队推广到跨团队的整体流程。毕竟一个真实的业务流程往往牵涉很多团队和很多个人大家的标准作业流程和专业背景都不一样平时靠各种拼凑的方式才能凑到一起。按照个人、团队、跨团队流程这三步走公司才能把自己真正关心的每一项指标都点亮最终走到那一百二十个流程的清单上。从投资回报率的角度看衡量的重点应该首先放在速度和生产力上。那工程团队本身呢会因此变成完全不同的样子吗。团队给出的答案是工程团队里的人员构成其实和六个月前、十二个月前相比没有太大变化还是需要理解系统、知道怎么运维、知道出问题了谁该值班的那批人。区别在于每一个人现在都被智能体大大增强了完成工作的能力。以前的团队结构可能是一位技术负责人对系统设计有整体判断一群工程师负责领任务、把活干完。现在几乎整个团队的每个人都对如何端到端搭建一个产品或系统有自己的判断也清楚技术方案该长什么样然后再去指挥自己的Claude把具体工作完成。团队的样子看起来差不多但能完成的工作量已经完全不是一个量级。依赖智能体也会带来一些失败模式比较典型的是一种有点虚假的超级独立感。因为现在人人都能自己动手搭系统一个人可以同时启动十个原型方案让它们各自跑起来最后挑跑得最好的那一个而不需要像以前那样先认真思考挑哪个方向最合适。这确实让每个人都获得了很强的独立性但从更系统、更整体的角度看把这些各自为战的产出重新协调到一起反而变得更难如果只是给每个人都放开手脚却没有把大家往同一个方向去组织就容易出现一种蔓延式的失控这种局面有好也有坏但确实是需要警惕的失败模式之一。再往后看智能体开发的方向会走向哪里。团队认为未来会更深地嵌入到组织内部深到甚至感觉不到自己在用某个具体的工具。现在大家还习惯于为了某类任务去找某个智能体工具这个工具擅长这个那个工具擅长那个。未来更可能出现一种共同的基底界面还是大家熟悉的界面但用户只需要标记一下想要哪个智能体随时启动、随时关闭剩下的大量工作会在看不见的地方自己完成甚至可能反过来主动找上用户比如提前发现某个服务出了问题自己去排查、自己去修好把对应的PR准备好等着用户回顾如果用户告诉它类似的小事以后不用再来打扰它下次就会直接处理并上线。整体感觉更像是一层看不见的基底用户在上面自然而然地工作。在这样的世界里每个人都能搭建面向团队的智能体不完全是多了一个队友的感觉而是某种团队协作方式本身长出了对应的智能体能理解两个人各自的偏好如果换成三个人的团队它又能理解这三个人略有不同的偏好把中间的空隙自动补上。界面和交互方式还会延续现在熟悉的样子但整体感觉会更像一个操作系统而不是一个个需要主动去找的具体工具。Claude Platform接下来打算怎么把这套愿景落地。团队提到最近一直在推的一个重点概念是结果Claude管理式智能体里已经上线了这个功能用户告诉Claude什么样的结果算是好结果给出一份评分标准再设定允许它尝试多少次才停止。随着这个概念继续演化未来会越来越接近这样一种状态用户直接告诉Claude自己想要什么结果给出一个预算然后就可以放手不管了。平台想做的事情就是把这个过程变得足够简单让用户每天都能随手启动一个智能体去处理具体任务比如今天需要把面试记录整理成一份反馈材料用户只需要说清楚希望这份笔记长什么样愿意花多少成本剩下的事情交给智能体去完成最后拿到想要的结果。让用户不用再费力思考怎么把这件事做出来正是团队想要填上的那个空缺把这件事做得足够简单。