Anthropic 眼中的智能体基础设施将如何变化

Jess Yann 说，Claude Platform 已不再只是提供模型推理的 API，而是增加了帮团队承担部分基础设施和智能体框架工作的功能。被问及客户反馈时，Angela Jiang 提到托管智能体的记忆、结果评估和“做梦”等功能，以及提供给开发者的抽象层级。

Jiang 说，智能体身份和权限仍在演变。她设想智能体接收预期结果后，申请访问所需资源，只在用户批准的范围内继续执行。可审计的服务身份则可能让人检查智能体是否在做预期工作。她将其描述为一种可能的未来运行模式，而非已经完成的设计。

Katelyn Lesse 说，一个智能体可以开放 API 或其他接口，让第二个智能体与之交互。她见过团队围绕智能体构建精简的 MCP 服务器，让另一个智能体调用它。这些接口使能力组合成为可能，不必让每个智能体自行完成所有任务。

Lesse 认为，这类工作流能够实现，部分原因是模型变得更好。过去开发者需要更多支架和固定流程，才能让不可预测的行为保持在正轨。她说，较新的模型能在合理约束内确定步骤；改进后的基础设施也让智能体能够运行更长时间、响应工作空间中的事件，并在工作完成后返回。

Jiang 说，早期智能体系统经常将复杂业务流程编码成僵硬的顺序：只有满足特定条件，步骤 A 才能进入 B。这种结构可能很脆弱，也会限制模型的能力。随着模型的推理和工具使用能力提高，她预计开发者会移除一些限制性规则，让模型周围的框架更加精简。

这并不意味着放弃所有结构。Jiang 描述了更高层次的策略：多个智能体尝试解决同一个问题，一个智能体挑战另一个的方案，或者遇到困难的智能体向能力更强的顾问求助。Yann 建议组合这些方法，例如从多个尝试中选择一个，再围绕选中的方案迭代。

Jiang 回忆起一个面向制造设施的黑客松项目：机器维护可能依赖一位专家几十年的经验。构建者结合操作流程、设备监控和工厂信号，让智能体尝试近似部分人工判断。在她的描述中，这套系统提供了一种方式，在经验丰富的员工退休后保留并复用知识。

Lesse 看到开发团队将智能体用于编写代码之外的工作。他们开始考虑整个项目：定义需求、运行开发环境、测试生成的代码以及进行质量保证。她提到 Shopify 名为 River 的系统，将其作为更定制化的端到端开发工作流的例子之一。

被问及为什么不是所有组织都看到同样的收益时，Lesse 提到了安全和合规保障，以及评估智能体的能力。Jiang 同意，团队必须重新审视基于旧工作方式建立的安全假设和检查清单。组织需要确信智能体在适当边界内运行。

衡量投资回报时，Jiang 建议不要一开始就列出全公司要自动化的流程。先问个人的工作速度提高了多少，再看团队生产力。她建议，只有在此之后，组织才着手处理跨越多个团队、涉及不同专业知识和操作流程的工作。

Jiang 说，速度和生产力可以作为早期指标；随着采用推进，公司可以加入与所关注结果相关的财务和用户指标。这种分阶段的方法旨在观察个人工作如何连接到团队和公司工作流，以及价值在哪里出现。

Lesse 说，她的工程团队仍需要理解所构建系统、知道如何运行它们并能在出问题时响应的人。变化在于这些人的工作方式：不再只是由一位技术负责人指导一群领取工单的人，更多工程师可以参与端到端设计，并协调智能体执行工作。

Jiang 看到这种新独立性可能带来的失败模式。创建原型的成本低时，一个人可以不事先选定方案，而是构建十个选项。这可能有用，但如果缺少共同方向，结果可能是工作分散，让人更难将各部分协调成连贯的系统。

展望未来，Jiang 设想智能体嵌入组织熟悉的界面，而不是成为人们刻意打开的一组独立工具。智能体可能发现问题、展开调查，并提交建议的代码变更供人审查。在获得适当权限后，用户也可能允许它处理小型重复修复，而不必每次询问。

在这一设想中，两个人共同使用的工作流可以有一个理解双方偏好的智能体；另一个团队的智能体则可以反映不同偏好。Jiang 将形成的公共层比作操作系统：它填补团队工作流中的空缺，同时保留熟悉的界面。

Lesse 将平台的结果评估功能视为朝这一方向迈出的一步：人们在评分标准中指定什么是好的结果，以及智能体可以尝试多少次。她设想未来人们只需给智能体一个结果和预算，例如总结面试笔记并准备反馈，就能让它朝目标工作，而不必管理每个步骤。