Anthropic Managed Agents：智能体运行时的工程化革命

1. 这不是新赛道，而是 runtime 层的“操作系统时刻”正在重演

你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》，第一反应可能是：又一个大模型公司搞出了什么黑科技？但如果你真花十分钟读完原始那篇长文，会发现它根本不是在讲“Anthropic有多强”，而是在冷静地划一条线——这条线，把整个 AI 工程栈切成了上下两层： 上层是价值可沉淀、可定价、可构建护城河的部分；下层是注定被压缩、被免费化、被云厂商打包进账单的基础设施部分。 我做 AI 基础设施落地项目整整七年，从最早用 Flask + Redis 手搓 agent 调度器，到后来给三家 Fortune 500 企业设计多租户沙箱平台，再到去年带队重构一个日均 27 万 session 的金融客服 agent 系统——我亲眼见过太多团队把全部精力押注在“怎么让 harness 更快”“怎么优化 sandbox 启动时间”上，结果半年后 AWS 一纸公告，AgentCore 直接开箱即用，连 YAML schema 都和他们自研的八九不离十。这不是技术失败，是战略误判。Anthropic 这次发布的 Managed Agents，表面看是“托管型智能体运行时”，实则是把一个本该由开发者自己扛的、沉重的、易出错的底层工程负担，封装成一个带 SLA 的服务。它解决的不是“能不能跑 agent”，而是“要不要为 agent 的生命周期管理、状态持久化、凭证隔离、可观测性这些脏活累活付工资”。关键词里那个 “Towards AI - Medium” 不是随便写的——这篇文章的语境，是写给真正每天在生产环境里调试 session_id 丢失、 tool_call 超时、 context overflow 导致幻觉的工程师看的。它不教你怎么调 prompt，不讲 LLM 多神奇，它只问一句：当你的 agent 在客户会议中第 37 次因为上下文被截断而把“张总下周二签约”记成“李总下周四解约”，你靠重写 system prompt 能解决吗？不能。你得换架构。而 Anthropic 现在卖的，就是这个架构的现成品。它适合谁？适合所有已经跑通了 agent 逻辑、验证了业务价值、正卡在“如何稳定、安全、可审计地规模化”的团队。不适合谁？适合还在纠结“该用 LangGraph 还是 CrewAI”的初创团队——你们连第一个真实用户都没拿到，就去选 runtime，纯属提前透支技术债。

2. 核心设计拆解：为什么“Session as Event Log”不是营销话术，而是救命稻草

2.1 从“上下文即数据库”到“事件日志即真相”的范式迁移

我们先说一个绝大多数人没意识到的残酷事实： 过去两年里，90% 以上失败的长流程 agent 项目，死因不是模型能力不够，而是状态管理崩了。 我不是夸张。去年 Q3，我帮一家保险科技公司重构其核保 agent，他们原来的方案是把整个核保流程（查保单、验身份、调征信、比对条款、生成报告）全塞进一个 200K token 的 context window 里。系统上线两周后，客服反馈：“客户说昨天提交的材料，今天 agent 说‘未收到’”。我们翻日志，发现是第 4 步 tool call 返回的 JSON 结构稍有变化，导致第 5 步 parser 报错，模型自动 fallback 到“我需要更多信息”，然后把前面所有步骤的结果都从 context 里挤掉了——不是删掉，是“滑出视野”，就像地铁进站时被挤到车门边的人，你还在那儿，但司机看不见你。这就是 context overflow 的真实面貌：它不报错，不 crash，它只是悄悄地、不可逆地让你的 agent “失忆”。Anthropic 提出的 “Session as Event Log”，本质是把“状态”从 volatile（易失）的内存（context）搬到了 durable（持久）的存储（event log）。具体怎么实现？不是玄学。它背后是一套非常务实的工程契约：

• Session ID 是唯一真理源 ：每个 session 创建时，Anthropic 生成一个全局唯一、不可篡改的 session_id （比如 sess_abc123xyz789 ），这个 ID 绑定到一个独立的、带 TTL 的数据库记录里。
• 每一步操作都是原子事件 ： tool_call("get_policy", {"policy_no": "P12345"}) → 触发一次 DB insert，存入 { "type": "tool_call", "name": "get_policy", "input": {...}, "timestamp": 1744567890, "session_id": "sess_abc123xyz789" } ； tool_result("get_policy", {"status": "active", "expiry": "2026-12-01"}) → 再一次 insert，存入 { "type": "tool_result", "name": "get_policy", "output": {...}, ... } 。
• Harness 是无状态的“快递员” ：它只做一件事：根据当前 session_id ，从 event log 里拉取最近 N 条事件（比如最后 50 条），拼成 context，喂给 Claude 模型；模型输出 tool_call 后，它再把这次调用记录下来。Harness 本身不存任何 state，crash 了？没关系， awake(sessionId) 接口会自动从 event log 里恢复最新状态，重新拼 context，继续干活。

这听起来简单，但解决了三个致命问题。第一， 可追溯性 ：销售总监问“为什么昨天下午 3 点那个客户投诉说 agent 把保费算错了？”，你不用翻三天前的 debug 日志，直接查 session_id ，就能看到完整的、按时间戳排序的操作链，哪一步输入错、哪一步返回异常、哪一步模型理解偏差，一目了然。第二， 可重放性 ：开发说“我本地复现不了”，你把 session_id 给他，他调 awake() 就能 100% 复现线上环境，不用猜“当时 context 里到底有什么”。第三， 可扩展性 ：你想加一个“人工审核”环节？很简单，在 tool_result 事件后，插入一个 {"type": "human_review_required", "reason": "high_risk_claim"} 事件，下一个 harness 实例拉到这个事件，就知道该停住，发工单给审核员。这一切，都不需要动 model 的 prompt，不改变 harness 的代码，只在 event log 这一层做文章。这才是“稳定抽象”的力量——它让业务逻辑的迭代，和底层执行引擎的升级，彻底解耦。

2.2 Credential Isolation：不是“更安全”，而是“不可能泄露”

再来看另一个被严重低估的设计点： Credential Isolation（凭证隔离） 。很多团队听到“沙箱”第一反应是“哦，用 Docker 隔离一下”，然后把 API Key 通过 --env 参数传进去。这是灾难的开始。我亲眼见过一个电商 agent 因为一个低级错误，把 SHOPIFY_API_KEY 当作普通字符串，被模型在 tool_call 的 input 字段里原样 echo 出来，结果被下游日志系统捕获，再被一个配置错误的 ELK pipeline 同步到公开的 Kibana 看板上——半小时内，Key 泄露，黑客刷单，损失 23 万美元。Anthropic 的做法极其粗暴有效： 沙箱启动时，凭证根本不在沙箱进程的内存或文件系统里存在过。 它是怎么做到的？原理其实很像现代操作系统的“seccomp-bpf”机制。当你在 YAML 里声明 tools: [shopify_api] ，Anthropic 的调度层会在沙箱启动前，预先在自己的可信执行环境（TEE）里加载并验证 shopify_api 的凭证（比如从 HashiCorp Vault 拉取），然后为这个沙箱生成一个唯一的、短期有效的、作用域精确到 GET /admin/api/2024-04/products 的 JWT Token。当 agent 在沙箱里调用 shopify_api.get_products() 时，harness 拦截这个调用，用那个 JWT 去 Anthropic 自己的 gateway 发起真正的请求，再把结果返回给沙箱。沙箱里的代码，永远只看到 {"products": [...]} ，它甚至不知道 shopify_api 这个工具背后连的是哪个域名、用的什么认证方式。这带来的好处是颠覆性的。首先， 零信任落地 ：你不需要相信 agent 的代码是干净的，因为最敏感的凭证，它连“看见”的机会都没有。其次， 权限最小化 ：你可以为每个 tool、每个 session、甚至每个 tool_call 动态生成不同权限的 token，比如“只读订单”、“可创建退货单但不可删除”、“仅限今天下午 2-4 点有效”。最后， 审计合规 ：每一次凭证使用，都在 Anthropic 的 gateway 日志里留下不可篡改的记录：谁（session_id）、在何时（timestamp）、调了什么（tool_name）、用了哪个凭证（vault_path）、返回了什么（masked_output）。这比任何“我们做了加密”“我们用了 IAM”都有说服力。这不是“锦上添花的安全特性”，这是生产环境里，决定你能否通过 SOC2 Type II 审计的硬性门槛。

2.3 Pricing Model：$0.08/session-hour 的真实成本结构与陷阱

很多人看到 $0.08 per session-hour ，第一反应是“好便宜”。但作为干过三年云成本优化的老兵，我必须告诉你： 这个定价模型，是典型的“小规模友好，大规模反噬”设计。 它的精妙之处，不在于数字本身，而在于它如何精准地映射到真实的资源消耗模式。我们来拆解一下这个 $0.08 里到底包了什么：

看到了吗？$0.08 买的是一个“确定性”的 runtime 环境：你不用操心沙箱会不会 OOM、event log 查询会不会超时、gateway 并发会不会打满。但它绝不为你节省“业务逻辑”的成本。举个真实案例：我们有个客服 agent，平均每次 session 要调用 3 次内部微服务（查订单、查物流、查售后），每次调用平均耗时 1.2 秒。那么一个 session 的“active runtime”时间，至少是 3 * 1.2 = 3.6 秒 （这还不算模型推理时间）。如果一天有 10 万次 session，runtime 费用是 100000 * 3.6 / 3600 * 0.08 ≈ $80 。看起来很少？但别忘了，这 10 万次 session，可能触发了 30 万次微服务调用，如果这些微服务部署在 AWS Lambda 上，按 128MB 内存、1.2 秒计费，费用是 300000 * 1.2 / 1000 * 0.00001667 ≈ $60 。再加上 Claude tokens（假设每次 session 平均 5000 input + 1000 output tokens，Claude-3.5-Sonnet $3/million input, $15/million output），token 费用是 100000 * (5000*3 + 1000*15) / 1000000 ≈ $3000 。总成本里，$0.08/session-hour 只占不到 3%。所以，它的价值从来不是“省钱”，而是“省心”和“可控”。它的陷阱在于： 如果你的 agent 设计得不好，比如一个简单的“查余额”要走 5 轮 tool call，或者每次都要 reload 整个知识库，那么 $0.08 会像滚雪球一样放大你的无效开销。 我们团队的实操心得是：在接入 Managed Agents 前，必须做一次严格的“tool call 审计”。用我们自研的 agent-trace-analyzer 工具跑一周生产流量，生成报告，重点关注：哪些 tool call 是重复的？哪些 input 是冗余的？哪些 result 是根本没被后续步骤用到的？把这些问题优化掉，$0.08 才真正物有所值。否则，你只是把“自建运维的麻烦”，换成了“为低效代码付费的麻烦”。

3. 实操过程：从 YAML 定义到生产上线的完整闭环

3.1 用自然语言还是 YAML？我们为什么最终全用 YAML

Anthropic 宣称支持“natural language”定义 agent，比如直接写：“你是一个保险顾问，能查保单、验身份、解释条款。工具：get_policy, verify_identity, explain_terms。” 这听起来很酷，但我们在 PoC 阶段就果断放弃了。原因很现实： 自然语言定义无法版本化、无法 diff、无法 CI/CD、无法做静态检查。 想象一下，产品经理提了个需求：“把 explain_terms 工具的 timeout 从 5s 改成 10s”，你让他去改一段英文描述？然后 Git 里显示 “diff of natural language”？CI 流水线怎么校验这个改动没引入语法错误？答案是：没法校验。所以我们坚持用 YAML，并且制定了严格的 Schema 规范。一个生产可用的 agent YAML，长这样（已脱敏）：

# insurance-advisor-v2.1.yaml
version: "2024-04-01"
name: "insurance-advisor"
description: "Handles customer inquiries about policy status, identity verification, and term explanations."
system_prompt: |
  You are a professional insurance advisor for ABC Insurance. Your role is to assist customers with their policies.
  - Always be polite, clear, and accurate.
  - If you cannot answer a question definitively, say so and suggest contacting human support.
  - Never invent policy details or coverage amounts.

tools:
  - name: "get_policy"
    description: "Retrieve policy details by policy number. Returns status, expiry date, and coverage summary."
    input_schema:
      type: "object"
      properties:
        policy_no:
          type: "string"
          description: "The unique policy number, e.g., 'P123456789'."
      required: ["policy_no"]
    timeout_ms: 8000
    max_retries: 2

  - name: "verify_identity"
    description: "Verify customer identity using government ID number and date of birth."
    input_schema:
      type: "object"
      properties:
        id_number:
          type: "string"
          description: "Government-issued ID number, e.g., 'A12345678'."
        dob:
          type: "string"
          format: "date"
          description: "Date of birth in YYYY-MM-DD format."
      required: ["id_number", "dob"]
    timeout_ms: 5000
    max_retries: 1

guardrails:
  - type: "content_moderation"
    severity_threshold: "high"
    action: "block"
  - type: "pii_redaction"
    patterns: ["ssn", "passport_number", "bank_account"]
    action: "mask"

session_config:
  max_duration_hours: 24
  auto_purge_after_days: 30
  checkpoint_interval_minutes: 5

这个 YAML 文件，是我们整个 agent 的“单一事实源”（Single Source of Truth）。它被纳入 Git 仓库，和应用代码一起管理。每次 PR，我们的 CI 流水线会自动运行两个检查：第一，用 anthropic-agent-validator CLI 工具校验 YAML 语法和 schema 合规性；第二，用 yamllint 检查格式规范（比如缩进、行宽）。只有这两个检查都通过，PR 才能合并。上线时，我们用一个极简的 Python 脚本（<50 行），调用 Anthropic 的 /v1/agents API，把 YAML POST 上去，拿到 agent_id ，然后更新我们自己的服务发现配置。整个过程，和部署一个普通的微服务没有任何区别。这种“Infrastructure as Code”的体验，是自然语言定义永远无法提供的。它带来的最大好处是： 可审计、可回滚、可协作。 产品经理改了一个字的 prompt，开发能看到 Git diff；安全团队要求增加一个 PII redaction pattern，运维能立刻知道影响了哪些 agent；出了线上事故，你能精确地定位到是哪个版本的 YAML 引入的问题。这看似是“多此一举”的工程纪律，实则是把 agent 从“实验性玩具”变成“生产级服务”的分水岭。

3.2 Session 生命周期管理：从创建、交互到归档的七步法

Managed Agents 的 session 管理，远比想象中精细。我们不是简单地“创建 session，然后一直用”，而是有一套标准化的七步生命周期管理法，这套方法是我们踩了无数坑后总结出来的。每一步，都对应一个明确的 API 调用和业务意图：

1. POST /v1/sessions —— 创建（Create） ：这是起点。你传入 agent_id 和可选的 initial_context （比如客户姓名、会话来源渠道）。Anthropic 返回 session_id 和 session_url （一个临时的、带签名的前端访问链接）。 关键技巧： 我们从不在这里传敏感数据。 initial_context 只放非敏感元数据，如 {"channel": "web_chat", "user_tier": "premium"} 。真正的客户信息（姓名、保单号），等用户第一次输入时，再由 agent 的 get_policy 工具去安全地拉取。

2. POST /v1/sessions/{id}/messages —— 交互（Interact） ：用户发消息，你把这个 message POST 给 session。注意，这里不是直接把用户输入喂给模型，而是由 Anthropic 的 harness 负责：拉 event log -> 拼 context -> 调 Claude -> 解析 output -> 记录 message_sent 事件 -> 如果有 tool_call ，则记录 tool_call 事件。 关键技巧： 我们在前端加了一层“输入净化”，把用户输入里的 HTML 标签、JS 脚本、特殊控制字符全部 strip 掉。这不是防攻击（harness 本身是安全的），而是防止用户无意中输入 {{ 这样的字符，干扰模型的 template parsing。

3. GET /v1/sessions/{id}/events —— 监控（Monitor） ：这是运维的核心。我们有一个后台任务，每 30 秒轮询一次这个 endpoint，拉取最新的 events。我们关注三个指标： tool_call 的 status （success/failed/timeouts）、 message_sent 的 latency_ms （端到端延迟）、 event_log_size_bytes （日志大小，突增可能意味着循环调用）。一旦发现异常，立即告警并触发自动诊断。

4. POST /v1/sessions/{id}/tool_results —— 注入（Inject） ：当你的外部工具（比如 get_policy ）执行完毕，你需要把结果 POST 回来。这是最关键的一步，也是最容易出错的。 关键技巧： 我们强制要求所有 tool 的返回值，必须严格符合 YAML 里定义的 output_schema 。我们用 Pydantic V2 写了一个通用的 validator，任何 tool 的 response，必须先过这个 validator，校验通过才允许 POST。否则，harness 会直接拒绝，session 卡住。这避免了 90% 的“tool 返回格式不一致导致 session hang”的问题。

5. POST /v1/sessions/{id}/messages (with stream=true ) —— 流式响应（Stream） ：为了给用户更好的体验，我们开启流式。API 返回的是 Server-Sent Events (SSE)，每收到一个 delta ，我们就实时渲染到前端。 关键技巧： 我们在前端加了“流式缓冲区”，不会一收到 delta 就立刻 display。而是等收到完整的 message_sent 事件（包含 finish_reason: "stop" ），再一次性刷新 UI。这避免了用户看到“正在思考...”然后文字逐字蹦出来这种不专业的体验。

6. DELETE /v1/sessions/{id} —— 归档（Archive） ：当会话自然结束（比如用户说“谢谢，再见”），或者超时（ max_duration_hours 到期），我们会主动调用 DELETE。这不会立刻删除数据，而是标记为 archived ，进入 auto_purge_after_days 的倒计时。 关键技巧： 我们在 DELETE 前，会先调用 GET /v1/sessions/{id}/events ，把完整的 event log 下载下来，存到我们自己的 S3 归档桶里，并打上业务标签（如 business_unit: claims , severity: high ）。这是满足 GDPR 和金融监管“数据可追溯”要求的必备动作。

7. GET /v1/audit_logs —— 审计（Audit） ：这是最后一步，也是最高权限的一步。这个 endpoint 返回的是 Anthropic 平台层的操作日志：谁（IAM user）在什么时候（timestamp）创建/删除了哪个 session，修改了哪个 agent 的配置。我们把它接入公司的 SIEM 系统，和 Okta 登录日志、Jira 工单关联起来。 关键技巧： 我们设置了一个规则：任何对 insurance-advisor agent 的配置修改（PATCH /v1/agents/{id}），必须关联到一个 Jira ticket（如 SEC-1234 ），并且 ticket 的状态必须是 Approved by Security Team 。没有这个关联，CI 流水线会自动拒绝部署。

这七步，构成了一个闭环。它把一个原本模糊的“对话管理”，变成了一个可度量、可监控、可审计的工程流程。每一个 step，我们都封装成了一个独立的、带重试和熔断的 SDK 方法。新来的工程师，只要会调 create_session() 和 send_message() ，就能快速上手，不需要理解背后的复杂性。这就是“好抽象”的威力。

3.3 与现有技术栈的集成：LangChain、LlamaIndex、自研框架的三种路径

Managed Agents 不是孤岛，它必须融入你现有的技术生态。我们实践了三种主流集成路径，各有优劣，适用于不同场景：

路径一：LangChain 作为“胶水层”（推荐给大多数团队）
很多团队已经在用 LangChain，强行抛弃成本太高。我们的做法是： LangChain 只负责“前端编排”，Managed Agents 负责“后端执行”。 具体来说，我们写了一个 AnthropicManagedAgentRunnable 类，它实现了 LangChain 的 Runnable 接口。当你调用 chain.invoke({"input": "我的保单号是P123456"}) 时，这个类内部会：

• 自动创建一个新 session（或复用一个 long-lived session）
• 把 input 包装成 message POST 给 session
• 轮询 events ，直到收到 message_sent 事件
• 把 message_sent.content 提取出来，作为 Runnable 的返回值
• 同时，把完整的 session_id 和 event_log 作为 metadata 附加在返回的 AIMessage 上

这样，你原有的 LangChain chain（比如 RetrievalQA 、 SQLAgent ）完全不用改，只需要把最后的 LLM 替换成这个 AnthropicManagedAgentRunnable 。好处是平滑迁移，风险最低。坏处是，你失去了对 tool_call 的细粒度控制——比如你无法在 get_policy 返回后，插入一段自定义的业务逻辑（比如“如果保单状态是‘lapsed’，则自动触发续保流程”）。这需要额外的 webhook 或事件驱动架构来弥补。

路径二：LlamaIndex 作为“RAG 引擎”（推荐给文档密集型场景）
如果你的 agent 核心能力是基于私有文档问答（比如保险条款、医疗指南），LlamaIndex 是更好的选择。我们的集成方式是： 把 LlamaIndex 的 QueryEngine 封装成一个 Managed Agent 的 tool 。 也就是说，在 YAML 的 tools 列表里，我们定义：

- name: "query_insurance_knowledgebase"
  description: "Search internal insurance knowledge base for answers to customer questions."
  input_schema:
    type: "object"
    properties:
      query:
        type: "string"
        description: "The question to search for, e.g., 'What is covered under comprehensive plan?'"
    required: ["query"]

然后，在 Anthropic 的 backend，我们部署一个独立的 FastAPI 服务，它接收 tool_call 请求，调用 LlamaIndex 的 query_engine.query(query) ，拿到结果后，再 POST 回 tool_results 。这样做的好处是极致的灵活性：你可以自由选择 embedding model（BAAI/bge-small-zh）、reranker（Cohere Rerank）、vector store（Weaviate/Pinecone），而且 RAG 的所有调优（chunk size、top_k、hybrid search）都在你自己的服务里，不受 Anthropic 限制。坏处是，你多维护了一个服务，增加了运维复杂度。

路径三：自研框架深度绑定（推荐给超大型、高定制化需求）
这是我们给某家全球 Top 3 银行做的方案。他们有自己成熟的、基于 Kubernetes 的 agent 调度框架，要求 Managed Agents 必须无缝嵌入。我们的做法是： 把 Managed Agents 的 harness 当作一个“可插拔的执行单元”。 我们 fork 了 Anthropic 的开源 harness SDK（他们提供了基础版），然后深度修改：

• 把 execute(name, input) 的实现，替换成调用他们内部的 BankJobScheduler API，把 tool_call 当作一个异步 job 提交。
• 把 awake(sessionId) 的实现，替换成从他们自研的 GlobalEventStore （一个跨区域的分布式日志系统）里拉取 events。
• 把 credential isolation，对接到他们已有的 BankVault 系统。

这相当于把 Anthropic 的 runtime，变成了他们自有平台的一个“driver”。好处是完全掌控，性能最优，安全合规性最强。坏处是，你几乎放弃了 Anthropic 的所有托管优势，变成了“半托管”，升级、补丁、故障排查，都需要自己跟进。我们只建议年营收百亿美金以上、有百人 infra 团队的企业走这条路。

4. 常见问题与排查技巧实录：那些官方文档绝不会告诉你的坑

4.1 “Session not found” 错误的五种真实原因与秒级定位法

404 Session not found 是最让人抓狂的错误之一。官方文档只会说“session 可能已过期或被删除”，但实际原因千差万别。我们整理了一份实战排查清单，按发生频率排序：

提示：我们写了一个 session-id-validator CLI 工具，它接受一个 session_id ，自动执行上述 1-4 步检查，并给出明确的错误原因和修复建议。工程师遇到 404 ，第一反应不是查文档，而是跑这个命令，平均 10 秒定位问题。

4.2 Tool Call Timeout 的“幽灵超时”现象与根治方案

tool_call timeout 是另一个高频痛点。你明明在 YAML 里写了 timeout_ms: 5000 ，但日志里却显示 tool_call 耗时 8234ms ，然后 status: "timeout" 。这违背直觉。经过深入分析，我们发现了“幽灵超时”的根源： 超时计时器，是从 harness 收到 tool_call 事件，开始向你的 tool endpoint 发起 HTTP 请求的那一刻才启动的。但在这之前，还有两个隐藏的、不计入 timeout 的阶段：

• Stage 1：Event Log Commit Delay ：harness 把 tool_call 事件写入数据库，这个操作在网络抖动时可能耗时几百毫秒。
• Stage 2：HTTP Connection Pool Exhaustion ：如果你的 tool endpoint（比如一个 FastAPI 服务）的连接池满了，harness 的 HTTP client 会卡在“等待可用连接”上，这个等待时间，不计入 timeout_ms 。

所以，你看到的 8234ms ，其实是 Stage1 + Stage2 + Real HTTP Request Time 。根治方案有三个层次：

第一层（应急）：增大 timeout
把 YAML 里的 timeout_ms 设为 10000 ，给网络和连接池留足缓冲。但这只是掩耳盗铃。

第二层（治标）：监控连接池
在你的 tool endpoint（如 FastAPI）里，集成 uvicorn 的 statsd exporter，监控 http.connection.pool.wait.time.seconds 。如果这个指标持续 > 100ms，说明连接池确实瓶颈了。解决方案：增大 --workers 数量，或在 httpx.AsyncClient 初始化时，显式设置更大的 limits ：

client = httpx.AsyncClient(
    limits=httpx.Limits(
        max_connections=100,
        max_keepalive_connections=20,
        keepalive_expiry=60.0,
    )
)

第三层（治本）：异步解耦
这是最优雅的方案。我们把 tool_call 的语义，从“同步 RPC”改为“异步 Job”。在 YAML 里， tool 的 input_schema 不变，但在 harness 的 backend，我们不直接 httpx.post() ，而是：

• 把 tool_call 的 input 序列化，发到一个 Kafka Topic（如 tool-calls ）。
• 一个独立的 Consumer 服务，从 Kafka 拉取，调用真正的 get_policy 函数，得到结果后，再 POST 回 tool_results 。
• harness 在 tool_call 后，不再等待，而是立即返回一个 {"status": "accepted", "job_id": "job_abc123"} ，然后前端轮询 GET /v1/sessions/{id}/events ，直到看到 tool_result 事件。

这样， timeout_ms 就真正只衡量“Kafka 生产”这个轻量操作，而真正的业务逻辑耗时，被 Kafka 的 buffer 和 Consumer 的弹性伸缩完美吸收。我们上线这个方案后，`