Claude Platform 从 API 走向代理基础设施
Anthropic 于 7 月 12 日发布的一段视频中，Claude Platform 工程主管 Katelyn Lesse 与产品主管 Angela Jiang 讨论了该平台过去 6 个月的代理化演变。两人给出的核心信息是，Claude Platform 已从单纯提供推理与 token 的 API，转为包含记忆（memory）、成果导向（outcomes）、dreaming，以及多代理协作能力的完整代理基础设施。
两位主管结合 Managed Agents 产品线的实务反馈，谈到代理身份、代理之间的沟通方式，以及 harness 的演化，并公开了两个客户案例。
Managed Agents：memory、outcomes 与 dreaming
Angela Jiang 表示，Managed Agents 上线后，获得最多正面反馈的三个概念是 memory、outcomes 和 dreaming。开发者在实务中的评价，集中在“抽象层次的清晰度”：即便 workflow 持续演化，代理本身仍保有清楚的识别与边界。
Katelyn Lesse 则谈到她对代理身份的看法。她认为，未来代理应拥有独立于用户的身份。用户先给代理一个目标 outcome，代理再反问，为完成这件事需要 A、B、C、D 哪些权限；用户可以授权 A、B、C，但拒绝 D，之后代理再为自己建立一个 service account 来执行任务。按她的描述，这种模型让代理行为更容易审计，也更可控。
在代理之间的沟通上，两人提到可以通过 API 或轻量的 MCP server 进行，“就像人与代理互动一样”。
Harness 变薄，meta 策略开始出现
Angela Jiang 说，过去几个月，开发者对 harness，也就是代理外部骨架的设计思路，已经出现明显变化。较早期的做法，往往需要复杂的业务流程盒子，例如“步骤 A 通过后才能进入步骤 B”的僵化框架。随着模型本身更聪明，tool calling 和推理能力更深，harness 开始变薄，开发者也能删去不少过去专门为模型设置的保护栏。
替代这类厚重框架的，是她所称的“meta harness”，也就是组合多种代理策略。实际做法已经包括：多个代理竞争解决同一个问题、对抗式代理模式——一个负责提出方案，另一个负责攻击方案，以及 Advisor 策略——当代理本身不会解时，直接调用另一个更聪明的代理协助。
Lesse 补充，未来可能会走向混合策略，先以 expansive 方式做探索，选定框架后再进入收敛与迭代。
两个案例：Urrea 工厂与 Shopify River
Jiang 分享的一个案例来自黑客松赢家 Urrea。她说，工厂里有一位在场域中累积 10-20 年经验、熟悉机台细节的专家，一旦退休，这部分关键经验也会随之流失。Urrea 团队把 SOP、机台监控信号和零件手册等资料上传到代理系统，让代理模拟这位专家的判断。Jiang 将这个案例的意义描述为：为“随退休而流失的专家知识”建立备援机制。
Lesse 提到的案例，则是 Shopify 内部的 River 系统。她说，这套系统不只是写程序，而是覆盖从 PR 撰写、需求文档、开发环境设置、程序编写，到后续 QA 验证的端到端开发代理系统。
在她看来，这反映出工程团队的基本样貌没有出现很大变化，但每位工程师都被代理“turbocharged”。团队逐渐转向由每个人去 orchestrate 自己的多个 Claude，而不是传统的“lead + 捡票”结构。
Anthropic 描述的下一步方向
谈到未来，Lesse 给出的理想状态是，用户只要对 Claude 说“我要这个 outcome、预算是这么多、开跑”，剩下的事情交给代理自行处理。她将这个方向定义为 Claude Platform 产品线正在补上的关键缺口——让开发者“不用更努力、也不用想更多”，就能生成自己想要的东西。