lxiol 博客

—title: Claude Managed Agents 详解：Anthropic 为什么要托管 Agent 运行底座
date: 2026-04-15 11:10:22
summary: title: Claude Managed Agents 详解：Anthropic 为什么要托管 Agent 运行底座 date: 2026-04-15 11:10:22 summary:
tags:

Claude Code
Codex
Hermes
AI Agent
开源
LLM
效率工具
搜索
Claude
Managed Agents
Agent
Anthropic
架构
categories:
转载—

原文链接：https://mp.weixin.qq.com/s/WsNQWXz1_kAQtHRvBtC11Q?scene=1&click_id=18

当模型已经足够强时，你有没有一套能让它长期运行、可恢复、可追踪、可控、可审计的系统？

架构师（JiaGouX）

我们都是架构师！
架构未来，你来不来？

看到 Claude 官方发 Managed Agents 的那一刻，我心里一紧。

前几天还在写 Harness、Skill、Memory，讨论的是“模型外面那层系统到底怎么做”。现在 Anthropic 直接把这层推成了 Claude Platform 上的托管能力。

这不只是一次普通产品更新。

它把我们过去一段时间反复拆的东西，直接打包成了平台能力：Agent、Harness、长任务、沙箱、权限、session、tracing、错误恢复。

这些词分开看都不新。

但 Anthropic 这次把它们放到了一条更清楚的产品线上：Agent 从 demo 走向生产，真正难自建的那一层，不是模型调用，而是运行底座。

4 月 8 日，Anthropic 发布 Claude Managed Agents。官方博客的定位很直接：帮助开发者更快构建和部署云端托管 Agent。

如果只把它写成“Anthropic 又发了一个 Agent API”，就太浅了。

我这次更想盯着三个问题：

• 它到底托管了哪一层？
• 为什么它会让一批做通用 Agent infra 的团队开始紧张？
• 技术团队现在应该先看懂什么？

如果用一句更直白的话讲：

它做的不是替你写一个 Agent。更准确地说，它把“让 Agent 能稳定干活”的后台搬到了云上。

你仍然要定义任务、工具、权限和完成标准。

但沙箱、长会话、状态保存、错误恢复、工具执行、日志追踪这些过去很重的底座，Anthropic 开始替你托管。

先说我自己的理解

我现在的理解大概是这样：

• 我目前的判断是：Claude Managed Agents 最值得看的地方，在于 Anthropic 把 Agent 的运行底座搬到了云端托管平台。
• 它不是一个聊天入口，更接近一套可以长期运行、可恢复、可追踪的云端 Agent 运行系统。
• 它让开发者定义任务、工具和 guardrails，Anthropic 负责运行环境、工具执行、session、tracing、恢复等基础设施。
• 官方文档把核心对象拆成四类：Agent、Environment、Session、Events。
• 它适合长时运行、异步、多工具调用、需要云端沙箱和持久会话的任务。
• 当前仍是 beta，outcomes、multiagent 等能力还是 research preview，不能写成完全成熟。
• 成本也不只是 token。官方价格是标准 Claude Platform token 费用，再加活跃运行时长的 $0.08 / session-hour。
• 对创业公司来说，通用 Agent infra 会变薄，垂直领域的 workflow、合规验证、权限模型和业务交付反而更重要。

从聊天框到接工作

我自己会用一条线来理解这次发布：

Agent 正在从“会话对象”变成“工作对象”。

会话对象是什么？

你打开一个聊天框，问它问题，让它写总结、改文案、分析材料。它的主要边界是上下文窗口和一次回答质量。

工作对象就不一样了。

你给它一个任务，它可能要跑半小时，期间读文件、写文件、调工具、查网页、生成中间产物、遇到错误后重试，还要把过程留给团队复盘。

这时候问题就从“模型会不会回答”变成了：

• 它在哪里执行？
• 状态丢了怎么办？
• 权限怎么收口？
• 工具调用怎么审计？
• 中途失败怎么恢复？
• 最后产出怎么验收？

这就是运行底座的问题。

如果只做聊天框，运行底座可以很薄。

如果要让 Agent 真正接工作，运行底座就会变成主战场。

Claude Managed Agents 把这条主线挑明了：Anthropic 不只想提供模型，也想提供“让模型稳定接工作”的那层运行系统。

把这点想清楚，后面的四个对象、Brain / Hands / Session、客户案例，以及 Agent startup 会不会难受，就都能串起来。

图：把 Claude Managed Agents 放回“托管 Agent 运行底座”这条线里看，会比把它理解成又一个聊天入口更接近本质。

这条线之前已经露出来了

回头看，最近写的几篇文章，刚好把这次发布前面的几块拼图摆了出来。

当时写的时候，我更多是在顺着每个具体问题拆：Claude Code 为什么能跑长任务，Coding Agent 为什么不能只看模型，Harness 为什么会成为差异，开源 Agent 又是怎么把执行循环、Skill 和记忆串起来。

现在再看 Claude Managed Agents，会发现它像是把这些零散问题收拢到一个更大的答案里。

整理 Claude Code 长任务运行系统时，我关心的是压缩、记忆、续写。说白了，就是 Agent 怎么把一个长任务稳稳跑完，不在中途忘事、跑偏、重复读文件。

拆 Coding Agent 的 6 个关键模块时，问题又往外走了一层：同样是强模型，为什么进了 Codex、Claude Code 之后，就更像一个能协作的工程师。

再到 Anthropic 最近那条 Harness 线，重点从“继续补短板”走到“开始删 dead weight”。也就是模型变强以后，哪些控制权可以还给模型，哪些边界还必须留在系统层。

拆 Hermes Agent 时，我们换到开源实现，看一个 Agent 怎么把执行循环、Skill 沉淀、长期记忆和安全边界串成自己的运行系统。

这些话题看起来分散，其实背后是同一个问题：

模型和 Agent 之间的边界，到底应该画在哪里。

这个边界不是固定的。

模型弱一点时，框架就要多管一点：规划、重试、上下文整理、任务拆分、记忆选择，都要靠系统兜底。

模型强一点时，一部分控制权又可以还给模型。原来必须写死在 harness 里的逻辑，可能会慢慢变成负担。

Anthropic 这次真正想解决的，可能已经不只是“今天应该把边界画在哪里”。

更难的问题是：

当模型能力一直变化时，系统怎么保证边界也能跟着变。

这就是 Managed Agents 让我觉得重要的地方。

它不只是告诉你怎么设计 harness，怎么做长任务，怎么管理 sandbox。

它说：我先把这层变成一组稳定接口。模型、harness、sandbox 将来都可以继续换，但上层业务尽量不要每次推倒重来。

这也是我说“心里一紧”的原因。

过去很多团队还在围绕这层基础设施做产品，Anthropic 已经开始把它变成 Claude Platform 的默认能力。

这对做 Agent infra 的团队不算友好。

但对真正要把 Agent 放进业务流程的技术团队来说，它又确实很有吸引力：少搭一层基础设施，就能更早去验证任务边界、权限边界和业务交付。

这里我不想把话说满。

托管运行底座不等于托管了所有生产问题。它更像是把一批共性问题先拿走，让团队更早暴露真正难的那部分：业务语义、权限治理、验收标准和组织协作。

它不是 GPTs 的同类

很多人第一反应会把 Claude Managed Agents 类比成 GPTs、工作流工具，或者又一组 Agent API。

这个类比只对了一半。

GPTs 更像是面向普通用户的“配置一个助手”。Managed Agents 更靠近开发者平台，官方文档里写得很清楚：它是 pre-built、configurable 的 agent harness，跑在 managed infrastructure 上。

更工程一点说，它管的是这几件事：

• 任务怎么持续跑；
• 工具怎么被调用；
• 代码在哪里执行；
• 文件和状态怎么保留；
• 断线、失败、重试怎么恢复；
• 权限、凭证、审计、tracing 怎么处理；
• Agent 输出怎么回到业务系统。

这就不是“多一个 prompt 模板”的问题了。

以前我们做 Agent demo，经常是一个循环：

用户输入 -> 模型思考 -> 调工具 -> 把结果塞回上下文 -> 再调模型。

这个 loop 本身不难。

难的是你真要把它放到生产环境里，让它跑十分钟、半小时、一小时，让它能写文件、跑 shell、查网页、接业务系统、处理错误，还要能解释每一步为什么发生。

这层东西，才是 Managed Agents 真正想接管的部分。

生产 Agent 常常先卡在运行底座

官方博客里列了一组生产 Agent 需要处理的基础设施问题：

• sandboxed code execution
• checkpointing
• credential management
• scoped permissions
• end-to-end tracing

这些词看起来像平台工程清单，但每一项都能把 demo 和生产系统分开。

比如 sandbox。

只回答问题的 Agent 不需要碰文件系统。但只要它开始生成表格、改代码、跑脚本、整理文档，就一定需要执行环境。这个环境既要有能力，又不能无限制放权。

再比如 checkpointing。

普通聊天出错了，大不了让用户重问。长任务跑到 40 分钟时失败，如果没有中间状态、事件日志和恢复机制，前面所有 token、工具调用、上下文整理都可能白费。

再比如 tracing。

Agent 一旦接入业务系统，团队最先问的通常会变成：

• 它刚才为什么调用这个工具？
• 哪一步花了最多钱？
• 哪个权限被用到了？
• 失败是模型判断错了，工具返回错了，还是环境挂了？
• 这次输出能不能复现和审计？

这些问题不解决，Agent 就很难从“能演示”走到“能交付”。

所以 Managed Agents 的价值，不在于让 Claude 多会说几句话，而在于把 Agent 运行时的脏活累活产品化。

四个抽象，解决责任边界

官方文档把 Claude Managed Agents 拆成四个核心概念。

对象

负责什么
Agent
模型、system prompt、tools、MCP servers、skills
Environment
容器模板、预装包、网络访问、挂载文件
Session
某个 Agent 在某个环境里执行一次具体任务
Events
应用和 Agent 之间的消息、工具结果、状态更新

这个拆法很重要，但也不用一上来把它想得太玄。

它没有把 Agent 当成“一个会说话的大模型”，而是把 Agent 放回一套运行系统里：谁负责思考，谁负责执行，谁负责保留状态，谁负责对外通信。

用更简单的角度来看：

• Agent 像这个“数字同事”的角色设定和能力清单；
• Environment 像它的工位、电脑、工具箱和网络边界；
• Session 像它接到的一项具体工作；
• Events 像这项工作从开始到结束留下的流水账。

再换一个工程视角：

• Agent 解决“它是谁、能用什么”；
• Environment 解决“它在哪里动手”；
• Session 解决“这次工作怎么持续”；
• Events 解决“过程怎么被记录、恢复和审计”。

以前很多 Agent demo 把这些东西揉在一起。

能跑，但边界不清楚。

一旦任务变长、工具变多、权限变复杂，就很难排查问题。

更麻烦的是，模型能力本身还在变化。

今天模型不会自己处理的事，你可能要写进 harness；明天模型会了，那段 harness 可能就变成多余约束。Anthropic 工程文章里提到过类似例子：以前为了处理模型接近上下文限制时过早结束任务的问题，需要在框架里做 context reset；但更强的模型出现后，这类逻辑可能就变成 dead weight。

所以四个对象真正解决的，不只是“怎么把 Agent 跑起来”。

它解决的是：当模型能力、工具形态、沙箱环境都在变化时，哪些接口应该尽量稳定。

如果再结合 Anthropic Engineering 的文章《Scaling Managed Agents: Decoupling the brain from the hands》，这条线会更清楚。

Anthropic 工程文章里，我觉得最值得看的核心，是一个更底层的思路：

接口要稳定，实现可以替换。

模型会变强，harness 会过时，sandbox 也会换。但只要 session、harness、sandbox 之间的接口足够稳，上层应用就不用跟着每一次底层调整一起重写。

这就是 Managed Agents 更像运行底座，而不是普通 API 的原因。

他们把 Agent 运行系统拆成三层：

• Brain：Claude 和 harness，也就是负责推理、规划、路由工具调用的部分；
• Hands：sandbox 和 tools，也就是真正执行动作的部分；
• Session：append-only 的事件日志，也就是任务推进过程中发生过什么。

这个拆分背后的工程直觉很朴素：不要让任何一个容器、任何一个 harness、任何一次运行成为不能死的“宠物”。

早期做法是把 session、harness、sandbox 都塞进同一个容器。好处是简单，坏处是耦合。

容器挂了，session 可能丢。

harness 卡住，工程师很难判断是工具问题、网络问题、容器问题，还是 Claude 的调用循环问题。

更麻烦的是，当客户希望把 Agent 连接到自己的 VPC 或业务环境时，一个写死在容器里的 harness 很快会变成限制。

Managed Agents 的方向是把 Brain、Hands、Session 解耦。容器可以挂，harness 可以重启，只要 session log 还在，就能从事件历史恢复。

这就是为什么我更愿意把它看成运行底座，而不是 API。

API 是入口。

运行底座才是长期运行、可恢复、可追踪、可治理的那层系统。

如果前面那条主线是“Agent 从会话对象变成工作对象”，这一节就是它的工程落点。

工作对象不能只靠聪明。

它还需要工位、记录、权限、恢复机制，以及能被别人检查的过程。

图：把 Agent、Environment、Session、Events 分开看，才能看清它托管的是一套运行系统，而不是单次模型调用。

官方工程文章还给了一个很有意思的性能观察：把 Brain 和 Hands 解耦后，首 token 延迟的 p50 降低约 60%，p95 降低超过 90%。

这个数字不要误读成“所有业务都会快 90%”。它更准确地说明了一个工程点：不用一开始就等容器和沙箱全部准备好，推理可以更早启动，执行环境按需连接。

这类收益，只有当 Agent 被当成长期运行的工作对象时，才会变得很明显。

几个案例里的方向

有意思的是，官方博客没有只讲抽象概念，而是很快把几个早期客户放了出来。

这不是普通的客户背书。

这些案例分别对应了几条 adoption path：协作产品、任务管理、组织内部 specialist agents、代码修复闭环、应用生成平台。

换句话说，Anthropic 不是只在说“开发者可以用 API 造 Agent”。

它在暗示另一件事：

未来很多成熟产品，都会在自己的 workflow 里塞进一个能长期运行的 Agent。

Notion：把 Agent 放进工作空间

官方博客里说，Notion 让团队可以直接在 workspace 里把任务委派给 Claude。多个任务可以并行运行，团队还能一起协作产出。

这说明 Notion 不是把 Managed Agents 当成另一个聊天框。

它更像是在协作产品里加了一层任务委派系统：用户不只是问问题，而是把开放式任务交出去，让 Agent 在工作区里持续推进。

这类产品真正怕的是：任务跑到一半断掉、状态丢失、多人协作看不到过程、输出不可追踪。

Managed Agents 正好补这层。

Asana：Agent 变成团队里的任务执行者

Asana 的方向更像“AI Teammates”。

官方材料里的说法是，Agent 在 Asana 里像团队成员一样接任务、做任务。基础设施交给 Managed Agents 后，Asana 可以把更多工程时间放到多人协作体验上。

这里的重点不是“AI 会不会写一段总结”。

重点是它进入了任务系统。

进入任务系统后，Agent 就不再是一个孤立工具，而要遵守任务分配、进度、协作、权限、产出验收这些产品规则。

这也是为什么通用 Agent 运行底座和垂直产品体验会分层。

底层运行底座越托管，上层产品越要回答一个问题：这个 Agent 到底在我的业务流程里扮演什么角色？

Rakuten：组织级 specialist agents

Rakuten 的案例更偏组织内部部署。

官方博客里提到，他们给产品、销售、市场、财务等部门部署 specialist agents，每个在一周内完成。

这说明 Managed Agents 的另一个价值是缩短“把一个专用 Agent 放进组织”的周期。

以前公司想做这种事，往往要先搭沙箱、管权限、接 Slack 或 Teams、处理文件、处理凭证、做日志、做错误恢复。

现在这层被平台托管以后，团队可以把精力放在 specialist agent 本身：

• 它懂哪个部门的业务？
• 能用哪些内部系统？
• 输出什么才算成功？
• 谁有权让它做什么？
• 出错时谁来复核？

注意，这些问题不会因为 Managed Agents 出现而消失。

它们只是从“基础设施问题”变成了“业务与治理问题”。

Sentry：从发现问题到直接开 PR

Sentry 的案例非常典型。

它把 Seer 的 root-cause analysis 接到一个 Claude-powered agent，让它写修复代码并打开 PR，而不是停在“旁边解释一下”。

这条链路里，Agent 已经进入软件工程的闭环：

发现问题 -> 定位原因 -> 写修复 -> 打开 PR -> 进入 review。

这也是 coding agent 这半年跑得最快的原因。

代码场景天然有几个优势：

• 有明确文件和仓库边界；
• 有测试、lint、CI；
• 有 PR review 流程；
• 有较清楚的回滚和审计机制。

所以 coding agent 很容易先进入生产。

但这不代表金融、法律、医疗、财务审批也能照搬。高风险领域还需要更强的授权模型、验证机制和人类复核协议。

Vibecode：把复杂运行底座下沉给更多开发者

Vibecode 的案例更接近开发工具和应用生成。

官方博客里说，开发者可以用 Managed Agents 更快拉起 agent infrastructure，从 prompt 到 deployed app，不再花几周搭基础设施。

这类场景会直接改变很多产品的成本结构。

当运行底座被托管，产品竞争会更靠近用户意图表达、交付体验、模板质量、部署链路和结果验证。

也就是说，底层能力越来越像云服务，上层产品要更懂场景。

重新定义

这次发布后，一个很自然的讨论是：很多 Agent startup 会不会被挤压。

这个判断有情绪，我会更谨慎一点看。

它不太可能让所有 Agent 公司突然失去价值。

但它确实会重新定价一类东西：通用 Agent infra。

如果一个产品只是在卖这些东西：

• 自己封一层 agent loop；
• 给模型接几个工具；
• 做一个通用沙箱；
• 存一下会话状态；
• 做一点粗粒度日志；
• 再包装成“企业级 Agent 平台”。

那它的空间确实会被压缩，而且压缩得会很快。

因为大模型公司开始把这层变成平台能力。

这也是让人不太舒服的地方。

以前很多团队还可以说：模型公司只管模型，我们在外面做 Agent infra。

现在 Anthropic 的动作更像是在说：模型外面那层最通用、最基础、最难自建的运行底座，我也要管。

但我不认为“Agent 公司都完了”。

我更倾向于另一个判断：通用 infra 的差异化会变薄，垂直领域的 harness 会变得更值钱。

金融 Agent 不是会调工具就够了。

它需要 mandate state，也就是这次授权到底允许花多少钱、买什么、什么时候必须停下来问人。

法律 Agent 不是能读合同就够了。

它需要 compliance harness，知道哪些条款能自动标注，哪些必须交给律师确认，哪些输出不能被写成法律意见。

医疗 Agent 更不用说。

它需要权限隔离、审计日志、human-in-the-loop，以及更严格的数据边界。

这才是后面更值得做的部分。

模型越来越通用，Agent 产品反而要越来越专用。

这句话听起来有点反直觉，但工程上很正常。

底座越标准，差异越容易往业务边界上走。云厂商把机器、网络、数据库托管掉以后，真正值钱的是你能不能把它放进一套稳定的业务系统里。

Agent 也会走类似的路。

乾坤未定

截至 2026 年 4 月 9 日，官方文档里，Managed Agents 仍是 beta。相关 API 需要 managed-agents-2026-04-01 这个 beta header。

官方资料里，有几项很容易被拿来做标题的能力，仍然需要单独看待：

• outcomes
• multiagent
• memory

这意味着它们还不能被写成完全稳定、默认可生产依赖的能力。

尤其是 memory，不能简单写成“开箱即用的长期记忆”。官方客户案例会提到长期任务和 memory，但具体到自己系统里怎么保留、怎么召回、怎么审计，仍然要按文档和实际 API 能力确认。

按官方文档表述，Managed Agents beta 对 API accounts 默认开启，可以通过 Console、API、CLI 进入；但 research preview 能力需要申请访问。现实里，不同账号、组织、区域和控制台入口，也可能影响你能不能马上看到完整能力。

所以这里不做实测结论。

我更愿意把它看成一个产品和架构信号：Anthropic 已经明确把 Agent 的运行底座纳入 Claude Platform，而不是只把 Claude 当作模型 API 出售。

成本也要算全。

官方价格不是“只要 0.08 美元每小时”。

更准确的说法是：

标准 Claude Platform token 费用 + 活跃运行时长的 $0.08 / session-hour + 可能的工具成本。

如果任务短、调用少，这笔钱可能很便宜。

如果你让很多 Agent 24 小时跑，尤其还用更贵的模型和外部工具，成本会很快变得不可忽视。

还有一个边界：它不是零代码工具。

普通用户可能会通过 Notion、Asana、Jira 这类协作产品间接用到类似能力。但如果要直接用 Claude Platform API 搭自己的 Agent，还是需要懂 API、权限、环境配置和业务系统集成。

看得见的和看不见的

这里我想到之前大年初二写过的一篇文章，里面借巴斯夏的框架讲过一个判断方法：看技术变化时，不能只看“看得见的影响”，还要看“暂时看不见的影响”。

看得见的影响，是一批通用 Agent 基础设施会被压缩。

如果一个产品只是封一层 loop，接几个工具，做一个沙箱，存一下会话状态，再加一点日志，那它确实会面对更强的平台压力。

这也是很多人第一眼会看到的部分。

但看不见的影响，可能更重要。

当这层底座变便宜、变标准、变容易获得以后，更多团队会把注意力从“怎么先搭一个能跑的 Agent 框架”，转向“这个 Agent 到底能不能接住一类真实工作”。

问题会变成：

• 哪些工作值得交给 Agent？
• 哪些动作必须留给人？
• 什么叫完成？
• 失败以后谁接手？
• 这个 Agent 在组织流程里扮演什么角色？

这些问题没有 Managed Agents 也存在，只是过去很多团队还没走到那里，就已经被沙箱、状态、权限、错误恢复拦住了。

如果说这次有什么让我恍然大悟的地方，就是这里：

Agent 产品的竞争，不会停在“谁先把框架搭出来”，而会更快进入“谁更懂工作本身”。

这和《大年初二聊AI：恐惧才是最大的风险》里讲的逻辑是一致的。

技术把某件事变便宜以后，真正值得看的，不只是它压缩了谁的旧工作，还包括它让哪些新工作、新产品、新组织方式变得可能。

写在最后

Claude Managed Agents 的发布，让我重新整理了一下对 Agent 的判断。

过去我们经常把 Agent 的问题归到模型身上。

模型不够聪明，所以 Agent 不稳定。

模型上下文不够大，所以长任务跑不完。

模型工具调用不够准，所以业务流程接不进去。

这些当然都是真问题。

但 Managed Agents 提醒我们，还有一个更基础的问题：当模型已经足够强时，你有没有一套能让它长期运行、可恢复、可追踪、可控、可审计的系统？

Anthropic 这次给出的答案，是把这层托管出来。

这不代表所有团队都要立刻迁过去。

我也不觉得自建运行底座从此没有意义。大客户、强合规、深度私有化、特殊网络环境，仍然会有自己的系统诉求。

但它确实提醒我们：接下来做 Agent 产品，光会调模型已经不够了。

更值得研究的是任务边界、工具权限、状态恢复、验证闭环和业务交付。

如果只记住一句话，我会记这个：

Agent 的下一步，是从“能回答问题”走向“能接住一项工作”。

真正的竞争，会从“我也有一个 Agent”转向“我的 Agent 能不能稳定地完成一类真实工作”。

参考资料

• Anthropic 官方博客：Claude Managed Agents: get to production 10x faster
https://claude.com/blog/claude-managed-agents
• Claude API Docs：Claude Managed Agents overview
https://platform.claude.com/docs/en/managed-agents/overview
• Anthropic Engineering：Scaling Managed Agents: Decoupling the brain from the hands
https://www.anthropic.com/engineering/managed-agents
• Claude API Docs：Pricing
https://platform.claude.com/docs/en/about-claude/pricing

往期相关

如喜欢本文，请点击右上角，把文章分享到朋友圈

如有想了解学习的技术点，请留言给若飞安排分享

因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享

·END·

1 2	``` 相关阅读：


- [刚刚，Claude Code“代码泄露”背后：如何重新看 Agent Harness](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408930&idx=1&sn=2fd7f3701ae8688e7720f80bb8296936&scene=21#wechat_redirect)
- [大家都在讲 Harness，但它到底该怎么理解](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408900&idx=1&sn=93bbae7c90fc03fb510f450c6fee97e0&scene=21#wechat_redirect)
- [模型越来越强，为什么大家却开始重写 Harness](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408891&idx=1&sn=639dc4a7c8482f6e1ac04d8d53c63459&scene=21#wechat_redirect)

- [如何让单个 Agent 做长任务不失真：Anthropic 给出了一套更工程化的答案](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408877&idx=1&sn=d27eb9e99ed526e342df775f0291cb2e&scene=21#wechat_redirect)
- [Claude Code高手的 8 个 Claude Code 实战习惯](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408884&idx=1&sn=6a2fa56f70f15cdd75eb5c2b12e687ef&scene=21#wechat_redirect)
- [别从 README 开始：一个架构师会怎样翻 Codex 仓库](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408870&idx=1&sn=ba53595a44ab55396b36795fbc78791b&scene=21#wechat_redirect)
- [Spec 不是代码的替代品，它是 AI Coding 的上下文管理层](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408860&idx=1&sn=b882b2ee97e3f798fea96e68d27c7071&scene=21#wechat_redirect)
- [如何让 Agents 自己设计、升级 Agents](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408848&idx=1&sn=aabf785116e9849dbd301a4f7c477181&scene=21#wechat_redirect)
- [OpenAI怎么把开源项目维护做成工作流：Skills、AGENTS.md 和 CI 的一套组合拳](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408832&idx=1&sn=ef00408738c853ea2e94be58c0612e51&scene=21#wechat_redirect)
- [Claude Skills 入门：把“会用 AI”变成“可复制的工程能力”](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408200&idx=1&sn=2f2cce7dfcbdb0766eac3590f777a17b&scene=21#wechat_redirect)
- [一套可复制的 Claude Code 配置方案：CLAUDE.md、Rules、Commands、Hooks](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408189&idx=1&sn=7d4f7a442a22af37f95c46ff1048a3df&scene=21#wechat_redirect)
- [Claude Code 最佳实践：把上下文变成生产力（团队可落地版）](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408183&idx=1&sn=0b6f1437465d3a61118db688cc889b17&scene=21#wechat_redirect)
- [把 AI 当成新同事：Agent Coding 的上下文与验证体系](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408169&idx=1&sn=7bba1377a31ffa0ce68932935c8d923a&scene=21#wechat_redirect)
- [一周写百万行的背后：Cursor长时间运行 Agent 的工程方法论](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408161&idx=1&sn=85aaff6f2f779e53b6ae9c5e1f003269&scene=21#wechat_redirect)
- [2026年生活重启指南](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408141&idx=1&sn=e1e64ad73d25414957aa5206ca969fc3&scene=21#wechat_redirect)
- [我真不敢相信，AI 先加速的是工程师。](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408153&idx=1&sn=d33b48464de93a2573a0a0cb025ada9e&scene=21#wechat_redirect)
- [扒一扒 Claude Cowork 系统提示词：Anthropic 如何打造数字同事](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408128&idx=1&sn=1b6c640de61986d1364847bffb2cd28f&scene=21#wechat_redirect)
- [Cowork 安全架构深度解析：从 Claude Code 到 Cowork，Anthropic 如何把“可控”做成产品](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408114&idx=1&sn=29a754281cd07c16b6191c6d146c5837&scene=21#wechat_redirect)
- [Anthropic官方万字长文：AI Agent评估的系统化方法论](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408107&idx=1&sn=905552d68f5b174fd9548360bdea4448&scene=21#wechat_redirect)
- [银弹还是枷锁？Claude Agent SDK 的架构真相](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408084&idx=1&sn=82f274ba084f9c289e2d141aad0c088b&scene=21#wechat_redirect)
- [Claude Code创始人亲授13条使用技巧](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408076&idx=1&sn=f139e90d699b528e80e79c558eed42ee&scene=21#wechat_redirect)
- [Claude Code 内部工具开源 code-simplifier：终结 AI 屎山代码的终极方案](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650408028&idx=1&sn=3a8571a9fa0bd5d7e59cd66fc6187b3e&scene=21#wechat_redirect)

> 版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!

**架构师**

我们都是架构师！

![图片](/images/Claude-Managed-Agents-详解Anthropic-为什么要托管-Agent-运行底座/5ae8c7bad256.jpg)

> 本文转载自微信公众号，如有侵权请联系删除。