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