1. 这不是新赛道，而是 runtime 层的“操作系统时刻”来了

上周二，4月8日，Anthropic 宣布 Claude Managed Agents 进入公开测试阶段。新闻稿里写满了“十倍提速”“Notion 和 Asana 已接入”“沙箱执行+会话快照+凭证托管由 Anthropic 全权负责”——这些词听着很熟，像极了五年前大家第一次听说 Kubernetes 的时候：一堆抽象名词堆在一起，但没人真说清楚它到底替你挡掉了什么、又悄悄扛起了什么。我干这行十年，从最早用 Flask 写 REST API 托管 LLM，到后来自己搭 LangChain 调度器、手搓 session 状态机、给 sandbox 做 credential 注入隔离，再到去年被一个跑了 37 分钟的 agent 无声无息地拖垮——它没报错，只是在第 42 轮 tool call 时开始把前 15 条搜索结果全记混，最后生成了一份逻辑自洽但事实全错的采购分析报告。我们花了两天回溯日志，才发现问题出在 context window 溢出后模型自动截断历史，而我们没留任何外部事件记录。那一次，我们不是丢了结果，是丢了整个推理过程的可追溯性。

这就是 Managed Agents 真正解决的问题：它不承诺“更聪明”，但确保“可复现、可审计、可恢复”。它把 agent 从一个依赖大模型上下文窗口的脆弱状态机，变成一个有独立生命周期、独立存储、独立安全边界的运行实体。关键词不是“agent”，而是 session-as-event-log —— 会话本身成为一条持久化、结构化、可查询的时间线； harness-as-stateless-executor —— 执行器退化为纯粹的调度胶水，只负责调用容器、传参、收字符串； sandbox-as-cattle —— 沙箱不再是个体化的宠物服务器，而是按需拉起、用完即焚的标准化计算单元。这三个设计选择，不是为了炫技，而是为了把过去三年里所有团队踩过的坑，一次性焊死在基础设施层。它面向的不是“想试试 agent 的产品经理”，而是“已经上线了 12 个生产级 agent、每天处理 47 万次 tool call、上个月因 credential 泄露被安全团队约谈两次”的工程负责人。如果你还在用 JSON 文件存 session history、用 dotenv 注入 API key、靠 retry + timeout 应对 context 溢出——那你不是在开发 agent，是在给运维埋雷。Managed Agents 不是让你更快上线第一个 demo，而是让你敢把第 101 个 agent 接进核心财务系统。

2. 核心设计拆解：为什么是这三个抽象，而不是别的？

2.1 Session 作为事件日志：不是存储层，而是事实层

Anthropic 把 session 定义为“脱离模型上下文的、持久化的、结构化事件流”，这个表述背后藏着三重工程判断。

第一层，是存储成本与语义价值的错配。传统做法把 session state 塞进 prompt，本质是把高价值的业务事实（用户原始请求、工具调用参数、返回结构化数据、决策依据链）和低价值的中间 token（模型生成的过渡句、格式填充词、冗余重述）混在同一块内存里。Claude 3.5 Sonnet 的 200K context 看似很大，但实际能承载的有效业务事件数非常有限。我们做过实测：一个标准的销售线索分发 agent，每轮包含 1 次 Slack 消息解析 + 2 次 CRM 查询 + 1 次邮件模板渲染，平均单轮产生 1800 tokens 的有效事件描述。当会话持续到第 87 轮，仅事件描述就占掉 156K tokens，留给模型思考和生成的空间只剩 44K——此时模型已无法完整回顾前 30 轮的客户偏好变更记录，开始基于局部片段做推测。这不是模型能力问题，是存储架构缺陷。

第二层，是故障域的不可控蔓延。当 state 与 model context 绑定，任何 context 溢出、token 截断、prompt 注入失败，都会导致整个 session 的语义完整性崩塌。更危险的是，这种崩塌是静默的：模型不会报错，它只是“合理地”遗忘或混淆。我们曾遇到一个客服 agent，在处理跨三天的退货纠纷时，因第 2 天下午的物流查询结果被截断，导致第 3 天模型误判“用户未提供物流单号”，直接触发退款流程。事后查日志，所有 API 调用都成功，所有返回数据都完整入库，唯独模型上下文里缺了那一行 tracking number。没有 event log，就没有归因路径。

第三层，是合规与审计的刚性需求。金融、医疗类客户明确要求“每个决策必须可回溯至原始输入、工具输出、人工审核点”。把 session 存在数据库里是一回事，把它作为不可篡改的事件流（类似区块链的 transaction log）写入专用存储，是另一回事。Managed Agents 的 event log 设计强制分离了“谁做了什么”（event）和“模型怎么想的”（reasoning），前者存于 Anthropic 托管的 durable store，后者留在 transient context 中。这意味着你可以审计“agent 是否在未获授权时调用了支付接口”，而无需解析上千行模型生成文本。

提示：不要把 event log 当作日志备份。它是你的业务事实真相源（source of truth）。当你需要回答“用户张三在 4 月 5 日 14:22 是否同意了合同条款”，答案必须来自 event log 的 approve_event，而不是模型最后一句“我已确认用户同意”。

2.2 Harness 作为无状态执行器：解耦调度与推理

Harness 在文档里被描述为“stateless executor that calls containers via execute(name, input) → string”，这句话的潜台词是： 它不理解业务，只认接口契约 。

我们拆开看这个 execute 接口的设计逻辑：

• name 是工具注册名，不是函数路径。这意味着 harness 不关心工具是 Python 函数、HTTP endpoint 还是 Docker container，只要它符合预定义的 OpenAPI schema。
• input 是严格校验的 JSON Schema 输入。我们在内部测试中故意传入带额外字段的 payload，harness 直接返回 400 并附带 schema mismatch 错误，而非转发给下游让工具崩溃。
• → string 是关键约束。它强制所有工具输出必须是纯文本（JSON string 或 Markdown），禁止二进制流、文件句柄、数据库连接等状态残留。这保证了每次 execute 都是原子操作，无副作用。

这种设计直接规避了三个高频痛点：

1. 框架锁定风险 ：你不用再为 LangChain 的 RunnableLambda、LlamaIndex 的 ToolNode、CrewAI 的 TaskExecutor 写适配层。只要工具暴露标准 HTTP 接口或容器入口，harness 就能调用。
2. 状态污染 ：传统 agent 框架常把数据库连接池、缓存 client、全局配置对象挂在 harness 实例上。当并发请求激增，连接池耗尽或配置被覆盖，错误难以复现。Managed Agents 的 harness 每次 execute 都是全新进程/容器，天然隔离。
3. 调试黑盒 ：过去排查 agent 卡顿，要同时看模型 token 流、工具响应时间、框架调度队列。现在你只需监控两件事：harness 的 execute 调用延迟（应 < 50ms），和 sandbox 的容器启动耗时（Anthropic 公布 p95 < 120ms）。其余环节全部下沉为黑盒，责任边界清晰。

我们实测过一个混合调用场景：同一 harness 同时调度 3 类工具——Python 编写的本地风控规则引擎（通过 FastAPI 暴露）、AWS Lambda 承载的 OCR 服务、以及部署在 GCP Cloud Run 上的 PDF 解析微服务。harness 对三者调用方式完全一致，错误码统一为 TOOL_EXECUTION_FAILED ，重试策略由 Anthropic 统一管理。这种一致性带来的运维效率提升，远超性能数字本身。

2.3 Sandbox 作为 cattle 式沙箱：凭证隔离是底线，不是加分项

“Sandbox as cattle, not pets” 这句话在技术圈被反复引用，但真正落地时，90% 的团队倒在 credential 隔离这一关。Managed Agents 的沙箱设计，把 credential 管理从“开发者的责任”升级为“平台的强制契约”。

它的实现机制很朴素：credential 不以环境变量、配置文件、或 API header 形式注入 sandbox，而是由 Anthropic 的 vault 服务在 sandbox 启动时，将加密后的凭证密钥（如 AWS IAM role ARN、Slack bot token 加密 blob）写入 sandbox 内部的 /run/secrets/ 目录（类 Unix 系统标准路径），并设置 strict file permission（仅 owner 可读）。工具代码若想使用凭证，必须显式读取该路径下的文件并解密——而解密密钥由 sandbox kernel 级别提供，应用进程无法获取。

这个设计解决了三个致命问题：

• 凭证泄露面最小化 ：传统方案中，如果 agent 被 prompt 注入攻击，攻击者可通过 os.environ 或 process.env 读取所有环境变量。Managed Agents 的 sandbox 内， env 命令输出为空， ls /run/secrets/ 列出的文件名是随机 UUID，且内容为加密 blob。即使攻击者获得 shell 权限，也无法直接提取明文凭证。
• 权限粒度可控 ：每个 sandbox 可绑定独立的 IAM role 或 OAuth scope。例如，处理客户数据的 sandbox 只授予 s3:GetObject 权限，而财务审批 sandbox 则拥有 dynamodb:UpdateItem 权限。权限变更无需重启 agent，只需更新 vault 中的 role 绑定。
• 审计可追溯 ：每次 credential 使用都会在 event log 中生成 credential_accessed 事件，包含 sandbox ID、工具名、访问时间、凭证类型。当安全团队问“4 月 6 日 Slack bot token 是否被异常调用”，你能在 3 秒内给出精确答案。

我们曾用 Burp Suite 对一个测试 sandbox 发起典型 prompt 注入攻击（注入 ; cat /proc/1/environ ），返回结果是空字符串。换用 ls -la /run/secrets/ ，看到一个名为 a7f3b9c1-2e4d-4f6a-8b1c-0e9d7f3a2b4c 的文件， cat 它则返回 decryption_failed: invalid signature 。这不是靠 obscurity，而是靠硬件级隔离（Anthropic 使用 Firecracker microVM）和密码学绑定。

注意：credential isolation 的前提是工具代码必须遵循 sandbox 的 secret 访问协议。如果你的工具硬编码了 API key 或从 dotenv 读取，Managed Agents 无法帮你兜底。这是开发者的契约义务，不是平台的魔法。

3. 实操落地：从 YAML 定义到生产环境的完整链路

3.1 Agent 定义：YAML 是契约，不是配置

Managed Agents 支持两种定义方式：自然语言描述（适合 PoC）和 YAML（生产必需）。这里只讲 YAML，因为它是唯一能表达完整契约的载体。

一个生产级 sales-agent.yaml 示例：

# sales-agent.yaml
name: "sales-lead-qualifier"
description: "Qualifies inbound leads from website forms and routes to appropriate sales rep"
version: "1.2.0"

system_prompt: |
  You are a senior sales operations analyst at Acme Corp.
  Your task is to qualify leads based on budget, timeline, and use case fit.
  Always output final decision in JSON format with keys: 'qualified', 'reason', 'next_step'.

tools:
  - name: "fetch_lead_data"
    description: "Fetch lead details from CRM by email"
    input_schema:
      type: "object"
      properties:
        email: { type: "string", format: "email" }
      required: [ "email" ]
    output_schema:
      type: "object"
      properties:
        name: { type: "string" }
        company: { type: "string" }
        budget_range: { type: "string", enum: ["<50k", "50k-200k", "200k+"] }
        timeline: { type: "string", enum: ["immediate", "3mo", "6mo+", "no_timeline"] }
        use_case: { type: "string" }

  - name: "assign_to_rep"
    description: "Assign qualified lead to sales rep based on territory and capacity"
    input_schema:
      type: "object"
      properties:
        lead_id: { type: "string" }
        territory: { type: "string" }
      required: [ "lead_id", "territory" ]
    output_schema:
      type: "object"
      properties:
        rep_name: { type: "string" }
        rep_email: { type: "string" }
        assignment_id: { type: "string" }

guardrails:
  - type: "output_format"
    config: { required_keys: ["qualified", "reason", "next_step"], json_only: true }
  - type: "pii_redaction"
    config: { fields: ["email", "phone", "address"] }
  - type: "tool_call_limit"
    config: { max_calls_per_session: 5, max_calls_per_tool: 3 }

runtime:
  timeout_seconds: 180
  memory_mb: 2048
  max_concurrent_sessions: 50

这个 YAML 的每个字段都是强契约：

• input_schema 和 output_schema 不是文档，是运行时校验规则。如果 fetch_lead_data 返回的 JSON 缺少 budget_range 字段，harness 会拦截并返回 TOOL_SCHEMA_VIOLATION ，不会让模型继续处理。
• guardrails 是硬性熔断器。 tool_call_limit 防止无限循环调用（我们曾见过一个 bug 导致 agent 对同一 lead 连续调用 17 次 CRM 查询）； pii_redaction 在 event log 写入前自动脱敏，避免审计风险。
• runtime 配置直接影响 billing。 memory_mb: 2048 对应 $0.08/session-hour 的基准价；若设为 4096 ，价格翻倍。这不是性能优化选项，是成本控制开关。

我们建议：所有生产 agent 必须通过 CI/CD pipeline 的 YAML Schema 校验（Anthropic 提供官方 JSON Schema），并在 staging 环境跑通 full-cycle test（从 webhook 接收模拟 lead，到生成 assignment_id，全程 event log 可查）。

3.2 会话生命周期管理：从 awake() 到 audit()

Managed Agents 的会话不是“启动即运行”，而是“按需唤醒、按量计费”。核心方法是 awake(sessionId) 。

会话状态流转图（非 Mermaid，文字描述）：

1. New ：首次调用 awake("sess_abc123") ，harness 拉起 sandbox，加载 agent 定义，初始化 event log。
2. Active ：收到用户消息，harness 调用模型，模型生成 tool call，harness 执行工具，结果写入 event log，返回响应。此状态按秒计费（$0.08/hour ≈ $0.000022/second）。
3. Idle ：连续 60 秒无新消息，会话进入 idle 状态，停止计费，但 event log 和 sandbox 状态保留（最多 7 天）。
4. Resumed ：新消息到达， awake() 重新激活，从上次中断的 event log 位置恢复上下文，无需重放历史。
5. Expired ：idle 超过 7 天，event log 归档，sandbox 销毁，sessionId 不可再用。

这个设计的关键价值在于 cost predictability 。我们测算过：一个日均处理 2000 条销售咨询的 agent，平均会话时长 4.2 分钟，其中 3.1 分钟处于 idle。若采用传统常驻进程模式，需 24/7 运行 2 个实例（防止单点故障），月成本约 $1,200；而 Managed Agents 模式下，月会话小时数 = 2000 × 4.2/60 ≈ 140 小时，费用仅 $11.20，且无 idle 成本。

实操中，我们封装了一个 SessionManager 类来处理唤醒逻辑：

class SessionManager:
    def __init__(self, anthropic_client):
        self.client = anthropic_client
    
    def handle_webhook(self, lead_data: dict):
        # 从 lead email 生成稳定 sessionId
        session_id = f"lead_{hashlib.sha256(lead_data['email'].encode()).hexdigest()[:8]}"
        
        # 尝试唤醒，若失败则新建
        try:
            response = self.client.awake(session_id, message=lead_data)
        except SessionExpiredError:
            response = self.client.create_session(session_id, agent_name="sales-lead-qualifier")
            response = self.client.awake(session_id, message=lead_data)
        
        return response
    
    def audit_session(self, session_id: str):
        # 直接查询 event log，无需解析模型输出
        events = self.client.get_event_log(session_id)
        # 过滤出关键事件
        tool_calls = [e for e in events if e.type == "tool_call"]
        decisions = [e for e in events if e.type == "model_output" and "qualified" in e.content]
        return {
            "total_steps": len(events),
            "tool_calls_made": len(tool_calls),
            "final_decision": decisions[-1].content if decisions else None,
            "pii_redacted": any("email" in e.content for e in events)
        }

audit_session() 方法展示了 event log 的真实价值：它让你在 10 行代码内完成传统需要日志聚合、ELK 分析、人工抽样的审计工作。

3.3 生产集成：如何与现有系统共存

Managed Agents 不是推倒重来，而是嵌入现有架构。我们以 Notion 的集成方式为蓝本，给出三个关键集成点：

1. 入口网关（Ingress Gateway）
Notion 用其官方 webhook 服务接收页面表单提交，然后调用 Anthropic 的 awake() 。我们建议：所有入口必须经过自己的 API 网关，做三件事：

• 请求签名验证（防止伪造 webhook）
• PII 预过滤（移除身份证号、银行卡号等强敏感字段，仅保留 email、company、use_case）
• 会话 ID 生成（用业务主键哈希，确保同一 lead 复访复用 session）

2. 工具桥接层（Tool Adapter Layer）
Managed Agents 的工具必须是 HTTP endpoint 或容器。我们构建了一个轻量 adapter service（Go 编写，< 5MB 内存），职责包括：

• 接收 harness 的 POST /execute 请求
• 解析 input_schema 校验 payload
• 调用内部 gRPC 服务（如 CRM client）
• 将 gRPC 响应序列化为 JSON string 返回
• 记录 adapter 自身的 latency 和 error（用于监控，不影响 harness）

这个 adapter 层让我们无需改造任何 legacy 系统，CRM 仍用 Thrift，ERP 仍用 SOAP，adapter 负责协议转换。

3. 事件出口（Egress Event Sink）
event log 是金矿，但 Anthropic 不提供实时推送。我们用 cron job 每 5 分钟拉取 get_event_log ，将关键事件（ tool_call_success , model_output , guardrail_triggered ）写入 Kafka topic，下游接：

• 数据库：存档供 BI 分析（如“上周 32% 的 lead 因 budget_range 缺失被拒”）
• 告警系统：当 guardrail_triggered 频率突增，触发 PagerDuty
• 客服工单系统： model_output 中含 next_step: "create_support_ticket" 时，自动创建 Zendesk ticket

这套集成在两周内完成，零修改现有业务系统，上线首周就发现两个长期存在的 CRM 数据同步 bug（通过对比 event log 中的 fetch_lead_data 输出与数据库实际值）。

4. 竞争格局与避坑指南：为什么现在入场，比一年后更安全

4.1 四大 runtime 竞品的实质差异

当前市场并非 Anthropic 一家独大，而是四股力量并存。我们用生产视角对比：

维度	Anthropic Managed Agents	AWS Bedrock AgentCore	Google Vertex AI Agent Builder	Azure AI Foundry
模型锁定	强绑定 Claude（仅支持 Claude 3.5+）	无锁定（支持 Claude、Llama、Cohere、Titan）	无锁定（支持 Gemini、Claude、Llama）	强绑定 Azure OpenAI（GPT-4o、o1）
沙箱隔离	Firecracker microVM，credential 严格隔离	Nitro Enclaves，credential 由 IAM role 控制	gVisor，credential 由 Workload Identity Federation 管理	Hyper-V，credential 由 Azure Key Vault 托管
会话持久化	原生 event log，7 天保留	Session state 存于 DynamoDB，需自行建模	Session 存于 Cloud Storage，需自行解析	Session 存于 Cosmos DB，提供部分查询 API
治理能力	基础 guardrails（格式、PII、调用限频）	企业级 policy controls（RBAC、data residency、audit log）	Policy engine（基于 Rego），支持自定义规则	Azure Policy 集成，支持合规框架映射
定价模型	$0.08/session-hour + token 费用	$0.05/session-hour + token 费用（含免费额度）	$0.06/session-hour + token 费用（按区域浮动）	$0.07/session-hour + token 费用（Azure 信用抵扣）

关键洞察： 没有“最好”的 runtime，只有“最匹配你现状”的 runtime 。

• 如果你已深度使用 AWS（EC2、RDS、IAM），AgentCore 的无缝集成（同一账号、同一 VPC、同一 SSO）能省下 3 周权限配置时间；
• 如果你已有大量 Vertex AI pipeline，Agent Builder 的 trace store 与 Vertex Explainable AI 深度联动，能直接复用现有可观测性基建；
• 如果你必须满足 SOC2 Type II，Azure AI Foundry 的合规认证路径最短；
• 如果你已签订 Claude 专属 license，Managed Agents 是唯一能保障模型版本、响应延迟、token 优先级的方案。

我们曾帮一家 FinTech 公司评估：他们用 AWS，但核心风控模型是 Claude。最终选择 AgentCore + Claude endpoint ，因为 AWS 的 policy controls 满足其审计要求，而 Anthropic 的 managed runtime 无法提供同等强度的 RBAC。这不是技术优劣，是合规成本的现实计算。

4.2 三大高频踩坑与实战对策

坑一：把 Managed Agents 当作“免运维”幻觉
现象：团队以为上线 YAML 就万事大吉，结果两周后发现 40% 的会话因 tool_call_timeout 失败。
根因： fetch_lead_data 工具调用 CRM API，而 CRM 在高峰时段响应达 8 秒，超过 harness 默认 5 秒 timeout。
对策：

• 在 YAML 中显式设置 timeout_seconds: 15 （工具级）和 runtime.timeout_seconds: 180 （会话级）
• 在 adapter layer 增加 circuit breaker（Hystrix 模式），连续 3 次超时则降级返回缓存数据
• 监控 tool_call_timeout 事件，当 15 分钟内超 5 次，自动触发告警并切换备用 CRM endpoint

坑二：忽略 event log 的 schema 演进成本
现象：v1.0 agent 的 event log 包含 {"type": "crm_lookup", "result": {...}} ，v1.1 升级为 {"type": "crm_enrichment", "data": {...}} ，导致下游 Kafka consumer 解析失败。
根因：event log 是外部契约，schema 变更需向后兼容。
对策：

• 所有 event type 名称加版本号： crm_lookup_v1 , crm_enrichment_v1
• 新增字段必须 optional，删除字段必须保留 deprecated 字段（值为 null）
• 建立 event log schema registry（我们用 Apache Avro），CI 流程强制校验变更

坑三：低估 credential rotation 的复杂性
现象：安全团队要求每 90 天轮换 Slack bot token，但 Managed Agents 的 vault 不支持自动 rotation。
根因：credential 在 vault 中是静态 blob，rotation 需手动操作。
对策：

• 将 credential 存于外部 vault（HashiCorp Vault），Managed Agents 的 sandbox 通过 Vault Agent sidecar 获取动态 token
• 在 YAML 中定义 credential_source: "vault://secret/data/slack-bot-token" ，由 harness 解析并注入
• 设置 Vault 的 TTL 为 89 天，自动触发 renewal

实操心得：Managed Agents 的最大价值不在“开箱即用”，而在“开箱即审计”。我们上线首月，安全团队用 event log 快速定位了 3 个越权调用（agent 调用了本不该有的财务 API），而传统方案需 2 周日志分析。这才是它值得付费的核心。

4.3 未来半年必须关注的三个信号

1. Open-Source Sandbox 的成熟度 ：Daytona 项目已实现 < 90ms sandbox spin-up，其 CLI 工具 daytona run --agent sales-agent.yaml 能在本地复现 Managed Agents 行为。当它发布 v1.0（预计 2026 年 Q3），你会面临选择：用 Anthropic 的托管服务，还是用 Daytona + 自建 K8s？我们的建议：先用 Managed Agents 跑通 MVP，当月会话量超 5 万时，再评估迁移。

2. Trace Store 的事实标准之争 ：Braintrust 的 Brainstore、Arize 的 Phoenix、LangSmith 三方正在争夺 event log 的 schema 标准。谁的格式被更多 runtime 原生支持，谁就成为事实上的 trace layer。我们已要求所有工具输出 JSON-LD 格式事件，确保未来可平滑迁移。

3. Self-Improving Agent 的监管临界点 ：Sakana AI 的 Darwin Gödel Machine 论文显示，agent 可自主重写代码提升 SWE-bench 分数。当这类 agent 进入生产，sandbox 不再是性能组件，而是法律合规组件。欧盟 AI Act 草案已提出“autonomous agent runtime must provide verifiable execution trace”。这意味着，runtime 的核心价值将从“快”转向“可证伪”。

5. 真实经验：为什么我们建议现在启动，但拒绝“All-in”

我在 2023 年亲手把一个客服 agent 从 LangChain 迁移到自研 runtime，花了 4 个人月，换来 30% 的 p95 延迟下降，但代价是每周 15 小时的运维巡检。Managed Agents 让我第一次觉得：“这次，我可以把精力全放在业务逻辑上。”

但我们没有 All-in。原因很实在： Managed Agents 是优秀的 runtime，但不是完整的 agent 开发栈 。它不解决：

• Prompt 工程闭环 ：没有 A/B 测试界面，无法对比 system_prompt 版本效果；
• Tool Discovery ：不能自动发现和注册新工具，仍需手动 YAML 维护；
• Human-in-the-loop ：当 guardrail 触发，没有内置的 approval workflow，需自己接 Slack bot。

所以我们的策略是： 用 Managed Agents 托管 runtime，用 LangSmith 做 prompt 版本管理和 trace 分析，用自研的 approval-service 处理人工审核流 。三者通过 event log 的 guardrail_triggered 事件松耦合。

最后分享一个细节：Anthropic 的 pricing 页面写着“$0.08 per session-hour”，但小字注明“minimum charge: 1 minute”。这意味着一个 3 秒的会话，按 60 秒计费。我们因此调整了会话策略——对简单查询（如“我的订单状态”），改用 stateless API 直接调用 Claude，只对多轮交互（如“帮我比较三款产品，考虑预算和售后”）才启用 Managed Agents。这个微调让 runtime 成本下降了 63%。

技术选型没有银弹。Managed Agents 不是终点，而是你 agent 架构演进中，第一个可以放心交出去的模块。当你不再为 context overflow 失眠，不再为 credential 泄露担惊，不再为会话丢失抓狂——你就知道，这个 $0.08，买到了真正的工程师尊严。