唯快不破，Anthropic几天搞定智能体生产

凌晨，Anthropic 发布了Claude Managed Agents，一套用于构建和部署云端智能体的托管工具。

用最简单的话来介绍，开发者不需要再处理安全、状态管理和权限等基础设施，能直接让Agent运行在生产环境。

官方称，一个原本需要数月才能上线的Agent，现在可以在几天内投入生产。

01

以10倍速度进入生产

在此之前，Agent开发真正的难点从来不在模型本身，而在工程。

我们可以很快用Claude或其他大模型做出一个看起来不错的demo：能写代码、能分析文档、甚至能自动调用工具。但一旦想把它变成一个能稳定运行的产品，问题就出现了。

明明它看起来什么都能做，可就是很难真正用在生产环境里。

demo做出来以后，开发者还需要自己搭一整套基础设施：安全的代码执行环境、长时间运行的状态管理、不同工具之间的权限控制，以及在出错时能够恢复的机制。这些能力每一个都不算复杂，但组合在一起，就是一件非常耗时的大工程了。

更麻烦的是，这些工作几乎无法复用。

模型一旦升级，harness里原本写死的那些假设往往不再那么适配，不同Agent之间也很难共享一套稳定的运行框架。

Agent开发翻来覆去：每个团队都在解决同一类问题，但很少有人真正把它做到稳定。

因此我们经常看到，Agent可以轻松做出demo，却迟迟才能上线。

Claude Managed Agents试图解决的正是这一问题：安全执行、状态管理、权限控制、错误恢复……它把这些原本要自己搭的一整套东西全部打包，统一由Anthropic提供。

开发者不需要再关心Agent是怎么跑起来的，只要告诉它做什么、能用什么工具、有哪些限制，剩下的执行过程都由系统自动完成。

带来的变化也很直接：原本要花几个月搭出来的一整套系统，现在变成了一个可以快速尝试、反复调用的接口。

它没有让Agent变得更聪明，但它狠狠缩短了demo和生产之间的距离。

除了加速上线的“工具包”，它还做了以下几件事：

首先是对长时间运行任务的支持。Agent可以在后台自主运行数小时，进度和输出会被持续保存，即使发生中断也不会丢失。

其次是多Agent之间的协作能力。Agent可以创建并调度其他Agent，以并行方式处理复杂工作。该能力目前以research preview形式提供，需要单独申请访问。

然后是对真实系统的访问与治理机制。AgentAgent能够访问带有范围权限、身份管理和执行追踪的真实系统，但能调用哪些工具、拿到哪些权限、使用哪些凭证，模型自己说了不算。

除此之外，系统还内置了一个用于任务执行的编排机制（a built-in orchestration harness），用于决定何时调用工具、如何管理上下文以及在出现错误时如何恢复。这意味着开发者无需手动编排Agent的执行流程，系统会在运行过程中自动进行调度。

这些能力本身并不新，但被放进同一个系统里之后，就省下了很多事情。

02

不只是能用，而是已经在用

在发布中，Anthropic 也给出了一批已经落地的案例，基本覆盖了协作工具、企业系统和开发工具这几个典型场景。

例如Notion（一款将文档、知识库和项目管理整合在一起的协作工具）直接把Claude塞进了工作区里：工程师让它写代码，内容团队让它做网站、做PPT，多个任务还能并行。

在企业侧，Rakuten（日本大型互联网与电商集团，业务涵盖电商、金融和通信）已经在多个部门部署Agent，包括产品、销售、市场、财务和人力资源。他们的做法很直接：把Agent接进Slack和Teams，让员工像派活一样分配任务，然后拿回表格、幻灯片甚至应用。官方说，一个Agent一周就能部署完成。

Asana（一家提供团队任务管理和项目协作工具的软件公司）的思路更激进一点。这家公司本来就是做项目管理的，现在干脆把Agent变成项目成员，直接参与任务推进和内容产出，起的名字也很直白：AI Teammates。

开发者这边的代表是Sentry（提供错误监控和性能分析的开发者工具），它原本就是用来监控bug的，现在Agent可以自动生成修复代码并创建Pull Request，把发现问题到提交修复的流程串起来。

还有Vibecode（一个通过自然语言生成并部署应用的AI开发工具平台），这类AI原生工具走得更远一点：用户只需要写一句需求，就可以从提示直接生成并部署一个应用，而Managed Agents成了它背后的默认基础设施。

如此种种可以看出，不管是写代码、做内容还是处理企业流程，Agent已经开始直接接手任务了

某种意义上，当安全、状态、权限和调度都变成默认能力之后，Agent不再需要被“包装”成系统，它本身就可以作为系统运行。

Agent缺的从来不是能力，只是难以落地而已。

过去开发者需要先搭好一整套框架，才能让Agent开始落地干活；现在这套框架已经提前存在，Agent可以直接被部署进去。

这就是Claude Managed Agents的意义所在。

03

工具很好，但问题才刚开始

Claude Managed Agents一推出就引发了大量讨论。

很多人对Anthropic的推进速度感到惊讶，心情就如同下面的meme：每天一起床就又看到一个Claude更新。

这不，泄露事件之后立马更新了Claude Code 2.1.90，Claude Mythos Preview的热度还没过，Claude Managed Agents又马上出来了。

Anthropic你尽管推出，我们一点也不苦一点也不累。

开个玩笑。在感叹发布速度的同时，对新工具的质疑也几乎同时出现。

最直接的问题，是它到底能不能真正跑好“长期任务”。

有开发者指出，Agent最大的挑战从来不在短任务，而是那些需要持续运行、反复决策的场景。一旦时间拉长，错误会不断累积，系统稳定性也会迅速下降。

能跑起来，不等于能跑得久。

更进一步，是“可靠性”的问题。

在小规模测试中，Agent往往表现不错，但一旦进入真实生产环境，任务复杂度上升、调用链变长，各种边界情况就会不断出现。

这恰恰是大多数Agent平台最容易失效的地方。

还有人把问题问得更实际一些：既然现在已经有多Agent能力，那它到底能不能直接替代现有的工作流工具？

还是说，像n8n这样的系统，依然是必需的？

本质上关心的还是同一件事：n8n就是为了保证流程稳定、可控、可复现，要想替代它，这套多Agent协调的系统必须足够稳定，足够“可靠”。

值得注意的是，Anthropic在工程设计上也在尝试解决这个问题。

在最新的技术文章中，他们将Agent系统拆成三个独立的部分：模型与调度逻辑（“大脑”）、执行环境与工具（“手”），以及记录全部过程的会话日志（session）。

三者通过接口连接，任何一层失败都可以单独恢复，而不会影响整体运行。

这套设计，把Agent从一次性执行的流程，变成了一个可以中断、恢复甚至重启的系统。

另外，对于那些需要长时间运行的任务，Anthropic没有把所有信息都塞进模型的上下文里，而是记录在外部日志中，需要时再取回来用，这样就不会占满上下文窗口。

同样地，权限也不再交给模型保管，而是单独隔离出去，这样即使出错，也不会直接暴露敏感信息。

不过工程设计只能解决结构问题，没办法保证结果。

可以说，大家并不怀疑Claude Managed Agents能做什么，怀疑的是它能不能稳定、可控地一直做下去。

这一点，就需要时间来验证了。

Claude Managed Agents介绍：
https://claude.com/blog/claude-managed-agents

工程博客：
https://www.anthropic.com/engineering/managed-agents