Anthropic 在 2026 年 4 月 30 日发了一篇 blog：《Building AI agents for the enterprise》，同时放出了一份 23 页 eBook。表面上看，这是 Claude Cowork 的企业落地材料。细看之后，会发现它真正讲的是企业级 Agent 的架构问题。
企业不缺一个能聊天的 AI。企业缺的是一个能进入组织流程、吃到组织知识、在权限和合规边界里完成任务，并且能被管理员治理的工作系统。
这份报告的主线
整份 PDF 的结构很清楚：员工、流程、产品。
员工层讲的是怎么让每个业务岗位拿到专家能力。流程层讲的是怎么把信息密集型流程从几天、几周压到几分钟。产品层讲的是怎么把 AI 做成客户真的能用的新能力，价值目标开始从降本走向收入。
这三个层级是递进关系。
先是个人变强，再是流程变快，最后是产品发生变化。到了第三层，AI 就不只是降本工具了，它开始影响收入、客户关系和产品护城河。
Anthropic 用了一个词：agentic thinking divide。我的理解是，企业会被分成两类。一类把 AI 当 chatbot，用来回答问题、总结文档、写点内容。另一类把 Agent 放进组织运行方式里，让它能调用工具、处理流程、沉淀经验、交付结果。
逐页看这份 PDF
报告内容见原文链接：https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/69f3af1f0b8ebe5cde42fcda_Claude-Building-AI-Agents-in-the-Enterpise-04302026_v2%20(1).pdf
第 1 页是封面，定位是 enterprise best practices。它面向企业领导者、平台团队和业务负责人，不是开发教程。
第 2 页是目录。目录把全文分成思维区分、员工升级、流程加速、产品开发、组织扩展和复利优势。这个顺序已经说明了 Anthropic 对企业 AI 的判断：不要从模型能力讲起，要从组织能力讲起。
第 3 页提出 thinking divide。企业现在的核心问题是 AI 用到什么范围。一个 chatbot、一个摘要器、一个 demo pilot 都能带来局部价值，但不会改变组织怎么运转。Agent 要能推理复杂任务，执行多步骤流程，并应用企业自己的领域知识。
第 4 页定义概念。Agent 和 Chatbot 的区别被讲得很直接：Chatbot 回答问题，Agent 完成目标。Claude Code 是工程师入口，Claude Cowork 是非工程岗位入口。MCP 负责接外部系统，Plugins 打包角色能力，Skills 固化可复用工作流。
第 5 页进入员工升级。这个章节的重点是把员工从重复、跨系统、信息密集的工作里释放出来。
第 6 页讲组织定制。通用模型只能给通用输出，企业收益来自把公司标准、术语、工具和制度知识给到 Agent。销售的例子很典型：Claude 接 CRM、会议记录和客户研究工具，拜访前自动生成 brief。财务、法务、营销也一样，Agent 必须在企业自己的知识框架里工作。
第 7 页是 L'Oreal 案例。原来业务员工每问一个数据问题，都要提交 dashboard 请求，等专家写查询。后来他们建了 Claude-based internal AI platform，用 15 个以上专门 Agent 把自然语言问题转成数据洞察和可视化。结果是 44,000 月活、2.5M 月消息、15,000 日活，conversational analytics 准确率从 90% 提到 99.9%。
第 8 页进入流程加速。这里开始从个人能力转向组织瓶颈。
第 9 页讲信息密集流程。季度规划、监管提交、法务审查、合规检查，这些流程慢，原因通常不是缺专家。更常见的情况是，专家知识要反复处理大量材料，而且不能出错。Anthropic 的关键观点是，专家反馈要进入 AI 知识库。每一次审阅都应该让未来流程变好。
第 10 页是 Lyft 案例。Lyft 的客服曾经让用户等 30 到 40 分钟，客服还要同时处理三四个聊天。Claude 接入后，能先调查具体情况、处理可解决问题，需要人工判断时再把摘要交给客服。结果是客服解决时间下降 87% 以上，决策准确率提升 30% 以上。
第 11 页进入产品开发。前两层主要是效率，第三层开始讲新产品能力。
第 12 页讲产品护城河。企业 AI 产品的价值来自前沿模型、专有数据、客户信任和领域知识的组合。这里最重要的概念是 trust boundary。金融、医疗这类行业里，数据安全和合规是产品上线前提。Agent 产品第一设计约束是数据在哪、谁能访问、怎么审计、能不能留在既有合规边界内。
第 13 页是 Rakuten 案例，也是和 Claude Managed Agents 关系最深的一页。Rakuten 有 70 多个业务，早期意识到 Agent 要有持久计算、记忆和存储，于是自建执行层。后来采用 Claude Managed Agents，把 execution layer 托管出去，工程团队回到差异化 Agent 体验上。结果是 specialist agents 一周内可部署，重大产品发布从季度一次变成两周一次，pilot 中 critical errors 下降 97%，成本和延迟下降超过 30%。
第 14 页开始讲怎么把 Claude 带到更多团队。前面几个案例都需要企业自建平台，Claude Cowork 要解决的是把这些能力产品化给非技术团队。
第 15 页讲 Claude Cowork。它让知识工作者也能委派复杂任务，并收到 Word、Excel、PPT、报告、分析这类完整交付物。关键机制是 Plugins。插件把 skills、context、connectors 打包成角色专用能力。销售插件知道 CRM 和销售流程，法务插件知道合同模板和风险框架，财务插件知道科目表和报告标准。
第 16 页讲企业规模化能力：插件市场、管理员控制、角色权限、用量和成本、OpenTelemetry 可观测性、本地执行、和既有工具集成。这里要补一层现实判断：帮助中心同时提醒，Cowork activity 当前不进入 Audit Logs、Compliance API 或 Data Exports，也不建议用于 regulated workloads。所以企业真要落地，必须同时看产品宣传和实际安全文档。
第 17 页给部署框架。先找两三个有明确痛点的团队，定义成功标准，把相关插件装好或定制好。不要用“提升生产力”这种空目标，要写成销售 call prep 时间减少 50%，法务合同审查从 5 天到 1 天，文档初稿质量达到最终稿 80%。
第 18 页讲第 4 到第 6 个月的规模化：部署 admin marketplace，建立插件审查和审批流程，把试点中沉淀的插件扩到更多团队。它强调复利：第一波沉淀上下文和治理，第二波就会更快。
第 19 页是复利优势章节页。
第 20 页是全文收束。不要等战略完美再开始。找一个痛点明确、成功标准清晰的流程，给 Claude 足够上下文，真实测结果，然后扩大。
第 21 页到第 23 页是资源和结束页。
Cowork 和 Managed Agents 分别解决什么
Claude Cowork 和 Claude Managed Agents 分别站在不同层面。
Cowork 是业务入口。它解决非工程团队怎么把 Agent 用起来。员工可以在 Claude Desktop 里发起任务，让 Claude 读写本地文件，生成 Excel、PPT、Word、研究报告，也可以通过插件拿到角色化能力。
Managed Agents 是平台入口。它解决开发者和企业平台团队不用自建 Agent harness。官方文档里，Managed Agents 的核心抽象是 Agent、Environment、Session、Events。
Agent 里放模型、system prompt、tools、MCP servers、skills。Environment 是带依赖、网络和文件的容器模板。Session 是一次具体任务。Events 是应用和 Agent 之间的消息、工具结果和状态流。
再加上工具、权限策略、多 Agent、memory stores、outcomes，Managed Agents 就变成了一个托管执行层。它适合长任务、异步任务、产品内 Agent、后台 Agent，也适合像 Rakuten 这样的企业把基础执行层交出去。
所以可以这样理解：
Cowork 让企业员工用上 Agent。
Managed Agents 让企业产品和平台团队造出 Agent。
企业级 Agent 架构应该长什么样
我会把它拆成七层。
入口层：Claude Cowork、Slack、Teams、Kanban、业务系统、产品 UI、API。
目标层：用户目标、outcome、rubric、审批点、human-in-loop。
编排层：主 Agent、specialist agents、sub-agent threads、任务拆分和汇总。
执行层：Managed Agent session、container、filesystem、bash、web、file tools、custom tools。
知识层：plugins、skills、memory stores、组织标准、模板、品牌口径、合规规则。
连接层：MCP、connectors、CRM、数据仓库、文档系统、工单系统、Office、Slack。
治理层：RBAC、plugin marketplace、permission policies、spend controls、OpenTelemetry、审计、数据边界。
很多企业做 Agent 卡住，并非模型不够聪明，问题常出在只做了入口层和 prompt。难点在后面六层。
比如一个法务 Agent，如果只会读合同和总结条款，价值有限。它要知道公司合同模板、风险偏好、审批流程、历史修改意见、哪些系统能查、哪些动作必须审批、谁能看什么客户材料、每次判断怎么留痕。这个东西已经进入组织流程。
为什么企业 Agent 不能照搬 toC
toC 场景里，Agent 更像个人助理。它帮你写东西、整理文件、查资料、做几个自动化动作。错了可以重来，风险大多是个人时间。
企业场景里，Agent 处理的是组织资产。它会碰客户数据、合同、财务、工单、产品发布、合规材料。一个错误可能影响客户、品牌、监管和收入。
所以企业 Agent 要解决的问题完全不同。
它要有组织上下文，不能只理解个人偏好。
它要有权限边界，不能拿到所有东西。
它要有可复用机制，不能让每个人自己写 prompt。
它要有审计和可观测性，不能只看最终答案。
它要有 human-in-loop，不能一味追求全自动。
它要能跨系统工作，不能停在一个聊天窗口里。
所以插件、MCP、memory、permission policies、OTel、admin marketplace 这些看起来“不性感”的东西，才是企业级 Agent 的关键。
价值在哪里
L'Oreal 的价值是把数据能力从专家团队释放到业务员工。员工不用排队等 dashboard，也能直接问数据问题，拿到可视化结果。
Lyft 的价值是把客服流程拆开。Agent 处理可调查、可判断、可执行的部分，人工处理需要同理心和复杂判断的部分。结果是客服不用同时扛三四个聊天。
Rakuten 的价值更底层。它发现自建 Agent 执行层会消耗工程资源，于是把 sandbox、session、memory、tool execution 这类基础设施交给 Managed Agents。工程团队终于能把时间花在业务 Agent 体验上。
这三个案例对应三种 ROI：
员工层看采用率、节省时间、输出质量。
流程层看周期压缩、准确率、人工介入率。
产品层看发布节奏、新收入、客户留存、错误率和平台粘性。
企业级 Agent 的价值在复利。一个团队沉淀的插件，可以被另一个团队复用。一次专家审阅，可以进入下一次流程。一个通过治理的连接器，可以成为更多 Agent 的基础能力。
总结
这份报告让我更确定一件事：企业级 Agent 的主战场不在聊天窗口。
主战场在组织架构里。谁能把企业知识、工具、流程、权限、审计和执行环境组合好，谁才能把 Agent 从个人效率工具变成组织基础设施。
Claude Cowork 解决的是业务侧入口问题，Managed Agents 解决的是平台侧执行问题。Plugins、Skills、MCP、Memory、Outcomes、Permissions、OTel 这些能力拼起来，才像一个企业 Agent 系统。
对企业来说，最实际的启动方式也很朴素：别先做全公司战略，找一个痛点明显的团队，定义清楚指标，把上下文和工具接好，跑一个真实流程。跑通之后，把专家知识沉淀成插件和 memory，再交给下一个团队。
这条路看起来慢，但它会累积。企业 AI 最终拼的是谁先把组织知识变成可执行、可治理、可复用的系统。
