Anthropic Managed Agents 架构解析：状态、凭证与计费的工程真相

1. 项目概述：当“运行时”开始自我坍缩

我第一次在 Slack 里看到那条内部消息时，正调试一个卡在第七步的财务对账 agent。消息标题很平静：“Anthropic Managed Agents 公开 Beta 上线”。但下面附的工程博客链接，我点开只看了三段就关掉了——不是因为没兴趣，而是太熟悉了。那种熟悉的、带着轻微焦虑的熟悉感，就像十年前第一次看到 AWS Lambda 的发布邮件：眼前摆着一块刚切好的蛋糕，而你手里的刀，正慢慢变钝。

这根本不是什么“全新品类”的诞生。它是一次精准的防御性落子，一次对正在加速坍缩的基础设施层的紧急占位。关键词里那个“Towards AI - Medium”，恰恰是问题的注脚：整个行业还在用 Medium 风格的叙事框架去理解这件事，而现实早已跑到了下一个版本。Managed Agents 是什么？它是一套被精心包装的、关于“状态存哪”和“凭证放哪”的工程答案。它解决的不是“agent 能不能做”，而是“做了之后，东西丢不丢、钱花不花、锅谁来背”。

如果你是刚接触 LLM 应用开发的工程师，或者正评估是否要自建 agent 平台的技术负责人，这篇文章就是为你写的。它不讲概念，不画蓝图，只拆解那些藏在 YAML 文件背后、写在沙箱日志里、刻在采购合同上的真实约束。我会告诉你为什么 Anthropic 的 session-as-event-log 不是炫技，而是去年我们团队在凌晨三点重写状态管理模块时流下的血泪；为什么 credential 隔离那几行配置，比你花三天调优的 system prompt 更能决定这个 agent 能不能上生产；以及最关键的一点——当你今天签下第一份 Managed Agents 的账单时，你真正买下的，到底是一块地基，还是一张通往更高楼层的电梯票。

这不是一篇关于“Anthropic 又发布了什么”的新闻稿。这是给所有正在把 agent 推向真实业务场景的人，一份基于真实踩坑记录的生存指南。接下来的内容，每一句都来自我和团队过去 18 个月在金融、电商、SaaS 客服三个垂直领域落地 agent 的实操现场。没有假设，只有结果；没有愿景，只有账单。

2. 架构解构：剥离营销话术后的三层真相

所有关于 Managed Agents 的报道，都绕不开那个操作系统类比：session 是虚拟内存，harness 是 CPU 指令集，sandbox 是硬件抽象层。这个比喻很美，但美得有点危险——它容易让人忽略一个残酷事实：操作系统之所以成为“系统”，是因为它上面长出了 Windows 和 Linux 这样的生态。而今天的 agent runtime 层，连自己的“DOS”都还没统一。Anthropic 的架构设计，本质上是在回答三个相互咬合、但又必须分开看的工程问题。我把它们拆成三层，一层一层剥给你看。

2.1 第一层真相：状态存储的范式迁移——从“上下文即数据库”到“事件日志即真相”

去年 Q3，我们为一家券商搭建了一个跨市场行情分析 agent。它的任务是：拉取 A 股、港股、美股三地的实时行情，识别异常波动，生成简报，并触发风控规则。流程设计得很清晰：数据获取 → 异常检测 → 归因分析 → 简报生成 → 规则触发。我们用了当时最主流的 LangChain + Redis 缓存方案，把每一步的中间结果（原始数据、检测阈值、归因逻辑链）都塞进模型的 context window 里，靠 prompt 工程让模型“记住”自己干过什么。

前 35 分钟一切顺利。第 36 分钟，当 agent 开始处理第 17 个股票代码时，context window 溢出了。模型没有报错，没有中断，它只是……悄悄地把最早拉取的 A 股数据从上下文里抹掉了。然后，它用剩下的港股和美股数据，结合一个被截断的归因逻辑，生成了一份“看起来非常专业”的简报。这份简报里，把某只港股的异动错误归因到了一只根本没出现在本次分析列表里的 A 股上。更糟的是，因为所有状态都在 context 里，我们没有任何日志能回溯这个错误是如何发生的。我们只能看着监控告警，像考古学家一样，在一堆 token 输出里徒劳地寻找线索。

Anthropic 的 session-as-event-log，就是为这种安静的灾难而生。它强制把“发生了什么”（what happened）和“模型怎么想的”（how the model reasoned）彻底分离。每一次 tool call、每一次用户输入、每一次模型输出，都被序列化为一条不可变的、带时间戳和唯一 ID 的事件记录，持久化到 Anthropic 托管的、独立于模型推理的存储中。Harness（那个 stateless 的执行器）本身不存任何状态，它只负责根据当前 event log 的最新快照，调用模型，然后把新产生的事件追加进去。

提示：这个设计带来的第一个硬性约束是——你的 agent 逻辑必须是“事件驱动”的，而不是“状态驱动”的。你不能再写 if last_result['status'] == 'error' then retry 这样的代码。你必须写 on event(type='tool_call_failed', tool='fetch_stock_data') then trigger_retry_logic 。这听起来是小改动，但会倒逼你重构整个 agent 的控制流。

2.2 第二层真相：凭证隔离的物理边界——从“环境变量即明文”到“沙箱即黑盒”

Credential 泄露，是 agent 生产环境中最隐蔽也最致命的风险。去年底，我们一个客户的服务台 agent 在测试环境里，因为一个未关闭的 debug 日志开关，把整个 AWS IAM Role 的临时凭证，以明文形式打印在了 CloudWatch 日志里。这个日志被一个自动化审计脚本抓取，上传到了一个第三方 SaaS 平台。所幸发现及时，没造成实际损失，但整个安全审计流程拖了六周。

Anthropic 的 sandbox 设计，其核心安全哲学是“零信任注入”。它不把 API Key、数据库密码、OAuth Token 这些敏感信息，作为环境变量（env var）注入到沙箱容器里。相反，它把这些凭证，预先注册到 Anthropic 自己的密钥管理服务（Vault）中，并为每个 sandbox 分配一个唯一的、短期有效的访问令牌（access token）。当 agent 在 sandbox 内部需要调用某个工具（比如 send_email ）时，它不是直接拿着 API Key 去请求，而是向 Anthropic 的 harness 发起一个受控的 execute('send_email', {to: 'user@domain.com', body: '...'}) 调用。Harness 收到后，用自己的 access token 去 Vault 换取真实的凭证，再以完全隔离的方式完成网络请求，最后只把结果（成功/失败 + 返回体）返回给 sandbox。

注意：这意味着你无法在 sandbox 内部执行任意的 curl 或 requests.get() 。所有对外部系统的访问，必须通过 Anthropic 预定义或你注册的工具（tool）来完成。这牺牲了绝对的灵活性，但换来了可审计、可策略化、可熔断的安全基线。对于金融、医疗等强监管行业，这个 trade-off 是值得的。

2.3 第三层真相：定价模型的隐含契约——从“按 token 计费”到“按状态生命周期计费”

Anthropic 的定价公式很简单：$0.08 / session-hour + 标准 Claude token 费用。但这个“session-hour”藏着一个关键细节：它计算的是“active runtime time”，不是“wall-clock time”。一个 session 可以持续数天，但只要它处于 idle 状态（比如等待用户回复、等待外部 API 回调），这段时间是不计费的。只有当 harness 正在执行模型推理、调用工具、处理事件时，才会计入 session-hour。

我们做过一个压力测试：创建一个 session，让它循环执行一个空的 noop 工具（不耗时、不耗资源），间隔 5 秒一次。连续运行 24 小时，总 session-hour 消耗是 0.02 小时（约 1.2 分钟），因为绝大部分时间它都在 idle。而如果让它每秒都发起一次 fetch_current_time 工具调用，24 小时下来，session-hour 就飙升到了 23.8 小时。

这个设计暴露了 Anthropic 的真实意图：它在鼓励一种“事件密集型、而非轮询密集型”的 agent 设计模式。它希望你的 agent 是被动响应的（waiting for user input, waiting for webhook），而不是主动 polling 的（checking database every 10s）。这与 AWS Bedrock AgentCore 的“按 invocation 计费”（每次调用都收费）形成了鲜明对比。前者赌的是 agent 的“智能性”（能等、会等、知道什么时候该醒），后者赌的是 agent 的“可用性”（随时都能叫，叫了就干活）。

3. 实操解析：从 YAML 定义到生产部署的完整链路

理论讲完，现在进入最硬核的部分：你拿到 Anthropic Managed Agents 的文档，准备动手写第一个 agent，会发生什么？我不会给你抄一段官方示例，而是带你走一遍我们为一家跨境电商客户落地的“智能退货助手” agent 的完整构建过程。这个过程覆盖了从需求分析、YAML 编写、沙箱调试，到灰度上线、监控告警的每一个真实环节。

3.1 需求到 YAML：如何把业务逻辑翻译成机器可读的契约

客户的核心诉求很明确：当用户在 App 里提交退货申请时，agent 要自动完成三件事：1）查询该订单的物流状态和商品库存；2）根据公司退货政策（如：发货超 30 天不退、定制商品不退）判断是否可退；3）如果可退，生成退货标签并发送邮件。整个过程需要在 90 秒内完成，且所有操作必须留痕，供客服事后复盘。

我们没有直接写 prompt，而是先画了一张“事件-动作”映射图：

• event: user_submitted_return_request → action: fetch_order_status, fetch_inventory
• event: order_status_fetched, inventory_fetched → action: evaluate_return_policy
• event: policy_evaluation_passed → action: generate_return_label, send_confirmation_email
• event: policy_evaluation_failed → action: send_rejection_notice

这张图，就是我们 YAML 文件的骨架。以下是核心部分的精简版（省略了详细的 schema 定义）：

# agent.yaml
name: "ecommerce-return-assistant"
description: "Handles customer return requests end-to-end"

# 系统级指令，定义 agent 的“人设”和底线
system_prompt: |
  You are a helpful, precise, and policy-compliant return assistant for Acme Corp.
  NEVER make up order status or inventory data. ALWAYS rely on the tools.
  If any tool fails, report the error to the user clearly. NEVER hallucinate.

# 定义 agent 能调用的所有工具（Tools）
tools:
  - name: "fetch_order_status"
    description: "Fetches real-time shipping status and delivery confirmation for an order ID."
    input_schema:
      type: "object"
      properties:
        order_id:
          type: "string"
          description: "The unique identifier of the order."

  - name: "fetch_inventory"
    description: "Checks current stock level and availability for a product SKU."
    input_schema:
      type: "object"
      properties:
        sku:
          type: "string"

  - name: "evaluate_return_policy"
    description: "Determines if a return is allowed based on order date, item type, and company policy."
    input_schema:
      type: "object"
      properties:
        order_date:
          type: "string"
          format: "date"
        item_type:
          type: "string"
          enum: ["standard", "custom", "perishable"]

# 定义 agent 的“守门员”——Guardrails
guardrails:
  # 防止越权访问
  - type: "tool_access_control"
    allowed_tools: ["fetch_order_status", "fetch_inventory", "evaluate_return_policy"]
    denied_tools: ["*"] # 默认禁止所有未显式允许的工具

  # 防止敏感信息泄露
  - type: "output_filtering"
    patterns:
      - "regex": ".*[A-Z]{2}[0-9]{6}.*" # 匹配可能的身份证号
      - "regex": ".*\\d{3}-\\d{2}-\\d{4}.*" # 匹配可能的社会安全号

# 定义 agent 的“记忆”规则（Session State）
session_state:
  # 明确指定哪些事件字段需要被持久化到 event log
  persistent_fields:
    - "order_id"
    - "sku"
    - "order_date"
    - "item_type"
    - "policy_decision"

实操心得：YAML 里的 persistent_fields 是灵魂。我们最初漏掉了 order_date ，导致在 evaluate_return_policy 工具里，模型无法拿到这个关键参数，只能反复询问用户。后来我们加了一条 rule： 任何在后续步骤中会被其他工具或决策逻辑依赖的字段，必须无一例外地列在这里。 这不是可选项，是强制契约。

3.2 沙箱调试：在隔离环境中验证你的“数字员工”

YAML 写完，下一步不是直接上线，而是进入 Anthropic 提供的 Web-based Sandbox。这个沙箱不是模拟器，它是一个真实的、与生产环境同构的微型 runtime。你可以在这里：

1. 手动注入初始事件 ：模拟用户提交退货请求，传入 {"order_id": "ORD-12345", "sku": "SKU-67890", "order_date": "2024-03-15"} 。
2. 单步执行 ：观察 harness 如何调用 fetch_order_status ，沙箱如何向我们的后端 API 发起请求，API 返回 {status: "delivered", delivered_at: "2024-03-18T14:22:00Z"} ，这个结果如何被解析并作为新事件写入 event log。
3. 强制故障 ：在 fetch_inventory 工具的 mock 响应里，故意返回一个 500 Internal Server Error 。观察 agent 是否按 guardrail 规则，优雅地降级，向用户发送“库存系统暂时不可用，请稍后再试”的提示，而不是崩溃或胡言乱语。

我们在这个阶段发现了两个关键问题：

• 问题一 ： evaluate_return_policy 工具的返回体里， policy_decision 字段是 "allowed" （字符串），但我们在 YAML 的 persistent_fields 里期望的是布尔值。这导致后续的 if policy_decision == true 判断永远为 false。解决方案：在工具的返回 schema 中，明确将 policy_decision 定义为 type: boolean ，并确保后端 API 严格遵守。
• 问题二 ：当 fetch_order_status 返回 delivered_at 时间戳时， evaluate_return_policy 工具需要计算 delivered_at 和 order_date 的差值。但我们的工具代码里，直接用了 JavaScript 的 Date.parse() ，而 Anthropic 的 sandbox 运行在 Python 环境下。解决方案：所有工具的输入/输出，必须是纯 JSON 可序列化的数据类型（string, number, boolean, array, object），绝不依赖宿主语言的特定 API。

注意：Sandbox 的日志是调试的黄金。它会精确记录： [Event ID: ev_abc123] -> [Tool Call: fetch_order_status] -> [Sandbox Log: Calling https://api.acme.com/v1/orders/ORD-12345/status] -> [Tool Response: {"status": "delivered", ...}] -> [New Event ID: ev_def456] 。这个链条，是你排查任何问题的唯一依据。

3.3 灰度上线与监控：让 agent 在真实流量中学会呼吸

上线不是“一键发布”，而是一个渐进式的“呼吸训练”。我们采用了三级灰度：

1. Level 1 (1% 流量) ：只对内部员工开放。所有返回结果都强制加上 [DEBUG] 前缀，并记录完整的 event log ID。目的是验证在真实网络延迟、真实用户输入（拼写错误、乱码、emoji）下的稳定性。
2. Level 2 (10% 流量) ：对 VIP 客户开放。此时关闭 debug 前缀，但所有 session 的 event log 都被同步到我们自己的可观测性平台（Arize）。我们重点监控两个指标： p95_session_duration （是否稳定在 85 秒内）和 tool_call_failure_rate （是否低于 0.5%）。
3. Level 3 (100% 流量) ：全量上线。此时，我们启用了 Anthropic 的 session_checkpoint 功能。它会在每个关键决策点（如 policy_evaluation_passed ）自动保存一个 checkpoint。如果用户在生成退货标签后突然退出 App，下次回来时，agent 可以直接从 generate_return_label 这个 checkpoint 恢复，而不是从头开始查订单。

实操心得：监控的关键不是“有没有错误”，而是“错误的模式”。我们发现，在 Level 1 阶段， tool_call_failure_rate 在每天上午 9:00-10:00 会有一个尖峰。排查后发现，是我们的库存 API 在这个时段有定时批处理任务，导致响应超时。这促使我们为 fetch_inventory 工具增加了重试逻辑和降级缓存。 Agent 的健壮性，是在真实世界的毛刺中打磨出来的，不是在完美的沙箱里设计出来的。

4. 竞争格局与价值迁移：为什么“运行时”注定走向零利润

Anthropic 的 Managed Agents 发布，被很多媒体解读为“AI Agent 操作系统”的诞生。但如果你把目光投向 AWS、Google、Microsoft 的动作，就会发现一个截然不同的图景：这不是一个新操作系统的启动，而是一场旧基础设施的集体“归零”运动。我用一张表格，把当前主要玩家的定位、优势和本质差异说清楚：

这张表揭示了一个冰冷的事实： 没有任何一家巨头，是把“agent runtime”当作一个独立、可盈利的业务来经营的。 Anthropic 需要它来锁住 Claude 的 token 消费；AWS 需要它来提升客户在云上的整体粘性和 spend；Google 和 Microsoft 需要它来成为各自 AI 平台不可或缺的“最后一公里”。

这就解释了为什么“运行时”层注定走向零利润。它的经济模型，已经不再是“卖软件”，而是“卖管道”。管道的价值，不在于管道本身有多坚固，而在于有多少水流经它。当 AWS 可以把 AgentCore 的调用成本压到 $0.005，当 Google 把 Vertex 的 token 成本打到行业最低，当 Microsoft 把 Foundry 的使用权限直接打包进企业版 Office 365 时，“runtime”就完成了从“产品”到“水电煤”的蜕变。

那么，钱会流向哪里？答案就在我们为客户搭建的那个“智能退货助手”的生命周期里。

• 第一笔钱 ，付给了 Anthropic（token 费 + session-hour）。
• 第二笔钱 ，付给了 Arize（我们购买了他们的商业版，用于存储和分析所有 session 的 event log，因为 Anthropic 的原生日志只保留 30 天）。
• 第三笔钱 ，付给了 Salesforce（客户采购了 Agentforce 的“电商退货合规包”，里面预置了 200 条退货政策规则和对应的审计模板）。
• 第四笔钱 ，付给了我们自己（作为咨询方，我们收取了“政策规则引擎定制开发”的费用）。

常见问题速查表：

问题	排查思路	解决方案	我们的实操经验
Session 启动缓慢（>5s）	检查 system_prompt 长度和复杂度；检查首次 tool_call 的网络延迟	将 system_prompt 中的冗余说明删减 30%；为高频工具（如 fetch_order_status ）配置 CDN 缓存	我们发现， system_prompt 超过 1200 token 后，TTFB 会呈指数级增长。砍掉所有“欢迎语”和“免责声明”，只留核心指令。
Tool Call 随机失败（5xx）	检查沙箱 outbound 网络策略；检查工具 endpoint 的 TLS 证书是否为 Anthropic 信任的 CA 签发	在工具 endpoint 前加一层 Cloudflare，启用其 Universal SSL；或使用 Anthropic 推荐的 Let's Encrypt 证书	Anthropic 的 sandbox 默认只信任主流 CA。我们一个客户的私有 CA 签发的证书，导致 100% 的 tool call 失败，花了两天才定位。
Event Log 丢失关键字段	检查 YAML 中 persistent_fields 是否遗漏；检查工具返回体是否包含该字段	使用 JSON Schema Validator 工具，对每个工具的 input_schema 和 output_schema 进行强制校验	我们编写了一个 CI 脚本，在每次提交 YAML 前，自动校验所有 persistent_fields 是否在至少一个工具的 output_schema 中被定义。
Pricing 超出预期	检查是否有长周期 idle session 未被正确关闭；检查是否有工具在循环中无意义地调用	在 agent 逻辑中，加入 if no_user_input_for > 300s then close_session 的兜底逻辑；为所有工具添加 max_retries: 2	我们发现，一个未处理的 timeout 错误，会导致 session 一直保持 open 状态，即使用户早已离开。一个 session 持续了 72 小时，产生了 $5.76 的费用。

5. 未来推演：当“运行时”归零后，真正的战场在哪里

“运行时”走向零利润，不是终点，而是起点。它像一块被抽走的地板，迫使所有人向上攀爬，去争夺那些尚未被 commoditize 的、真正创造价值的上层空间。基于我们过去一年在多个客户现场的观察，我认为未来的价值高地，将集中在以下三个方向，它们不是并列的，而是存在清晰的依赖关系。

5.1 第一层高地：可移植的“行为日志”（Trace Store）——Agent 的“行车记录仪”

当你的 agent 在 Anthropic 的 runtime 上跑了三个月，积累了 50 万条 session，然后客户突然说：“我们要迁移到 Azure Foundry，因为他们的合规认证更全。” 你怎么办？把那 50 万条 event log 导出来，再导入 Azure？别做梦了。Anthropic 的 event log 格式、字段命名、序列化方式，和 Azure 的 trace API 完全不兼容。你面对的，不是数据迁移，而是数据格式战争。

这就是 Braintrust、Arize、LangSmith 这些公司正在疯狂押注的战场。它们卖的不是一个 dashboard，而是一个“通用日志协议”。Brainstore 的核心创新，是定义了一套 ai-interaction-log 的 OpenAPI Spec，它强制要求所有字段（ session_id , event_type , tool_name , input_hash , output_hash , latency_ms ）都必须存在，且类型固定。只要你用 Brainstore 的 SDK 来记录你的 agent 行为，无论你今天用 Anthropic，明天用 Bedrock，后天自己用 Kubernetes 部署一个 LangGraph，你的日志都能被同一个 Brainstore 实例解析、查询、分析。

个人体会：我们已经在两个客户项目中，强制要求将 Brainstore 的 SDK 作为 agent 构建的“第一依赖”。这意味着，哪怕客户最终选择自建 runtime，他们的行为日志也天然具备了可移植性。这笔前期投入，换来的是未来三年内，任何一次技术栈迁移的成本，从“数月”降低到“数天”。

5.2 第二层高地：可执行的“治理策略”（Governance & Policy）——Agent 的“交通法规”

一个 agent 能做什么，不能做什么，谁批准了它这么做，出了问题谁负责——这些问题，在今天，大多靠一份 PDF 文档和一个 Excel 表格来管理。这在 POC 阶段可行，但在生产环境，尤其是金融、医疗领域，这是灾难的温床。

AWS 在 March 2026 GA 的 AgentCore Policy Controls，是一个信号。它允许你用 YAML 定义策略，比如：

policy: "finance-data-access"
rules:
  - effect: "DENY"
    condition: "tool_name == 'fetch_customer_pii'"
    reason: "PII access requires explicit manager approval"
  - effect: "ALLOW"
    condition: "tool_name == 'fetch_account_balance' && user_role == 'customer_service_rep'"

但这只是开始。真正的治理，是能把这些策略，变成 agent 运行时的“肌肉记忆”。它需要和企业的 IAM 系统打通，能自动关联到具体的审批工单（ServiceNow ticket），能在 agent 执行高风险操作前，弹出一个带生物识别的二次确认。目前，还没有一家公司能提供端到端的解决方案。这是一个巨大的空白，也是资本正在疯狂涌入的方向。OWASP Agentic Top 10 的发布，就是给这个空白区域划出了清晰的边界。

5.3 第三层高地：可交付的“垂直合约”（Vertical Marketplace）——Agent 的“行业许可证”

Salesforce 的 Agentforce ARR 达到 $800M，这个数字背后，是一个深刻的洞察：企业愿意为“解决一个具体问题”的 agent 付费，而不是为“能跑 agent 的平台”付费。一个“医保理赔审核 agent”，一个“跨境税务申报 agent”，一个“半导体晶圆缺陷分析 agent”，它们的价值，不在于用了什么模型、什么 runtime，而在于它们能直接替代一个年薪 15 万美元的专家，并且准确率高出 20%。

这些垂直 agent 的核心壁垒，不是技术，而是 领域知识的封装 。它需要把几十年积累的理赔规则、税法条款、晶圆工艺参数，全部转化为 agent 可理解、可执行、可验证的逻辑单元。这正是 virattt/ai-hedge-fund 和 vxcontrol/pentagi 这些开源项目的价值所在——它们不是在造轮子，而是在为未来的垂直市场，提供第一批可复用的“知识积木”。

最后分享一个小技巧：如果你正在创业，想切入 agent 市场，我的建议是， 立刻放弃“做一个通用 agent 平台”的想法。 去找一个你真正懂的、有明确付费意愿的垂直行业（比如宠物保险、独立音乐人版权管理、小型律所的合同审查），用 Anthropic Managed Agents 快速做出一个 MVP，然后把你的核心价值，全部押注在“这个 MVP 背后的领域知识库”上。当 runtime 归零时，你的知识库，就是你唯一的、无法被复制的护城河。