Anthropic负责人：AI Agent 正在重写企业工作流丨Every
Anthropic负责人：AI Agent 正在重写企业工作流丨Every
Anthropic负责人：AI Agent 正在重写企业工作流丨Every Anthropic负责人：AI Agent 正在重写企业工作流丨Every Modified May 10 🔗 原文链接： https://mp.weixin.qq.com/s/ebKFqPYW... 原创 Capihom Capihom 晚点再听LaterCast2026年5月9日 20:45 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "平台最终会是一组原语和基础设施，让你用最少的工作最快拿到结果。" "如果你把 Agent 做进产品，并且真的跑到规模上，基础设施会越来越难。" "最后可能只剩两个参数：结果和预算。" Every 这次请到 Anthropic Claude 平台负责人 Angela 和工程负责人 Caitlin。两人负责的对象已经超出聊天入口，延伸到 Claude 背后的开发者平台：Messages API、code execution、web search、managed agents、memory、skills、vaults。主持人 Dan Shipper 一上来就问得很实在：GPT 3 时代，平台只是补全端点；今天，Claude managed agents 更像一台带文件系统、记忆和工具的云端电脑。工程师、产品负责人和创业团队读这场对话，可以看到下一层抽象会落在哪里，以及今天自己搭 Agent 时哪些基础设施不该重复造。 API 从补全端点走到云端电脑 Angela 回顾 Claude 平台的演进时，把线索放在一个词上：stateful。早期开发者把 prompt 发进 API，拿回一个 completion；后来有了 chat session、tool calling；再往后，客户开始追问怎么接工具、怎么跑 loop、怎么让 Agent 自主完成一段工作。 平台的任务从“吐 token”变成“让结果稳定发生”。 Managed agents 把 Messages API、内置工具、sandbox、web search 等能力包进同一套 harness，开发者可以直接在更高层上搭东西。 "随着 Claude 变得更自主，我们发现平台需要走向更高阶的抽象，只为帮你拿到更好的结果。" 她举的原语很具体：Messages API 仍在底层，但开发者现在可以直接用 code execution，拉起 sandbox 执行任务，也可以用 web search 补外部信息。平台团队把这些能力放进一套运行架构里，目标是让开发者少消耗在调度、状态和工具组合的反复试错上。 当客户问“怎么把 Claude 用好”，答案已经进入平台设计，而不只停在模型参数上。 Mac mini 脚本暴露了规模边界 Dan 提到 Every 内部也在做 Agent：几台 Mac mini 上跑着 Claude loop，一个上千行 Python 文件负责调度，能用文件系统和浏览器。很多团队今天也处在这个阶段，先把可用性跑出来，再考虑平台化。Caitlin 的回答很直接：Anthropic 自己也重复搭过这类基础设施，搭到足够多次后，团队决定把它做成可复用的平台。 个人试验可以放在一台机器上，产品级 Agent 要处理长任务、状态、隔离、权限和失败恢复。 "如果你把 Agent 做进产品，并且真的跑到规模上，基础设施会越来越难。" 几台机器上的 loop 很适合验证想法，进入产品后就会遇到完全不同的账本：同一时间有多少 Agent 在跑，失败后怎么重试，用户凭证放在哪里，长任务中间的上下文如何保留，任务结束后怎么把结果交回产品。Anthropic 做 managed agents 的动机，来自自家产品团队多次重复搭建这些设施后的疲劳。 平台化的目的很朴素：把重复的云端运行成本摊薄。 文件系统和 skills 成了 Claude 的工作手势 Anthropic 在 managed agents 上没有追求完全中立。Angela 说得很清楚，平台会在一些地方保持 opinionated：让 Claude 使用文件系统，鼓励使用 skills，把这些原语和模型的工作方式绑得更紧。她承认，这些选择像小注脚，时间拉长后会影响模型擅长什么、产品怎么搭。 Agent 工程不再只是 prompt 技巧，文件、工具、技能、运行环境都会进入模型行为的训练场。 "使用文件系统，使用 skills。它们很基础，但我们希望 Claude 从这些原语出发。" Dan 追问这种路径依赖会不会把模型带进固定赛道。Angela 的回答很谨慎：Anthropic 不能保证每个选择都永远正确，但会认真挑选哪些能力更“原生”地给模型。文件系统看似只是交互方式，后面会影响模型怎么读项目、怎么修改文件、怎么留下中间结果。Skills 也是同一类东西，它把组织经验做成可调用的能力，让 Claude 在任务中复用。 通用模型切换开始让位于成套 Agent Dan 提出团队最常见的顾虑：如果用了 Claude managed agents，会不会失去把模型切到 GPT、Gemini 或下一代模型的自由？Angela 没有回避。几个月前，很多团队还在搭很通用的 harness，底层模型热插拔。她观察到，下一代模型正在走向不同训练路线和工具偏好。 为了榨出模型能力，harness 和模型会变成一组交付单元，而不是随便拆开的零件。 冗余和多模型仍会存在，但切换层级可能从“换底层模型”上移到“换一整套 Agent”。 "你仍然需要冗余，也可能在某些事情上用别的模型，但更可能是在 Agent 这一层切换。" 她提到一个内部实验：团队为 memory 试过多套 harness，评估结果差异非常大。看起来只是“怎么请求、怎么保存、怎么让模型用工具”的细节，最后会变成输出质量的差距。Cursor 这类产品是否为不同模型做不同 harness，Angela 没有直接判断，但她观察到外部团队也在往类似方向走。 未来的竞争很可能发生在 Agent 配方层：模型、工具、记忆和执行环境怎么绑在一起。 这会改变团队的技术决策顺序。过去先问“底层选哪个模型”，然后再套一层统一接口；现在可能先定义用户要什么结果，再选择哪一套 Agent 能更稳定交付。模型锁定的焦虑不会消失，但它会被交付质量、评估结果和迁移成本重新排序。工程负责人要管理的，已经不只是 provider 列表。 内置 Agent 先从团队流程落地 谁最适合先用 managed agents？Caitlin 给了两个场景。一个是公司内部自动化，比如完整的软件开发平台，或者一个小流程：市场文案需要法务先审。另一个是把 Agent 做进面向客户的产品。两类场景共同的痛点都很工程化：团队不想每次重新实现 memory、运行 loop、权限、部署和协作界面。 平台先解决重复的底层劳动，让业务团队把精力放在流程本身。 "你不应该每次做内部自动化时，都重新实现 memory 和这些底层东西。" Caitlin 还补了一种角色：把 Agent 嵌进自家产品的团队。它们仍然需要很多定制，因为产品体验、客户数据和业务规则都不一样。但它们没有必要把工程资源砸在 Agent 的底座上。平台提供的是可组合的运行环境，产品团队在上面加自己的界面、规则和客户流程。 如果团队的优势在业务理解，基础设施越少占用研发时间越好。 主持人还追问了 Slack 场景：一个常驻团队频道、带自己性格、负责一块工作的 Agent，会不会成为平台的一部分。Angela 的回答偏肯定。Anthropic 已经先做了 vaults 这类更底层的凭证原语，下一步自然会碰到 agent identity、Slack 集成、一键部署等更产品化的入口。平台先处理难啃的基础设施，再逐步贴近团队每天用的工作界面。 法律审稿流程给了一个模板 最具体的案例来自 Anthropic 内部：市场同事写完文案，以前可能要开 ticket，请法务审。现在可以先提交给一个法律审稿 Agent，由它按规则做第一轮检查；足够清楚的内容直接放行，拿不准的再进入法务收件箱。这个 Agent 可能接 MCP server 读外部上下文，用 skills 存规则，再通过一个小 app 让市场和法务一起看结果。 Agent 没有取消人的判断，它的作用是把重复的第一遍筛查前置。 "它会先做一轮 Agent 审查，再把结果放进法务的收件箱。" 这也是 managed agents 和单个 skill 的差别。法务规则当然可以写成 skill，但完整流程还需要独立会话、认证、权限和人工介入。市场同事提交一段 copy 后，Agent 要能启动自己的任务，查规则，判断是否需要人审，再把结果交给正确的人。业务流程越接近现实组织，越需要这种“会运行的系统”，而不是一段只在聊天窗口里执行的提示词。 多人协作需要可看见的会话 Dan 追问：为什么法律审稿不能只是一个 skill？Caitlin 的回答抓住了团队 Agent 的形态差异。Skill 可以装规则，MCP 可以接上下文，但多人要共同查看输出、补充信息、让多个 Agent 参与，还需要会话、权限和界面。Angela 还提到，内部工具起初可能由平台团队写，后来业务同事打开 Claude Code 自己改小地方，再由拥有系统的团队 review PR。 团队 Agent 的难点不只在模型，难在谁能看、谁能改、谁负责。 "你还需要合适的形态，让不同的人能协作，也让多个 Agent 能进入同一个系统。" Angela 描述了另一层保护：业务同事不一定直接碰最底层代码。Anthropic 会让他们通过 Claude 与自己拥有的 Agent 交互，让 Claude 判断怎么改规则、改配置，必要时再生成可 review 的变更。底层仍有平台团队负责系统边界，业务团队获得更低门槛的调整入口。 组织里人人都能改 Agent，不等于人人都直接改核心系统。 这也是为什么 Angela 会说，到了团队层面，一切突然复杂很多。个人工具只要帮一个人提高效率；团队 Agent 要处理共享上下文、统一规则、审计轨迹、权限层级和负责人。Stripe 的 Minions、Ramp 的内部平台、Anthropic 自己的工具，都指向同一个变化：AI 原生组织需要一层开发者生产力平台，不只是每个人多装一个聊天机器人。 Agent 自己也要升级和退场 当公司里有很多 Agent 常驻 Slack、每周推送一次、偶尔处理一个流程，新的麻烦也会出现：没人负责就会变旧，模型升级后旧架构可能不合适，提示词和规则也会过期。Anthropic 的做法之一是写 skills，帮助 Agent 升级到新模型；更激进的团队会让 Agent 监控 Agent，发现哪些该迁移、哪些该停用。Caitlin 仍把评估放回可验证结果：coding Agent 可以看 PR 是否合并，业务 Agent 要把 outcome 和 budget 定义清楚。 "最后的状态也许会把一切压缩成一个结果和一个预算。" 多 Agent orchestration 也被放进同一条线里。Angela 提到几种架构：advisor strategy 把执行和建议分开；生成者和对抗者互相检查；小任务拆成很多片再汇总；还有 best of N 的多路尝试。深度研究、广度研究、bug hunting 分别适合不同组合。平台如果把原语做得像 LEGO，团队就能在更高层拼出策略，而不是每次从底层拼接网络、权限和文件。 Caitlin 最后给出的工程重点更朴素：平台必须撑住这些形态。Agent 如果能按任务临时组成、长时间运行、不断重建自己，系统就要能处理长请求、不同形状的工作负载和持续增长的 token 进出。模型能力越往前走，平台越不能成为交付瓶颈。她说，一年后再聊 Claude 平台，团队最在意的可能就是规模：用户想让 token 进出 Claude，系统就必须稳定接住。否则再聪明的 Agent，也会卡在排队、超时、权限、上下文丢失、结果回传、跨团队追踪、成本控制、审计和归档等老问题上。 写在最后 这场对话最有参考意义的地方，是把 Agent 平台讲成了日常工程问题：文件、权限、运行环境、评估、协作、升级和系统韧性。先别急着追逐最花哨的多 Agent 架构，先把一个清晰流程做成能交付、能审查、能维护的 Agent。工作方式的变化，会从这些小系统开始。 内容来源："The Secrets of Claude's Agent Platform From the Team Who Built It"丨Every（嘉宾：Angela、Caitlin） 原视频：https://www.youtube.com/watch?v=lLypHkIVLqc 697c5a1917944dc79002dde6ffe3b5d7.mp4 297.28MB 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ https://mp.weixin.qq.com/s/ebKFqPYW... 🔗 原文链接： https://mp.weixin.qq.com/s/ebKFqPYW... https://mp.weixin.qq.com/s/ebKFqPYW... 原创 Capihom Capihom 晚点再听LaterCast2026年5月9日 20:45 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "平台最终会是一组原语和基础设施，让你用最少的工作最快拿到结果。" "如果你把 Agent 做进产品，并且真的跑到规模上，基础设施会越来越难。" "最后可能只剩两个参数：结果和预算。" Every 这次请到 Anthropic Claude 平台负责人 Angela 和工程负责人 Caitlin。两人负责的对象已经超出聊天入口，延伸到 Claude 背后的开发者平台：Messages API、code execution、web search、managed agents、memory、skills、vaults。主持人 Dan Shipper 一上来就问得很实在：GPT 3 时代，平台只是补全端点；今天，Claude managed agents 更像一台带文件系统、记忆和工具的云端电脑。工程师、产品负责人和创业团队读这场对话，可以看到下一层抽象会落在哪里，以及今天自己搭 Agent 时哪些基础设施不该重复造。 API 从补全端点走到云端电脑 Angela 回顾 Claude 平台的演进时，把线索放在一个词上：stateful。早期开发者把 prompt 发进 API，拿回一个 completion；后来有了 chat session、tool calling；再往后，客户开始追问怎么接工具、怎么跑 loop、怎么让 Agent 自主完成一段工作。 平台的任务从“吐 token”变成“让结果稳定发生”。 Managed agents 把 Messages API、内置工具、sandbox、web search 等能力包进同一套 harness，开发者可以直接在更高层上搭东西。 "随着 Claude 变得更自主，我们发现平台需要走向更高阶的抽象，只为帮你拿到更好的结果。" 她举的原语很具体：Messages API 仍在底层，但开发者现在可以直接用 code execution，拉起 sandbox 执行任务，也可以用 web search 补外部信息。平台团队把这些能力放进一套运行架构里，目标是让开发者少消耗在调度、状态和工具组合的反复试错上。 当客户问“怎么把 Claude 用好”，答案已经进入平台设计，而不只停在模型参数上。 Mac mini 脚本暴露了规模边界 Dan 提到 Every 内部也在做 Agent：几台 Mac mini 上跑着 Claude loop，一个上千行 Python 文件负责调度，能用文件系统和浏览器。很多团队今天也处在这个阶段，先把可用性跑出来，再考虑平台化。Caitlin 的回答很直接：Anthropic 自己也重复搭过这类基础设施，搭到足够多次后，团队决定把它做成可复用的平台。 个人试验可以放在一台机器上，产品级 Agent 要处理长任务、状态、隔离、权限和失败恢复。 "如果你把 Agent 做进产品，并且真的跑到规模上，基础设施会越来越难。" 几台机器上的 loop 很适合验证想法，进入产品后就会遇到完全不同的账本：同一时间有多少 Agent 在跑，失败后怎么重试，用户凭证放在哪里，长任务中间的上下文如何保留，任务结束后怎么把结果交回产品。Anthropic 做 managed agents 的动机，来自自家产品团队多次重复搭建这些设施后的疲劳。 平台化的目的很朴素：把重复的云端运行成本摊薄。 文件系统和 skills 成了 Claude 的工作手势 Anthropic 在 managed agents 上没有追求完全中立。Angela 说得很清楚，平台会在一些地方保持 opinionated：让 Claude 使用文件系统，鼓励使用 skills，把这些原语和模型的工作方式绑得更紧。她承认，这些选择像小注脚，时间拉长后会影响模型擅长什么、产品怎么搭。 Agent 工程不再只是 prompt 技巧，文件、工具、技能、运行环境都会进入模型行为的训练场。 "使用文件系统，使用 skills。它们很基础，但我们希望 Claude 从这些原语出发。" Dan 追问这种路径依赖会不会把模型带进固定赛道。Angela 的回答很谨慎：Anthropic 不能保证每个选择都永远正确，但会认真挑选哪些能力更“原生”地给模型。文件系统看似只是交互方式，后面会影响模型怎么读项目、怎么修改文件、怎么留下中间结果。Skills 也是同一类东西，它把组织经验做成可调用的能力，让 Claude 在任务中复用。 通用模型切换开始让位于成套 Agent Dan 提出团队最常见的顾虑：如果用了 Claude managed agents，会不会失去把模型切到 GPT、Gemini 或下一代模型的自由？Angela 没有回避。几个月前，很多团队还在搭很通用的 harness，底层模型热插拔。她观察到，下一代模型正在走向不同训练路线和工具偏好。 为了榨出模型能力，harness 和模型会变成一组交付单元，而不是随便拆开的零件。 冗余和多模型仍会存在，但切换层级可能从“换底层模型”上移到“换一整套 Agent”。 "你仍然需要冗余，也可能在某些事情上用别的模型，但更可能是在 Agent 这一层切换。" 她提到一个内部实验：团队为 memory 试过多套 harness，评估结果差异非常大。看起来只是“怎么请求、怎么保存、怎么让模型用工具”的细节，最后会变成输出质量的差距。Cursor 这类产品是否为不同模型做不同 harness，Angela 没有直接判断，但她观察到外部团队也在往类似方向走。 未来的竞争很可能发生在 Agent 配方层：模型、工具、记忆和执行环境怎么绑在一起。 这会改变团队的技术决策顺序。过去先问“底层选哪个模型”，然后再套一层统一接口；现在可能先定义用户要什么结果，再选择哪一套 Agent 能更稳定交付。模型锁定的焦虑不会消失，但它会被交付质量、评估结果和迁移成本重新排序。工程负责人要管理的，已经不只是 provider 列表。 内置 Agent 先从团队流程落地 谁最适合先用 managed agents？Caitlin 给了两个场景。一个是公司内部自动化，比如完整的软件开发平台，或者一个小流程：市场文案需要法务先审。另一个是把 Agent 做进面向客户的产品。两类场景共同的痛点都很工程化：团队不想每次重新实现 memory、运行 loop、权限、部署和协作界面。 平台先解决重复的底层劳动，让业务团队把精力放在流程本身。 "你不应该每次做内部自动化时，都重新实现 memory 和这些底层东西。" Caitlin 还补了一种角色：把 Agent 嵌进自家产品的团队。它们仍然需要很多定制，因为产品体验、客户数据和业务规则都不一样。但它们没有必要把工程资源砸在 Agent 的底座上。平台提供的是可组合的运行环境，产品团队在上面加自己的界面、规则和客户流程。 如果团队的优势在业务理解，基础设施越少占用研发时间越好。 主持人还追问了 Slack 场景：一个常驻团队频道、带自己性格、负责一块工作的 Agent，会不会成为平台的一部分。Angela 的回答偏肯定。Anthropic 已经先做了 vaults 这类更底层的凭证原语，下一步自然会碰到 agent identity、Slack 集成、一键部署等更产品化的入口。平台先处理难啃的基础设施，再逐步贴近团队每天用的工作界面。 法律审稿流程给了一个模板 最具体的案例来自 Anthropic 内部：市场同事写完文案，以前可能要开 ticket，请法务审。现在可以先提交给一个法律审稿 Agent，由它按规则做第一轮检查；足够清楚的内容直接放行，拿不准的再进入法务收件箱。这个 Agent 可能接 MCP server 读外部上下文，用 skills 存规则，再通过一个小 app 让市场和法务一起看结果。 Agent 没有取消人的判断，它的作用是把重复的第一遍筛查前置。 "它会先做一轮 Agent 审查，再把结果放进法务的收件箱。" 这也是 managed agents 和单个 skill 的差别。法务规则当然可以写成 skill，但完整流程还需要独立会话、认证、权限和人工介入。市场同事提交一段 copy 后，Agent 要能启动自己的任务，查规则，判断是否需要人审，再把结果交给正确的人。业务流程越接近现实组织，越需要这种“会运行的系统”，而不是一段只在聊天窗口里执行的提示词。 多人协作需要可看见的会话 Dan 追问：为什么法律审稿不能只是一个 skill？Caitlin 的回答抓住了团队 Agent 的形态差异。Skill 可以装规则，MCP 可以接上下文，但多人要共同查看输出、补充信息、让多个 Agent 参与，还需要会话、权限和界面。Angela 还提到，内部工具起初可能由平台团队写，后来业务同事打开 Claude Code 自己改小地方，再由拥有系统的团队 review PR。 团队 Agent 的难点不只在模型，难在谁能看、谁能改、谁负责。 "你还需要合适的形态，让不同的人能协作，也让多个 Agent 能进入同一个系统。" Angela 描述了另一层保护：业务同事不一定直接碰最底层代码。Anthropic 会让他们通过 Claude 与自己拥有的 Agent 交互，让 Claude 判断怎么改规则、改配置，必要时再生成可 review 的变更。底层仍有平台团队负责系统边界，业务团队获得更低门槛的调整入口。 组织里人人都能改 Agent，不等于人人都直接改核心系统。 这也是为什么 Angela 会说，到了团队层面，一切突然复杂很多。个人工具只要帮一个人提高效率；团队 Agent 要处理共享上下文、统一规则、审计轨迹、权限层级和负责人。Stripe 的 Minions、Ramp 的内部平台、Anthropic 自己的工具，都指向同一个变化：AI 原生组织需要一层开发者生产力平台，不只是每个人多装一个聊天机器人。 Agent 自己也要升级和退场 当公司里有很多 Agent 常驻 Slack、每周推送一次、偶尔处理一个流程，新的麻烦也会出现：没人负责就会变旧，模型升级后旧架构可能不合适，提示词和规则也会过期。Anthropic 的做法之一是写 skills，帮助 Agent 升级到新模型；更激进的团队会让 Agent 监控 Agent，发现哪些该迁移、哪些该停用。Caitlin 仍把评估放回可验证结果：coding Agent 可以看 PR 是否合并，业务 Agent 要把 outcome 和 budget 定义清楚。 "最后的状态也许会把一切压缩成一个结果和一个预算。" 多 Agent orchestration 也被放进同一条线里。Angela 提到几种架构：advisor strategy 把执行和建议分开；生成者和对抗者互相检查；小任务拆成很多片再汇总；还有 best of N 的多路尝试。深度研究、广度研究、bug hunting 分别适合不同组合。平台如果把原语做得像 LEGO，团队就能在更高层拼出策略，而不是每次从底层拼接网络、权限和文件。 Caitlin 最后给出的工程重点更朴素：平台必须撑住这些形态。Agent 如果能按任务临时组成、长时间运行、不断重建自己，系统就要能处理长请求、不同形状的工作负载和持续增长的 token 进出。模型能力越往前走，平台越不能成为交付瓶颈。她说，一年后再聊 Claude 平台，团队最在意的可能就是规模：用户想让 token 进出 Claude，系统就必须稳定接住。否则再聪明的 Agent，也会卡在排队、超时、权限、上下文丢失、结果回传、跨团队追踪、成本控制、审计和归档等老问题上。 写在最后 这场对话最有参考意义的地方，是把 Agent 平台讲成了日常工程问题：文件、权限、运行环境、评估、协作、升级和系统韧性。先别急着追逐最花哨的多 Agent 架构，先把一个清晰流程做成能交付、能审查、能维护的 Agent。工作方式的变化，会从这些小系统开始。 内容来源："The Secrets of Claude's Agent Platform From the Team Who Built It"丨Every（嘉宾：Angela、Caitlin） 原视频：https://www.youtube.com/watch?v=lLypHkIVLqc 697c5a1917944dc79002dde6ffe3b5d7.mp4 297.28MB 697c5a1917944dc79002dde6ffe3b5d7.mp4 297.28MB 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣