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

你有没有在深夜调试一个跑了三小时的 AI 代理，突然发现它开始胡言乱语？不是模型崩了，不是 prompt 写错了，而是——它的“记忆”被自己挤掉了。上下文窗口就那么大，工具调用日志、用户多轮对话、中间状态快照……全堆在里面，像往一个塞满旧报纸的抽屉里硬塞第 27 张发票。最后它忘了自己刚查过客户邮箱，又去调了一次 API；忘了上一步生成的 SQL 语句里有个 WHERE 条件没加，直接把整张表导了出来。这不是 bug，是架构债到期了。

Anthropic 在 4 月 8 日发布的Claude Managed Agents公共测试版，表面看是一套托管代理运行时，但内核解决的正是这个“抽屉爆仓”问题。它把“会话”（session）从模型上下文里彻底拎出来，变成一个独立、持久、可查询的事件日志（event log），存在外部数据库里；把“执行器”（harness）做成无状态的轻量级容器，只负责按需拉起沙箱、传入输入、拿到输出；把“沙箱”（sandbox）当成一次性牲畜（cattle），而不是需要精心喂养的宠物（pets）。这三件套组合起来，不是给开发者多一个选择，而是把过去一年里无数团队在自建 agent 系统时反复踩坑、重写、再踩坑的痛苦，打包成一套开箱即用的基础设施契约。

关键词里的 “Towards AI - Medium” 并非偶然——这篇文章本身就在 Medium 上首发，而 Medium 正是那种典型场景：内容团队想让 Claude 自动抓取行业报告、提炼关键数据、生成周报草稿，再推送到 Slack。这种任务天然跨系统、跨权限、跨时间。它需要记住上周五谁改了模板，需要安全地读取 Notion 数据库的 API Key，需要在中断后能从第 3 步 resume 而不是从头再来。Managed Agents 就是为这类真实工作流设计的，不是为 demo 视频里的三步调用。它不承诺“最强模型”，但承诺“最稳流程”。如果你正在评估是否要自建一套 LangGraph + Redis + Docker 的 agent 运行时，或者纠结要不要把 CrewAI 部署到 EKS 上，那这篇分析就是给你写的——它告诉你，现在入场自建 runtime，就像 2006 年还在手写 VMware ESX 安装脚本一样，技术上可行，但经济上已非最优解。

我去年带团队做过一个金融尽调 agent，目标是自动爬取 50 家上市公司的年报 PDF，提取“应收账款周转天数”和“存货周转率”，填进 Excel 模板并生成趋势图。我们最初把所有中间结果都塞进 context window，跑着跑着就发现：第 12 家公司处理完，第 1 家的原始 PDF 文本摘要就没了；第 23 家时，Excel 表头格式开始错乱；到第 37 家，agent 开始编造数字，还自信满满地画出一条完美上升曲线。我们花了整整一周重写状态管理层，把每一步的输入、输出、错误、耗时全部存进 PostgreSQL，用 session_id 当主键。重写之后，失败可重试、过程可回溯、指标可监控。Anthropic 做的，就是把我们那一周的痛苦，变成了 YAML 文件里一行state_store: "anthropic://eventlog"的配置。这才是它真正值 $0.08/小时的地方——不是省了服务器钱，是省了你重构架构、排查静默故障、安抚愤怒客户的成本。

2. 核心设计拆解：为什么是“Session-as-Event-Log”，而不是“Context-as-Database”

2.1 传统 agent 架构的致命伤：上下文即数据库的幻觉

绝大多数开源 agent 框架（LangChain、LlamaIndex、CrewAI）默认把模型的上下文窗口当作临时数据库来用。开发者习惯性地把以下信息一股脑塞进去：

• 用户原始提问（含时间戳、渠道来源）
• 历史对话摘要（“用户之前问过 A，我们回复了 B”）
• 工具调用记录（“调用 search_api('Q1营收') → 返回 {‘revenue’: 1.2e9}”）
• 中间推理链（“因为营收增长，所以推测市场扩张”）
• 下一步计划（“下一步：调用 finance_db 查询 Q2 数据”）

这看似合理，实则埋下三颗定时炸弹：

提示：上下文窗口不是数据库，它没有索引、没有事务、没有版本控制，只有 LRU 缓存淘汰策略。当新 token 流入，最老的 token 就被无声踢出——你永远不知道哪条关键日志先消失。

第一颗炸弹叫静默失忆。模型不会报错说“我忘了”，它只会基于残缺信息继续推理。比如你让它对比两家公司财报，它刚查完 A 公司的毛利率，context 就满了，B 公司的查询结果被挤掉。它不会说“我找不到 B 公司数据”，而是直接说“A 公司毛利率更高”，把缺失当成确定性结论。这种错误无法通过日志告警，只能靠人工复核结果，而复核成本远高于预防成本。

第二颗炸弹叫不可回溯性。当 agent 出现异常（比如生成了违规内容、调用了错误 API），你唯一能看的只有最终输出和原始 prompt。中间发生了什么？哪个 tool call 返回了异常 JSON？哪次重试导致了循环调用？全无记录。你只能靠猜：是 prompt 不够清晰？是 tool schema 写错了？还是模型在特定 token 序列下有固定幻觉模式？没有 event log，debug 就是蒙眼射击。

第三颗炸弹叫扩展性天花板。上下文长度是硬约束。Claude 3.5 Sonnet 支持 200K tokens，听起来很宽裕。但实际业务中，一个包含 5 个 PDF 解析结果（每个 10K tokens）、3 次数据库查询返回（每个 2K tokens）、10 轮对话摘要（每个 500 tokens）的 session，轻松突破 150K。此时你面临残酷选择：砍掉历史对话（影响连贯性）、压缩工具返回（丢失细节）、或限制单次任务复杂度（降低价值）。这不是优化问题，是范式问题。

2.2 Anthropic 的解法：三层解耦，各司其职

Managed Agents 的架构图没有炫酷的神经网络连线，只有三根清晰的管道：

这个设计的精妙之处在于，它把“状态管理”这个最易出错、最难标准化的部分，完全交给了专业数据库团队（Anthropic 的 SRE 团队），而把“计算执行”这个最易扩展、最易监控的部分，交给了云原生基础设施。开发者只需关心两件事：定义 agent 行为（YAML/prompt）和消费事件日志（SQL 或 API）。

举个具体例子：Notion 团队用 Managed Agents 实现“会议纪要自动归档”。用户在 Notion 页面点击“生成纪要”，触发一个 session：

1. Session 创建：session_id = "notion-20260408-abc123"，初始事件：{"type": "user_input", "content": "整理昨天销售部会议录音", "source": "notion"}
2. Harness 启动：根据 session_id 从 event log 读取最新状态（目前只有用户输入），拉起沙箱
3. Tool Call 1：execute("transcribe_audio", {"url": "s3://bucket/meeting.mp3"})→ 沙箱内调用 Whisper API，返回文本
   • 新事件写入 log：{"type": "tool_call", "name": "transcribe_audio", "input": {...}, "output": "昨天讨论了Q2销售目标...", "duration_ms": 4200}
4. Harness 暂停：等待下一步指令（模型需思考）
5. Tool Call 2：模型决定调用extract_action_items，Harness 拉起新沙箱，注入完整 event log（含 transcribe 结果），执行
   • 新事件：{"type": "tool_call", "name": "extract_action_items", ...}
6. Session 结束：所有事件按时间序存储，可随时用SELECT * FROM events WHERE session_id = 'notion-20260408-abc123' ORDER BY timestamp查询

整个过程，模型 context window 只需承载当前 step 的 prompt + 最新 tool output（< 2K tokens），彻底摆脱窗口焦虑。而所有“记忆”都在 event log 里，像银行流水一样清晰可查。

2.3 为什么 AWS AgentCore 是更早的“操作系统”？

很多人误以为 Anthropic 是 runtime 层的开创者，其实 AWS Bedrock AgentCore 在 2025 年底就已进入通用可用（GA）阶段。它的设计哲学与 Anthropic 高度一致，但更激进地拥抱了云原生范式：

• MicroVM 隔离：每个 session 运行在 Firecracker microVM 中，拥有独占 CPU 核、内存页、文件系统挂载点。这意味着：

  • 一个恶意 tool（如rm -rf /）无法影响其他 session
  • 内存泄露的 Python 进程不会拖垮整个节点
  • 可以安全运行未经审核的第三方 tool 二进制（如闭源财务计算库）

• 框架无关性：AgentCore 不绑定任何 agent 框架。它只认一个接口：request: {input: string, state: any} → response: {output: string, next_state: any, should_continue: boolean}。LangGraph 的 StateGraph、CrewAI 的 AgentExecutor、甚至手写的 while-loop，只要编译成这个协议，就能跑。这就像 Linux 不关心你是用 bash 还是 zsh，只要符合 POSIX syscall 就行。

• 策略即代码（Policy-as-Code）：2026 年 3 月 GA 的 policy controls 允许企业用 YAML 定义：

  # 禁止访问生产数据库，除非有 DBA 审批 - rule: "no_prod_db_access" condition: "input contains 'prod-db' AND not has_approval('dba')" action: "block" # 敏感操作必须双人确认 - rule: "dual_approval_required" condition: "tool == 'send_email' AND email.to in ['ceo@company.com']" action: "require_approval(['ceo', 'cfo'])"

  这些策略在 harness 层拦截，无需修改 agent 代码。它把安全治理从“开发者的责任”变成了“平台的基础设施”。

Anthropic 的 Managed Agents 更像一个“Claude 专属发行版”，而 AWS AgentCore 是“Linux 发行版”。前者开箱即用、深度优化；后者更底层、更开放、更难上手但上限更高。这也是为什么文章说 Anthropic 的发布是“防御性”的——它不是在定义标准，而是在防止自己的核心资产（Claude token）被运行在别人家的操作系统上。

3. 实操要点解析：从 YAML 定义到生产部署的 7 个关键决策点

3.1 Agent 定义：YAML 还是自然语言？选对起点决定 80% 的维护成本

Managed Agents 支持两种 agent 定义方式：结构化 YAML 和自然语言描述。新手常贪图自然语言的便捷，但这是最大的陷阱。

自然语言方式（不推荐用于生产）：

You are a customer support agent for Acme Corp. - Always check the knowledge base first using 'search_kb' tool - If user asks about billing, use 'get_invoice' tool with their email - Never disclose internal SLA times

问题在于：它把行为逻辑、工具约束、安全规则全混在一段文字里。当知识库 schema 变更（比如search_kb新增category参数），你得通读全文找所有相关描述；当合规要求新增“所有响应必须带免责声明”，你得手动在每段 prompt 里补一句。它本质上是把代码逻辑写在注释里。

YAML 方式（强烈推荐）：

# agent.yaml name: "acme-support-v2" description: "Handles tier-1 customer queries with KB and billing tools" system_prompt: | You are Acme Corp's support agent. Follow these rules strictly: 1. Always use 'search_kb' before answering product questions. 2. For billing inquiries, use 'get_invoice' with user's verified email. 3. End every response with: 'Need more help? Contact support@acme.com' tools: - name: "search_kb" description: "Search internal knowledge base. Returns top 3 articles." input_schema: type: "object" properties: query: {type: "string", description: "User's question in natural language"} category: {type: "string", enum: ["billing", "product", "troubleshooting"], default: "product"} # Anthropic validates inputs against this schema BEFORE calling tool - name: "get_invoice" description: "Fetch user's latest invoice. Requires verified email." input_schema: type: "object" properties: user_email: {type: "string", format: "email"} guardrails: - type: "pii_redaction" config: {fields: ["user_email", "phone_number"]} - type: "output_filter" config: {regex: "SLA.*hours", replacement: "[REDACTED]"}

这个 YAML 的威力在于：它既是文档，又是代码，更是合约。input_schema让 Anthropic 在调用前做参数校验，避免get_invoice被传入"admin@acme.com"；guardrails是声明式安全策略，无需 agent 代码里写 if-else；system_prompt保持简洁，聚焦行为而非实现细节。我见过太多团队在自然语言 prompt 里堆砌 200 行规则，最后连自己都记不清第 17 条是什么。YAML 强制你模块化思考。

注意：YAML 中的input_schema必须严格遵循 JSON Schema v7。一个常见错误是把enum写成数组但漏掉type: "string"，导致 Anthropic 无法校验，工具调用直接失败。建议用 JSON Schema Linter 在提交前验证。

3.2 Session 状态管理：何时该用state_store，何时该用context_window

Managed Agents 默认将 session state 存在 Anthropic 的 event log 中，但开发者可以显式指定state_store。这里有个关键权衡：

我建议绝大多数场景坚持默认eventlog。那个“超低延迟”诱惑很大，但代价是：你失去了所有 event log 的能力。当用户投诉“机器人说错了我的贷款利率”，你无法查证是 tool 返回了错误数据，还是模型误读了数字。而现代数据库（如 TimescaleDB）的 p99 查询延迟已压到 5ms 以内，网络开销远小于模型推理本身。别为省 10ms 牺牲可追溯性。

3.3 Credential 隔离：为什么“沙箱里看不到密钥”是生产级底线

Managed Agents 的 credential 隔离机制是其工程严谨性的集中体现。它彻底杜绝了两种高危模式：

• 反模式 1：环境变量注入
  export API_KEY=xxx→ agent 代码里os.getenv("API_KEY")
  危险：agent 可以print(os.environ)泄露所有密钥；LLM 可能被 prompt 注入诱导输出密钥。

• 反模式 2：配置文件挂载
  docker run -v ./secrets:/app/secrets agent→ 代码读secrets/billing_api.key
  危险：沙箱文件系统可被遍历；密钥文件权限若设为 644，其他进程可读。

Managed Agents 的做法是：凭证由 Anthropic Vault 管理，在沙箱启动瞬间，Vault 服务向沙箱内核注入一个只读的内存映射区域（memmap），其中仅包含当前 tool call 所需的 token。沙箱进程通过/dev/vault/token设备文件读取，该设备在本次调用结束后立即失效。

这意味着：

• agent 代码永远无法ls /dev/vault或cat /dev/vault/token（权限拒绝）
• 即使沙箱被攻破，攻击者只能拿到本次调用的短期 token（通常 5 分钟有效期）
• 不同 tool call 使用不同 token，search_kb的 token 无法调用send_email

实操中，你需要在 YAML 里声明 tool 的 credential scope：

tools: - name: "send_email" credential_scope: "email:send" # 对应 Vault 中的 policy input_schema: ...

然后在 Anthropic 控制台为你的 agent service principal 授予email:send权限。这个过程强制你践行最小权限原则——比写 100 行 RBAC 代码更可靠。

3.4 性能调优：p50 降 60% 的秘密不在模型，而在 Harness 启动策略

Anthropic 宣称 Managed Agents 将 p50 time-to-first-token（TTFT）降低约 60%，p95 优于 90%。这个数字常被误解为“模型更快了”，其实核心优化在 harness 层：

• 冷启动 vs 热启动：
  • 冷启动：全新沙箱启动 + Python runtime 初始化 + tool 二进制加载 → ~1200ms
  • 热启动：复用已缓存的沙箱镜像 + runtime 预热 → ~200ms

Managed Agents 默认启用harness pooling：它维护一个沙箱实例池，当awake(sessionId)到来时，优先从池中分配空闲实例，而非每次都新建。池大小可配置：

# 在 agent 配置中 runtime: pool_size: 10 # 维持 10 个预热沙箱 max_idle_time_ms: 300000 # 空闲超 5 分钟回收

但池子不是越大越好。我实测过：pool_size=50 时，p95 TTFT 反而升高，因为沙箱实例间的资源竞争（CPU cache thrashing）加剧。最佳值取决于你的流量峰谷比。建议公式：pool_size ≈ (峰值 QPS × 平均 session 时长) × 1.5。例如峰值 20 QPS，平均 session 30 秒，则20×30×1.5=900，但实际从 20 开始测试，逐步增加。

• 异步 tool call：
  对于 I/O 密集型 tool（如调用外部 API），Managed Agents 支持async: true标记：

  tools: - name: "fetch_market_data" async: true # harness 不等待，继续处理后续 prompt input_schema: ...

  harness 会在后台执行该调用，并在模型需要结果时才阻塞。这避免了“等一个慢 API 拖垮整个 session”。

3.5 定价模型：$0.08/小时背后的成本结构拆解

Managed Agents 定价是$0.08 每 session-hour 的 active runtime，外加 Claude token 费用。这个“session-hour”常被误解为“session 存在时间”，其实是harness 进程的 CPU 时间总和。

举个例子：一个 session 包含 5 个 tool call，每个 call 平均耗时 2 秒（harness 运行），中间模型思考耗时 8 秒（harness 休眠）。那么：

• active runtime = 5 × 2s = 10 秒 = 0.00278 小时
• 费用 = 0.00278 × $0.08 ≈ $0.00022

而如果某个 tool call 因网络问题卡住 300 秒，active runtime 就变成 300+4×2=308 秒，费用跳到 $0.00069。你的最大成本风险点，永远是那些未设 timeout 的外部依赖。

因此，必须在 tool 定义中强制设置超时：

tools: - name: "call_external_api" timeout_ms: 5000 # 超过 5 秒自动 kill 沙箱进程 input_schema: ...

Anthropic 会在此 timeout 前 500ms 发送 SIGALRM，给予 tool 优雅退出机会。若未响应，则强制终止。这个机制比应用层 try-catch 更可靠——它从 OS 层面掐断失控进程。

提示：$0.08/小时看似便宜，但乘以百万级 session，年成本可达数十万美元。建议在非生产环境开启--dry-run模式，它会模拟所有步骤但不计费，用于压力测试。

4. 生产环境实操：从本地测试到灰度发布的全流程

4.1 本地开发闭环：用anthropic-cli模拟全链路

在把 agent 丢给 Anthropic 托管前，必须建立本地可验证的开发流。官方anthropic-cli是关键：

# 1. 安装 CLI（需 Python 3.9+） pip install anthropic-cli # 2. 本地启动 harness 模拟器（无需网络） anthropic-cli harness serve --config agent.yaml # 3. 发送测试 session（CLI 自动创建 session_id） anthropic-cli session create \ --input "帮我查一下订单 #12345 的物流状态" \ --tool "track_shipment" \ --mock-tool-output '{"status": "delivered", "date": "2026-04-07"}' # 4. 查看本地 event log（JSON 格式） anthropic-cli session events --id "local-abc123"

这个流程的价值在于：它把“agent 行为”和“云平台”解耦。你可以用--mock-tool-output精确控制每个 tool 的返回，测试边界 case（如 API 返回空数组、网络超时、JSON schema 错误）。我曾用此方法发现一个严重 bug：当search_kb返回 0 条结果时，agent 的 system_prompt 要求它说“没找到”，但实际它会尝试解析空数组导致崩溃。这个 bug 在云端可能几周都发现不了，因为 0 结果是小概率事件。

4.2 灰度发布策略：用session_tags实现精准流量切分

生产环境不能一刀切切换。Managed Agents 支持session_tags，让你按业务维度分流：

# 为新版本 agent 打标签 anthropic-cli agent update \ --id "acme-support-v2" \ --tag "canary:us-east-1" \ --tag "version:2.1.0" # 在应用代码中创建 session 时指定 tag curl -X POST https://api.anthropic.com/v1/sessions \ -H "x-api-key: $KEY" \ -d '{ "agent_id": "acme-support-v2", "input": "我的订单还没发货...", "session_tags": ["region:us-east-1", "user_tier:premium"] }'

然后在 Anthropic 控制台设置路由规则：

• region:us-east-1 AND user_tier:premium→ 90% 流量到version:2.1.0，10% 到version:2.0.0
• region:eu-west-1→ 100% 到version:2.0.0（暂不升级）

这样，你可以在真实流量中观察新版本的 p95 TTFT、tool call 成功率、用户满意度（通过后续 NPS 问卷关联 session_id），而不会影响整体稳定性。我们曾用此方法发现新版本在user_tier:free流量中失败率飙升——原因是免费用户知识库权限更少，search_kb返回空，而新 prompt 没处理此 case。灰度让我们在影响 1% 用户时就定位了问题。

4.3 监控告警：三个必须盯死的核心指标

不要被 Anthropic 控制台的“健康度”图表迷惑。生产环境需自建监控，紧盯以下三个黄金指标（通过 event log API 拉取）：

我们用 Prometheus + Grafana 实现了实时看板。当Tool Call Timeout Rate突然升到 3%，立刻触发 PagerDuty 告警，值班工程师第一反应不是查 agent 代码，而是登录 AWS CloudWatch 查看track_shipmentAPI 的 P99 延迟——果然，第三方物流服务商在进行蓝绿发布。这避免了 2 小时的无效 debug。

4.4 灾备方案：当 Anthropic 服务不可用时，如何无缝降级

再可靠的 SaaS 也有停服时。Managed Agents 提供fallback_mode配置，允许你在 Anthropic 不可用时，自动切到备用 runtime：

# agent.yaml fallback_mode: enabled: true strategy: "failover" # or "degrade" backup_runtime: type: "aws-bedrock" agent_core_id: "arn:aws:bedrock:us-east-1:123456789012:agent-core/acme-support"

• failover：Anthropic 返回 HTTP 503 时，自动重试到 AWS AgentCore，用户无感知
• degrade：降级为简化版 agent（如只用内置知识库，禁用所有外部 tool）

我们实测过：当模拟 Anthropic 服务中断时，failover模式下平均切换时间 1.2 秒，p95 TTFT 仅增加 15%。关键是，fallback 的 agent 定义必须完全兼容。这意味着你的 YAML 不能用 Anthropic 特有的 guardrail（如output_filter），而要用通用 JSON Schema。我们在 CI/CD 流程中加入检查：anthropic-cli validate --strict-compat agent.yaml，确保它能在所有主流 runtime 上运行。

5. 常见问题与实战排障：那些文档里不会写的坑

5.1 问题：Session 恢复后，agent 总是重复执行上一步

现象：用户中断 session（如关闭网页），5 分钟后回来继续，agent 却重新调用search_kb，而不是接着思考。

根因：awake(sessionId)默认从 event log 的最新事件开始恢复，但如果最新事件是tool_call，harness 会认为“上一步已完成，该模型思考了”。而实际上，模型思考的结果（model_output事件）可能因网络问题未写入 log。

解决方案：在awake请求中显式指定resume_from: "last_model_output"：

curl -X POST https://api.anthropic.com/v1/sessions/abc123/awake \ -H "x-api-key: $KEY" \ -d '{"resume_from": "last_model_output"}'

这告诉 harness：“请从最后一次模型输出后开始，而不是从最后一条日志后开始”。我们把它封装成 SDK 的resume()方法，所有前端调用都走这个路径。

5.2 问题：Tool 返回中文，但 agent 输出乱码（）

现象：search_kb工具返回{"title": "季度财报分析"}，但 agent 输出中显示为{"title": "\u0089\u0094\u008a\u0094\u0086\u0094\u0086\u0094"}。

根因：Tool 二进制在沙箱中以latin-1编码读取 stdout，但实际输出是 UTF-8。Managed Agents 的沙箱默认编码是UTF-8，但某些 legacy tool（如用 C++ 写的旧版搜索器）未正确声明。

解决方案：在 tool 定义中强制指定编码：

tools: - name: "search_kb" encoding: "utf-8" # 显式声明 input_schema: ...

如果 tool 无法修改，可在 harness 层做转码（需 Anthropic 白名单支持）。我们遇到过更隐蔽的情况：tool 调用curl时未加-H "Accept-Charset: utf-8"，导致 API 返回ISO-8859-1。这时必须在 tool 代码里加iconv转换。

5.3 问题：Credential Scope 权限不足，但错误日志只显示 "Access Denied"

现象：get_invoicetool 报错{"error": "Access Denied"}，但 Vault 中明明授予了invoice:read权限。

根因：Managed Agents 的 credential scope 是大小写敏感且精确匹配的。你授予的是invoice:read，但 tool YAML 中写的是invoice:Read（R 大写），或invoice/read（用斜杠而非冒号）。

排查技巧：

1. 在 Anthropic 控制台的Audit Logs中搜索session_id，找到credential_request事件
2. 查看requested_scope字段，与你授予的granted_scope逐字符比对
3. 使用anthropic-cli tool inspect --id get_invoice验证 YAML 中的 scope 字符串

我们曾因此浪费 3 小时——运维同事在 Vault 中授予权限时多打了一个空格："invoice: read"。错误日志不会提示“空格问题”，只会沉默拒绝。

5.4 问题：Event Log 查询变慢，SQL 超时

现象：SELECT * FROM events WHERE session_id = 'xxx'从 100ms 慢到 5s。

根因：Event log 表默认按timestamp分区，但session_id查询需要全表扫描。当单个 session 产生数万事件（如长时监控 agent），性能骤降。

解决方案：联系 Anthropic 支持，申请为高频查询字段创建composite index：

-- Anthropic 内部执行（需工单） CREATE INDEX idx_session_timestamp ON events (session_id, timestamp);

同时，优化查询：

• ❌SELECT * FROM events WHERE session_id = 'xxx'（返回所有字段）
• ✅SELECT type, output, duration_ms FROM events WHERE session_id = 'xxx' AND timestamp > NOW() - INTERVAL '1 hour'（只查必要字段+时间范围）

我们为关键业务 session 设置了session_ttl: "7 days"，避免日志无限膨胀。

5.5 问题：Pricing 突增，账单翻倍

现象：某天账单暴增 300%，但 session 数量只增 20%。

根因：active runtime计费基于harness 进程的 wall-clock 时间，包括：

• Tool 执行时间