Agent Runtime 重构：从上下文陷阱到可审计会话日志

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

我第一次在生产环境里跑一个需要连续交互 30 分钟以上的 AI agent，是在 2025 年初。当时用的是自己搭的 LangChain + FastAPI + Redis 状态机方案。系统上线第三天，客户在 Slack 里发来一张截图：一个本该生成完整财务分析报告的 agent，在第 7 轮工具调用后突然开始胡说八道——它把前 4 步查到的营收数据全忘了，却坚称“根据最新财报”，编出一组完全不存在的数字。我们翻日志、查 Redis、重放 trace，最后发现根本没日志可查：状态全压在 LLM 的 context window 里，窗口一满，老数据就被无声无息地挤掉，连个 warning 都没有。整个 session 就像被橡皮擦抹掉了一半的草稿纸，你既不能回溯，也不能续写。

这件事之后，我和团队花了整整两周，把所有状态逻辑从 prompt 里抽出来，改用事件溯源（Event Sourcing）模式存进 PostgreSQL，每个 tool call 都落库为一条不可变事件记录，agent 的“记忆”从此和模型解耦。做完那一刻我才真正理解： 不是 agent 不够聪明，而是我们一直把它关在一个会自动清空的玻璃盒子里。 Anthropic 在 2026 年 4 月 8 日发布的 Claude Managed Agents，本质上就是把这个玻璃盒子换成了带永久日志、带隔离沙箱、带凭证保险柜的工业级操作台。它不解决“agent 能做什么”，它解决的是“agent 做完之后，你还知道它做了什么”。

关键词里的 “Towards AI - Medium” 其实是个重要线索——这篇文章不是技术白皮书，也不是产品通稿，它是写给每天在真实业务里调试 agent、被 context overflow 搞崩溃、被 credential 泄露吓出冷汗的工程师看的。它讲的不是“Anthropic 又出了个新东西”，而是“我们终于不用再自己造轮子去扛 runtime 层那些反人性的设计债了”。适合谁？适合所有正在用 LangGraph 写 workflow、用 CrewAI 搭多智能体、或者正打算把 Notion 数据库接入 Claude 的团队负责人；也适合那些刚在 AWS 控制台里点开 AgentCore、对着 microVM 配置项发呆的 DevOps 同学。它解决的问题很朴素：让 agent 从一次性的“对话流”，变成可审计、可恢复、可编排的“业务进程”。

这背后藏着一个更硬核的事实：runtime 层正在经历和 2000 年代初虚拟化技术一模一样的历史路径。当年 VMware 卖的是每台物理服务器上万美金的 ESX 许可证，今天 Anthropic 卖的是每小时 8 美分的 session 运行时。差别只在于，这一次，压缩周期被缩短到了 18 个月。而真正值得所有人盯住的，从来不是那个正在被压价的 runtime 层本身，而是它上面正在快速成形的三块新地基：能证明 agent 到底干了什么的 trace store，能管住 agent 别越界的 policy engine，以及能让销售总监直接签单的垂直 agent 市场。这才是本文要拆给你看的全部。

2. 核心设计逻辑：为什么“Session as Event Log”是唯一正确的起点

2.1 从“上下文即内存”到“事件即真相”的范式迁移

过去两年，我参与过 7 个不同行业的 agent 项目，从医疗问诊助手到供应链异常检测系统，它们有一个惊人的共同点： 90% 的线上故障，根源不在模型推理，而在状态管理。 最典型的场景，就是 multi-step retrieval（多步检索）。比如一个金融分析 agent，第一步查公司年报，第二步抓行业研报，第三步比对竞品数据，第四步生成风险提示。每一步的结果都得塞进 prompt，等 context 窗口撑到临界点（Claude 3.5 Sonnet 是 200K tokens），系统不会报错，它只是悄悄把第一步的年报 PDF 文本摘要给截断了。模型接着往下走，用残缺的输入生成残缺的输出，用户看到的是一份“看起来很专业但关键数据全错”的报告。

Anthropic 的 Managed Agents 把这个问题从根上切掉了。它的核心抽象不是“一个会说话的模型”，而是一个 “Harness（执行器）+ Session（会话）+ Sandbox（沙箱）” 的三角结构 。其中 Session 被明确定义为“持久化的事件日志”，独立于任何模型实例存在。这意味着：

• 每次 tool call 的输入、输出、时间戳、调用者身份、返回状态，都会作为一条不可变事件（immutable event）写入底层存储；
• Harness 是无状态的——它只负责接收 execute(name, input) 请求，调用对应容器，把结果打包成事件发回 Session；
• 当 Harness 因为网络抖动或 OOM 崩溃时，新启动的 Harness 只需调用 awake(sessionId) ，就能从 Session 中读取最新事件流，精准恢复到崩溃前一刻的状态，而不是从头开始。

这个设计不是炫技，它直指三个现实痛点：

1. 可审计性 ：法务或合规部门要查“某客户的数据是否被泄露”，你不再需要翻几十个微服务的日志，只需查询 Session ID 对应的事件流，看哪条 call('fetch_customer_data') 事件的 output 字段是否包含敏感字段；
2. 可复现性 ：当客户投诉“昨天生成的报告和今天不一样”，你不需要让客户再走一遍流程，直接重放 Session 事件流，就能 100% 复现当时的决策链；
3. 可扩展性 ：Session 作为中心事件源，天然支持事件驱动架构——你可以接一个 Kafka topic，让风控系统实时监听 call('transfer_funds') 事件，触发二次审批。

提示：这个模式和数据库里的 WAL（Write-Ahead Logging）原理高度一致。WAL 不是把数据直接写磁盘，而是先记一笔“我要写什么”，再异步刷盘。Anthropic 把 agent 的决策过程也变成了 WAL——先记“我调用了什么工具、传了什么参数、得到了什么结果”，再让模型基于这个事实做下一步判断。这是工程上最稳的解法。

2.2 Credential Isolation：不是“怎么藏密钥”，而是“密钥根本不出现在沙箱里”

去年帮一家跨境支付公司做风控 agent 时，我们踩过一个致命坑。当时为了快速上线，把 API Key 直接设为 Docker 容器的环境变量，然后让 agent 的 Python 代码通过 os.getenv('PAYMENT_API_KEY') 读取。上线一周后，安全团队在渗透测试中发现：只要让 agent 执行 curl https://internal-api.example.com/debug?token=${PAYMENT_API_KEY} 这类命令（模型很容易被诱导生成这种调试请求），密钥就会原样暴露在 HTTP 请求头里。这不是理论风险，是真实发生的事故。

Anthropic 的解决方案极其干净： Credential Vault（凭证保险库）与 Sandbox（沙箱）物理隔离。 具体实现是：

• 开发者在 YAML 配置中声明需要哪些 credential（如 notion_api_key , salesforce_oauth_token ）；
• Anthropic 的控制平面在 provision sandbox 时，只向沙箱注入一个临时的、短时效的、作用域极窄的 bearer token；
• 沙箱内的 agent 代码调用 tool_call('notion_search', {'query': 'Q1 report'}) 时，Harness 层会拦截该请求，用临时 token 向 Vault 换取真正的 Notion API Key，再以服务端代理方式完成调用；
• 整个过程中，真实的 API Key 永远不会进入沙箱内存空间，agent 代码甚至无法感知它的存在。

这个设计的价值，远超“防密钥泄露”。它让 credential 管理变成了平台能力：

• 密钥轮换无需重启 agent：Vault 更新密钥后，下一次 tool call 自动生效；
• 权限最小化成为默认：每个 tool 的 credential scope 在配置时就锁定（如 notion_search 只能读 database，不能删 page）；
• 审计粒度精确到毫秒：Vault 日志能清晰记录“哪个 Session ID 在什么时间，为哪个 tool call 换取了哪个凭证”。

对比之下，很多 DIY 方案还在用 HashiCorp Vault 的 sidecar 模式，让 agent 主动去 Vault 拉密钥——这等于把保险柜钥匙交给了 agent 本人。Anthropic 的做法，是让 agent 只能提需求，由平台代为执行，彻底切断了密钥接触面。

2.3 架构分层的现实意义：为什么“Harness crash and resume”不是 PPT 术语

很多技术人第一反应是：“这不就是个带状态管理的 serverless 函数？” 但实际落地时，分层带来的收益远超想象。举个真实案例：我们给一家电商公司做的“促销策略 agent”，需要串联 5 个内部系统（库存、价格、物流、CRM、BI）。最初版本把所有逻辑写在一个 LangChain Chain 里，每次调用都加载全部工具。结果发现：

• p95 延迟高达 8.2 秒（主要卡在初始化阶段）；
• 某个物流接口超时，整个 chain 就卡死，必须人工干预重试；
• 新增一个 BI 工具，要改 3 个模块的代码，测试周期 2 天。

换成 Managed Agents 的分层模型后：

• Harness 层只做最轻量的路由：收到 execute('get_inventory') ，立刻转发给 inventory-container，不碰业务逻辑；
• Sandbox 层按需启动：只有调用 get_inventory 时，inventory-container 才被拉起，其他容器保持休眠；
• Session 层自动处理失败：当 get_inventory 返回 timeout，Session 记录该事件为 failed ，Harness 可配置重试策略（如指数退避），或直接跳转到 fallback 流程。

结果是：

• p95 延迟降到 1.3 秒（下降 84%）；
• 单点故障不影响全局：物流接口挂了，agent 自动降级到“基于历史数据估算库存”，继续生成促销建议；
• 新增 BI 工具只需写一个新 container 和 YAML 配置，上线耗时 20 分钟。

这就是分层的价值： 它把“系统稳定性”从开发者肩上，转移到平台基础设施上。 你不再需要为每个工具写熔断、降级、重试逻辑，Harness 层已经内置了这些企业级能力。而这一切的前提，是 Session 作为事件日志的绝对权威性——只有当每一步操作都有迹可循，平台才能做出智能的恢复决策。

3. 实操细节解析：从 YAML 配置到生产部署的完整链路

3.1 配置即代码：YAML 文件里的每一个字段都在解决真实问题

Managed Agents 的配置文件（ .claude-agent.yaml ）看着简单，但每个字段都是血泪教训的结晶。下面是我基于 3 个生产项目提炼出的“必填项精解”，不是文档翻译，而是告诉你为什么必须这么写：

# .claude-agent.yaml
name: "sales-dev-agent"
version: "1.2.0"
description: "Qualifies leads from LinkedIn and schedules demos"

# 【关键】System Prompt 不是“欢迎语”，而是 agent 的宪法
system_prompt: |
  You are a senior sales development representative at Acme Corp.
  Your goal is to qualify inbound leads from LinkedIn Sales Navigator.
  RULES:
  - NEVER ask for credit card info or sensitive PII
  - If lead says 'not interested', respond with 'Thanks for your time' and end
  - Always cite the exact LinkedIn profile URL when referencing lead data
  - For scheduling, ONLY use Calendly links from https://acme-corp.calendly.com

# 【关键】Tools 不是功能列表，而是权限契约
tools:
  - name: "linkedin_search"
    description: "Search LinkedIn profiles by name/company"
    input_schema:
      type: "object"
      properties:
        full_name: {type: "string", description: "First and last name"}
        company: {type: "string", description: "Company name (exact match)"}
    # credential_scope 定义了这个工具能拿到什么密钥
    credential_scope: "linkedin_read_only"

  - name: "calendly_create_event"
    description: "Create a demo meeting slot in Calendly"
    input_schema:
      type: "object"
      properties:
        email: {type: "string", format: "email"}
        duration_minutes: {type: "integer", enum: [30, 45, 60]}
    # 注意：这个工具需要写权限，scope 严格限定
    credential_scope: "calendly_demo_write"

# 【关键】Guardrails 是你的最后一道防线
guardrails:
  # 模型可能生成的危险指令，必须拦截
  blocked_phrases:
    - "curl https://"
    - "wget http://"
    - "exec("
    - "os.system("
  # 敏感数据识别，自动 redact
  pii_detection:
    enabled: true
    patterns:
      - "ssn: [0-9]{3}-[0-9]{2}-[0-9]{4}"
      - "credit_card: \d{4} \d{4} \d{4} \d{4}"

# 【关键】Session 策略决定 agent 的“寿命”
session_policy:
  # 会话最长存活 72 小时，避免僵尸 session 占资源
  max_duration_hours: 72
  # 空闲 30 分钟自动休眠，节省成本
  idle_timeout_minutes: 30
  # 关键！事件保留 90 天，满足 GDPR 审计要求
  event_retention_days: 90

这个 YAML 文件里， credential_scope 字段解决了密钥爆炸问题——你不再需要为每个工具单独管理密钥，而是定义好 scope，由平台统一分发； blocked_phrases 不是简单的字符串匹配，它会在模型生成 token 的每一步做实时扫描，一旦发现 curl 开头的序列，立刻中断生成； event_retention_days 直接关联到法务合规条款，90 天是多数金融客户合同的硬性要求。 写 YAML 的过程，本质上是在和平台签订一份 SLA 合约。

3.2 本地开发与调试：如何在不烧钱的情况下验证逻辑

很多人以为 Managed Agents 只能在 Anthropic 云上跑，其实 Anthropic 提供了完整的本地开发套件 claude-agent-cli 。我推荐的调试流程是三层递进：

第一层：纯逻辑验证（零成本）
用 CLI 的 --dry-run 模式，把 YAML 配置和测试输入喂给本地模型（如 Ollama 上的 llama3:70b）：

claude-agent-cli run \
  --config ./sales-dev-agent.yaml \
  --input '{"message": "Hi, I saw your post about AI agents"}' \
  --dry-run \
  --model ollama:llama3:70b

CLI 会模拟 Harness 行为：解析 prompt、识别 tool call、生成事件日志，但不真调用任何外部 API。你能看到完整的事件流：

[EVENT] system_prompt_applied -> "You are a senior sales..."
[EVENT] user_message_received -> "Hi, I saw your post..."
[EVENT] tool_call_scheduled -> {"name": "linkedin_search", "input": {...}}
[EVENT] tool_call_executed -> {"output": "Profile found: Jane Doe @ Acme Corp..."}

这一步能快速验证 prompt 设计、tool 触发逻辑、guardrail 是否生效，100% 免费。

第二层：沙箱模拟（低成本）
用 --sandbox-mode=mock 启动，CLI 会启动一个轻量级 mock sandbox，所有 tool call 都返回预设的 JSON 响应：

claude-agent-cli run \
  --config ./sales-dev-agent.yaml \
  --input '{"message": "Schedule a demo"}' \
  --sandbox-mode=mock \
  --mock-responses=./test-responses.json

test-responses.json 里可以定义：

{
  "linkedin_search": {"status": "success", "data": {"url": "https://linkedin.com/in/jane-doe"}},
  "calendly_create_event": {"status": "error", "code": "INVALID_EMAIL"}
}

这样你就能测试错误处理逻辑、fallback 流程，而不用真的调用 Calendly API（避免测试账号被限流）。

第三层：真沙箱联调（可控成本）
当逻辑验证通过，再切到真实 sandbox：

claude-agent-cli run \
  --config ./sales-dev-agent.yaml \
  --input '{"message": "Book a demo"}' \
  --sandbox-mode=real \
  --anthropic-api-key $ANTHROPIC_KEY

此时 CLI 会创建一个真实 sandbox，调用真实 API，但只产生 1 次 session（$0.08）。我习惯在周五下午做这一步，因为周末可以观察 session 事件日志，周一上班前就能确认所有集成点是否正常。

注意：本地 CLI 的 --dry-run 和 --mock 模式，其输出格式和云端事件日志完全一致。这意味着你在本地验证的事件结构，上线后可以直接被你的 trace store（如 LangSmith）消费，无需任何适配。

3.3 生产部署的关键配置：别让 $0.08/hour 变成 $8000/month

Managed Agents 的定价模型（$0.08/session-hour）看似简单，但生产环境里几个配置失误，会让成本飙升 100 倍。这是我从客户账单里总结出的三大“成本黑洞”及应对方案：

最狠的成本优化技巧，来自一家在线教育公司的实践：他们把“学生答疑 agent”拆成了 stateless + stateful 两层 。学生提问时，先用无状态的 claude-agent-cli run --stateless 快速判断问题类型（是课程内容？技术问题？ billing？），仅此一步就消耗 $0.001；只有当判定为“技术问题”时，才启动带完整工具链的 stateful session。结果是 session-hour 成本下降 63%，而用户体验毫无感知——因为 80% 的问题，stateless 层就直接回答了。

4. 竞争格局全景图：为什么说 Anthropic 的发布是防御战，而非攻坚战

4.1 Hyperscaler 的“免费即正义”：AWS AgentCore 如何用基础设施优势碾压

2025 年 11 月，AWS Bedrock AgentCore GA 上线时，我第一时间去看了它的 pricing 页面。没有惊喜，只有一行小字：“AgentCore runtime included at no additional charge for all Bedrock model invocations.” —— 只要你在用 Bedrock 的模型，AgentCore 的 runtime 就是免费的。 这不是营销话术，是 AWS 的基础设施哲学：runtime 层就像 EC2 的虚拟化层，它不该单独收费，而应作为云服务的“空气”。

我拿 Anthropic 的 Managed Agents 和 AgentCore 做了横向对比，重点看三个生产级指标：

最关键的是生态整合。AgentCore 不是孤立产品，它深度嵌入 AWS 的整个治理链条：

• IAM Policy 可直接控制 agent 能调用哪些 AWS 服务（如 bedrock:InvokeModel + s3:GetObject ）；
• CloudTrail 自动记录所有 agent 的 tool call，事件直接流入你的 SIEM 系统；
• Cost Explorer 可按 agent name、session ID、tool name 维度分账，财务部门能直接看到“销售开发 agent 本月消耗 $2,340”。

这解释了为什么 Notion 选择 Anthropic，而 Rakuten 选择 AWS：Notion 的核心资产是 Claude 模型能力，它需要一个能最大化 Claude 性能的 runtime；Rakuten 的核心资产是 AWS 云账单，它需要一个能把 agent 成本无缝纳入现有采购体系的 runtime。 Anthropic 卖的是模型体验，AWS 卖的是云基础设施。

4.2 开源势力的闪电战：Daytona 和 Kubernetes SIG 如何重构游戏规则

如果说 hyperscaler 是靠“免费”打价格战，开源社区就是在用“速度”打技术战。2025 年初还默默无闻的 Daytona，到 2026 年 3 月已拿下 2400 万 GitHub Stars，并宣布支持 sub-90ms 沙箱启动。它的杀手锏不是性能，而是 “dev environment first” 的开发范式 。

Daytona 的核心理念是： agent 开发环境，应该和前端开发一样丝滑。 它提供的 CLI 工具链，让开发者能像写 React 组件一样写 agent：

# 创建一个新 agent
daytona create sales-agent --template langgraph

# 在本地启动带 UI 的调试环境（自动注入 mock tools）
daytona dev

# 一键部署到任意 Kubernetes 集群
daytona deploy --cluster my-prod-cluster

最惊艳的是它的 daytona dev 命令：它会启动一个 Web UI，左侧是实时更新的事件流（和 Anthropic 的 Session 日志格式完全一致），右侧是可交互的 sandbox 控制台。你可以暂停 agent、修改某一步的 tool 输出、重放事件流——这比 Anthropic 的 CLI 调试体验高出两个数量级。

而 Kubernetes SIG 在 2026 年 2 月发布的 k8s-agent-sandbox 项目，则代表了另一种思路： 把 agent runtime 变成 Kubernetes 的一等公民。 它定义了新的 CRD（Custom Resource Definition）：

apiVersion: agent.k8s.io/v1
kind: AgentSandbox
metadata:
  name: sales-dev-sandbox
spec:
  image: acme/sales-agent:v1.2
  tools:
    - name: linkedin_search
      endpoint: http://linkedin-proxy.default.svc.cluster.local
  sessionTTL: "72h"

这意味着，你可以用 kubectl apply -f sandbox.yaml 部署 agent，用 kubectl get agentsandbox 查看所有运行中的会话，用 kubectl logs -f agentsandbox/sales-dev-sandbox 实时查看事件日志。 agent runtime 彻底融入了运维人员最熟悉的工具链。

这两股开源力量的交汇点，是 “trace portability” （追踪可移植性）。Anthropic 的 Session 日志、AgentCore 的 CloudTrail 事件、Daytona 的 event stream、K8s 的 CRD status，它们都在用不同的格式记录同一件事。谁能率先定义统一的 OpenTelemetry for Agents 标准，谁就掌握了 runtime 层之上的价值高地。

4.3 垂直市场的爆发：当 agent 从“技术概念”变成“采购合同”

Salesforce 的 Agentforce ARR 达到 $800M，这个数字背后是 29,000 份真实签署的采购合同。我研究了其中 127 份合同样本，发现一个惊人规律： 合同里从不出现“runtime”、“sandbox”、“harness”这类技术词，只反复出现三个词：“compliance”、“ROI”、“SLA”。

比如某家保险公司采购的“理赔审核 agent”，合同条款是：

• Compliance ：必须通过 OWASP Agentic Top 10 审计，所有 PII 数据处理需符合 HIPAA；
• ROI ：将平均理赔处理时长从 4.2 天缩短至 1.8 天，否则按差额赔付；
• SLA ：99.95% 的会话需在 3 秒内返回首 token，超时按分钟扣减服务费。

这揭示了一个残酷现实： 企业采购的不是 agent 技术，而是 agent 解决的业务问题。 当 runtime 层 commoditize（商品化）后，价值必然向上游迁移。目前最热的三个垂直方向是：

1. 金融合规 agent ：virattt/ai-hedge-fund 项目已支持 SEC Form 13F 自动生成，其核心不是模型多强，而是内置了 200+ 条 FINRA 合规检查规则，每条规则都可审计、可追溯；
2. 安全渗透 agent ：vxcontrol/pentagi 项目能自动执行 OWASP ZAP 扫描、Nmap 端口探测、Burp Suite 漏洞验证，并生成符合 ISO 27001 格式的审计报告；
3. 医疗编码 agent ：MedCoder.ai 项目将 ICD-10 编码准确率从人工的 89% 提升至 96.3%，关键是它把 AMA（美国医学会）的编码指南转化为可执行的 decision tree，每一步编码决策都有指南原文引用。

这些项目的共同点是：它们都不卖 runtime，而是卖 “垂直知识 + 可验证结果 + 合规背书” 。当你能向 CFO 展示“本季度 agent 为公司节省了 $2.3M 人力成本”，或向 CISO 展示“所有渗透测试均通过 NIST SP 800-115 认证”，runtime 层的性能参数就变成了无关紧要的 footnote。

5. 实战问题排查手册：从 37 个线上故障中提炼的黄金法则

5.1 Context Overflow 的幽灵：如何识别和根治“静默失效”

Context overflow 是 agent 最难缠的敌人，因为它不报错，只撒谎。我在生产环境里见过最诡异的案例：一个法律合同审查 agent，连续 3 天对同一份合同给出完全相反的结论。日志显示一切正常，直到我导出 Session 事件流，发现第 12 步的 call('extract_clauses') 事件 output 字段，后半截被截断了——原来模型在生成长文本时，把截断标志 ... 当成了有效内容，后续步骤基于残缺数据做推理。

根治三步法：

1. 前置检测 ：在每次 tool call 前，用正则扫描 input 字符串长度，超过 150K tokens 时主动触发 truncate_and_summarize 流程（用模型自身压缩前序事件）；
2. 后置校验 ：在 Session 事件流中，为每个 tool_call_executed 事件添加 output_length_bytes 字段，监控其分布，当 95% 分位数突增 20%，立即告警；
3. 终极兜底 ：配置 session_policy.max_events_per_session: 50 ，强制长流程拆分为多个 session，用 parent_session_id 建立父子关系。

实操心得：不要依赖模型的“自我总结”能力。我试过让 Claude 在 context 满时自动生成摘要，结果发现它经常漏掉关键否定词（如把“不得转让”总结为“可转让”）。现在我们的标准做法是：用专门训练的 tiny-BERT 模型做无损摘要，它虽然小，但专为法律文本优化，准确率 99.2%。

5.2 Credential Leaked 的 7 种形态及防御矩阵

密钥泄露不是“有没有”，而是“以什么形式发生”。我整理了 37 个真实泄露事件，归为 7 类，并给出 Anthropic 配置级防御方案：

最有效的防御，是让密钥“不可见”。Anthropic 的 Vault 模式做到了这点：agent 代码里永远找不到 API_KEY 这个字符串，它只认识 tool_call('notion_search') 这个动作。 当密钥从代码里消失，泄露面就从“整个代码库”缩小到“Vault 接口”这一个点。

5.3 性能瓶颈定位：从 p95 延迟到逐毫秒归因

p95 延迟高，不等于模型慢。我帮客户优化一个 p95 达到 12 秒的 agent 时，发现真正瓶颈是 calendly_create_event 工具的 DNS 解析——Calendly 的域名在某些 VPC 中解析超时。这提醒我们： agent 的延迟是全链路的，必须逐段测量。

Anthropic 的事件日志提供了完美的归因基础。每个事件都有 timestamp_start 和 timestamp_end 字段，你可以计算出各环节耗时：

{
  "event_type": "tool_call_executed",
  "tool_name": "calendly_create_event",
  "timestamp_start": "2026-04-10T08:23:15.123Z",
  "timestamp_end": "2026-04-10T08:23:18.456Z",
  "duration_ms": 3333,
  "output": {"status": "success", "meeting_url": "..."}
}

我的标准排查流程是：

1. 看分布 ：用 Kibana 查 duration_ms 的 histogram，如果 95% 的事件集中在 100-300ms，但有 5% 突然跳到 3000ms，说明是偶发故障，不是设计问题；
2. 看关联 ：筛选 tool_name: "calendly_create_event" 且 duration_ms > 2000 的事件，检查其前一个事件 tool_name 是什么——如果是 linkedin_search ，说明是网络问题；如果是 user_message_received ，说明是模型生成太慢；
3. 看聚合 ：按 tool_name 分组，计算平均 duration_ms ，找出 TOP 3 慢工具，针对性优化（如为 Calendly 添加 DNS 缓存层）。

最终我们在这个项目里，把 p95 从 12 秒降到 1.8 秒，其中 70% 的收益来自工具层优化，只有 30% 来自模型升级。 优化 agent，80% 的工作量在 tool，不在 model。

6. 未来半年行动清单：抓住 runtime commoditization 前的最后窗口期

6.1 立即执行的三件事（本周内）

1. 审计你的所有 agent 会话 ：用 claude-agent-cli export-events --days 30 导出最近 30 天的事件日志，用脚本统计：

   • session_duration_hours 的分布（识别长会话）
   • tool_name 的调用频次（识别高频工具）
   • event_type: "tool_call_executed" 的 duration_ms P95（识别慢工具） 这份报告，就是你接下来三个月的优化路线图。

2. **重构 credential