AI Agent Runtime 范式革命：会话即事件日志

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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查资料、调 API、写代码、汇总报告——一环扣一环地推进一个复杂任务。我去年就带着团队跑过这样一个销售线索深度分析 Agent：它要从 CRM 拉客户数据，调用第三方风控 API 做信用评分，再结合公开财报做行业对比，最后生成 PPT 脚本。前 35 分钟一切顺利，第 38 分钟，它突然开始胡说八道：把一家已倒闭公司的最新营收写成“同比增长 217%”，把风控报告里的“高风险”误读为“高潜力”。我们翻日志、看 token 统计、重放 prompt——全无头绪。直到把整个 session 上下文 dump 出来，才发现：它的上下文窗口早已被撑爆，最前面的工具调用结果（包括那个关键的风控返回值）被悄悄截断了。模型在残缺的历史上继续推理，就像医生凭半张化验单开处方——不崩溃，但错得悄无声息、代价高昂。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents，表面看是一套托管运行时，内核却直指这个痛点： 它把“会话”（session）从模型的上下文里彻底剥离出来，变成一个独立、持久、可查询的事件日志 。这不是功能叠加，是架构范式的切换。就像 90 年代操作系统把硬件资源虚拟化，让应用不必操心 CPU 寄存器怎么切换、磁盘扇区怎么寻址一样，Managed Agents 把“状态存储”、“工具执行”、“凭证管理”这些原本需要每个开发者自己缝合、反复踩坑的脏活累活，抽象成几个稳定接口： awake(sessionId) 、 execute(toolName, input) 、 log(event) 。你不再和 context window 的字节搏斗，而是和一个有明确生命周期、可审计、可恢复的“会话实体”打交道。

这解释了为什么关键词里反复出现 “Towards AI - Medium”——这篇文章不是技术公告，而是一份面向工程决策者的战情简报。它不教你怎么写 YAML 配置，而是告诉你：当 AWS Bedrock AgentCore 已经 GA 五个月、Vertex AI Agent Builder 和 Azure AI Foundry 全线铺开时，Anthropic 这次发布，本质是一场防御性卡位。它的对手不是某个具体产品，而是整个 runtime 层正在加速发生的“归零效应”：就像虚拟化软件从 VMware 的数万美元/主机，变成 Linux 内核里免费的 KVM 模块；就像容器运行时从 Docker Engine 的商业授权，变成 Kubernetes 标准化的 CRI 接口。你花大价钱买的不是“更快的沙箱”，而是未来十八个月内大概率会免费、开源、被云厂商打包进基础账单的基础设施层。真正值得你投入时间研究的，是那些能活过这场压缩的上层建筑——可观测性平台、策略治理引擎、垂直领域智能体市场。这才是本文想让你看清的底牌。

2. 核心设计拆解：为什么“会话即事件日志”是唯一正确的解法

2.1 传统 Agent 架构的致命伤：上下文即牢笼

绝大多数自建 Agent 系统，其状态管理逻辑都遵循一个朴素但危险的模式：把所有历史对话、工具调用结果、中间变量，一股脑塞进模型的 context window。这看似简单直接，实则埋下三重定时炸弹：

• 容量天花板不可逾越 ：Claude 3.5 Sonnet 的上下文上限是 200K tokens，听起来很大。但实际场景中，一次调用 Slack API 返回的 JSON 可能就占 3K tokens，一个中等长度的 PDF 解析结果轻松破 10K。当你的 Agent 需要串联 5 个工具、处理 3 份文档、生成 2 版草案时，context 很快就逼近临界点。更糟的是，模型不会报错，它只会静默丢弃最早的内容——就像往满杯水里继续倒水，溢出的部分你根本看不见。

• 状态不可追溯、不可调试 ：当 Agent 行为异常，你只能看到最终输出和当前 prompt。中间哪一步工具返回了错误数据？哪个 guardrail 规则被绕过了？哪次重试导致了逻辑偏移？没有结构化日志，你只能靠猜。我见过团队为定位一个“偶尔漏发邮件”的 bug，花了三天时间手动重放 17 个 session，只因缺乏统一 trace store。

• 故障不可恢复、不可重放 ：Harness（执行器）进程崩溃？服务器重启？网络抖动导致 tool call 超时？传统架构下，session state 随进程消亡而消失。用户被迫从头开始，Agent 之前的所有努力付诸东流。这在客服、金融等强状态场景中是灾难性的。

提示：不要迷信“增大 context window”是终极方案。Anthropic 自己的工程博客明确指出：“The model context window stops being the load-bearing storage layer.” —— 上下文窗口不该是承重墙，而应是轻质隔断。这是对过去三年 Agent 开发范式最犀利的否定。

2.2 Anthropic 的三层解耦：Session、Harness、Sandbox

Managed Agents 的架构图看起来简洁，但每一层都针对上述痛点做了精准手术：

• Session 层：持久化、结构化、可查询的事件日志
  这是整个设计的基石。每次 Agent 启动，Anthropic 为其分配一个全局唯一 sessionId ，所有操作——用户输入、系统提示、工具调用请求与响应、guardrail 触发、错误堆栈——都被序列化为结构化事件（JSON），写入外部持久化存储（推测为分布式 OLAP 数据库）。这意味着：

  • 无限回溯 ：你可以随时 GET /sessions/{id}/events?from=2026-04-08T10:00:00Z&to=2026-04-08T10:30:00Z 查询任意时间段的完整行为链。
  • 精准重放 ： awake(sessionId) 不是加载一个模糊的“上下文快照”，而是重建整个事件流，确保每次 resume 都从完全一致的状态出发。
  • 合规审计 ：企业安全团队可以直接查询 SELECT * FROM events WHERE sessionId = 'xxx' AND eventType = 'tool_call' AND toolName = 'send_email' ，满足 SOC2 审计要求。

• Harness 层：无状态、轻量、可水平伸缩的执行器
  Harness 是真正的“瘦客户端”。它不保存任何业务状态，只负责解析 Session 事件流，根据当前状态决定下一步调用哪个工具，并将结果封装成新事件提交给 Session 层。它的核心接口只有两个：

  • execute(toolName, input) → string ：向沙箱发起调用，返回原始字符串（非 JSON 解析，避免二次序列化开销）。
  • awake(sessionId) → harnessState ：从 Session 层拉取最新事件流，重建执行上下文。
    这种设计让 Harness 可以像 Web 服务器一样随意扩缩容。一个 Harness 实例挂了？新实例 awake() 一下就能无缝接续。成本也极低——Anthropic 的 $0.08/session-hour 定价，本质上是对 Harness 计算资源的计量，而非对“智能”的收费。

• Sandbox 层：按需创建、隔离彻底、凭证零暴露的执行环境
  这是生产级安全的底线。Managed Agents 的沙箱不是 Docker 容器，而是基于 Firecracker 微虚拟机（microVM）或类似轻量级 VMM 技术构建。每个 tool call 都在全新的、隔离的 microVM 中执行，拥有独占的 CPU、内存、网络栈和根文件系统。最关键的是凭证管理：

  • 凭证绝不注入环境变量 ：传统做法是 docker run -e API_KEY=xxx my-tool ，Agent 进程可通过 os.environ 读取。Managed Agents 强制要求凭证由 Anthropic Vault 管理，沙箱启动时仅获得一个短期、作用域受限的访问令牌（token），且该令牌无法被 Agent 代码直接读取或泄露。
  • 网络白名单硬隔离 ：沙箱默认无外网访问权限，必须显式声明所需域名（如 notion.so , asana.com ），Anthropic 的网络网关会严格 enforce。

这种三层解耦，让 Anthropic 成功将“状态管理”这个最易出错、最难运维的模块，从开发者肩上卸下，交给了一个经过大规模验证的、可信赖的托管服务。它不是炫技，而是把工程师从“胶水代码民工”解放为真正的业务逻辑建筑师。

3. 实操要点与细节深挖：从 YAML 配置到生产部署避坑指南

3.1 你的第一个 Managed Agent：YAML 配置详解

Managed Agents 支持两种定义方式：自然语言描述（适合 PoC）和 YAML（生产必备）。以下是一个真实可用的、用于自动处理 GitHub Issue 的 Agent YAML 示例，我已标注每一行的生产意义：

# agent.yaml
name: "github-issue-resolver"
description: "Automatically triage, research, and draft responses for GitHub issues"
version: "1.0.0"

# 【核心】系统提示，定义 Agent 的角色、能力边界和输出规范
system_prompt: |
  You are a senior GitHub maintainer for an open-source LLM toolkit.
  Your job is to:
  1. Classify the issue type (bug, feature request, question, documentation)
  2. If it's a bug: search GitHub issues for duplicates using the 'search_issues' tool
  3. If it's a feature request: check the project roadmap via 'get_roadmap' tool
  4. Always respond in Markdown with clear sections: ## Classification, ## Research Summary, ## Suggested Response
  5. NEVER invent facts. If a tool fails, say "Unable to verify".

# 【关键】工具注册表，定义 Agent 可调用的外部能力
tools:
  - name: "search_issues"
    description: "Search existing GitHub issues for duplicates. Input: {query: string}"
    # Anthropic 托管的工具，无需你实现，只需配置参数映射
    parameters:
      query: "$.input.query"  # 将用户输入中的 query 字段映射给工具

  - name: "get_roadmap"
    description: "Fetch the current public product roadmap. Input: {}"
    # 无参数工具，直接调用
    parameters: {}

  - name: "post_comment"
    description: "Post a comment on a GitHub issue. Input: {issue_number: number, body: string}"
    # 这是你自定义的工具，需提供 endpoint 和 auth
    endpoint: "https://api.your-company.com/v1/github/comment"
    auth:
      type: "vault"  # 强制使用 Anthropic Vault，非环境变量！
      vault_key: "github-bot-token"  # Vault 中预存的密钥名

# 【安全生命线】Guardrails，防止越界行为
guardrails:
  # 阻止任何尝试读取本地文件或执行 shell 命令的 prompt 注入
  - type: "prompt_injection"
    action: "block"
    message: "I cannot execute system commands or read local files."

  # 限制工具调用频率，防滥用
  - type: "rate_limit"
    tool_name: "search_issues"
    max_calls_per_hour: 10

  # 强制所有输出必须包含指定的免责声明
  - type: "output_filter"
    regex: "This response was generated by an AI assistant."
    action: "append_if_missing"

# 【生产必需】会话生命周期管理
session_config:
  # 默认 24 小时，超时后自动清理，避免僵尸 session 占用资源
  ttl_hours: 24
  # 启用自动 checkpoint，每 5 分钟或每次 tool call 后保存事件
  auto_checkpoint: true

注意： auth.type: "vault" 是生产环境的强制要求。如果你在 YAML 中写 auth: {type: "env", key: "GITHUB_TOKEN"} ，Anthropic 的部署校验会直接失败。这是架构设计的铁律，不是可选项。

3.2 生产部署的四大雷区与我的血泪经验

部署 Managed Agents 到生产环境，远不止 anthropic deploy -f agent.yaml 这么简单。以下是我在三个不同客户项目中踩过的坑，以及对应的解决方案：

• 雷区一：Tool Endpoint 的幂等性陷阱
  问题：我们的 post_comment 工具在 GitHub API 失败时会重试，但未实现幂等。一次网络抖动导致 Agent 重复调用了 3 次 post_comment ，同一 Issue 下出现了三条一模一样的回复。
  解决方案： 所有自定义 Tool Endpoint 必须实现幂等键（Idempotency Key） 。我们在 post_comment 的请求头中加入 X-Idempotency-Key: ${sessionId}-${timestamp}-${call_id} ，后端服务据此去重。Anthropic 的 execute() 调用会自动携带 call_id ，你只需透传。

• 雷区二：Guardrail 规则的“假阳性”泛滥
  问题： prompt_injection guardrail 过于激进，将用户正常提问 “How do I use curl to call your API?” 误判为注入攻击，直接阻断。
  解决方案： Guardrail 需分层配置，且必须启用日志审计 。我们将 prompt_injection 的 action 从 block 改为 log_and_warn ，同时开启 guardrail_events 日志流。通过分析一周的日志，发现 92% 的误报来自特定词汇组合（如 curl + API + token ）。于是我们新增一条白名单规则： if input contains "curl" and "API" and not "token" then allow 。 永远先观察，再拦截。

• 雷区三：Session TTL 与业务 SLA 的错配
  问题：金融客户的“贷款审批 Agent”平均耗时 45 分钟，但我们配置了默认 ttl_hours: 24 。某次长流程中，Harness 因 GC 暂停了 2 秒，导致 awake() 调用延迟，Session 被后台清理，整个审批流程中断。
  解决方案： TTL 必须基于 P95 业务耗时动态计算 。我们改用 ttl_hours: ${P95_DURATION_IN_HOURS} + 2 ，并通过 anthropic session update --ttl-hours 2 在流程关键节点（如开始人工审核前）动态延长 TTL。 Session 是活的，不是静态配置。

• 雷区四：沙箱网络策略的“隐形墙”
  问题：Agent 调用内部 get_roadmap 工具失败，错误日志只显示 Connection refused 。排查数小时才发现，该工具 endpoint 位于公司内网 10.0.0.0/8 ，而 Anthropic 沙箱默认只允许访问公网。
  解决方案： 必须显式声明所有依赖域名和 IP 段 。在 YAML 中添加：

  sandbox_network:
    allowed_domains:
      - "internal-api.your-company.com"
      - "10.0.0.0/8"  # CIDR 格式，支持内网段
    blocked_domains:
      - "malicious-site.com"  # 黑名单优先级更高
  

  Anthropic 的网络网关会实时生效，无需重启。

3.3 定价模型的精算：何时自建更划算？

Anthropic 的定价是 $0.08 per session-hour of active runtime + Claude token 费用。很多人只看 $0.08 ，却忽略了“active runtime”的定义。官方文档明确： Active runtime 仅计算 Harness 进程实际在 CPU 上执行的时间，不包括等待 tool call 响应、网络 IO、或 sleep() 的时间 。这很合理，但容易误读。

我们做了个真实测算：一个典型的客服 Agent，平均每次 session 包含：

• 用户输入处理：0.2 秒
• 调用 3 个工具（CRM、知识库、邮件系统），平均每个 tool call 等待 1.5 秒（网络+后端处理），Harness 本身空转等待：4.5 秒
• 生成回复：0.3 秒
• 总耗时约 5 秒，但 active runtime ≈ 0.2 + 0.3 = 0.5 秒 ，其余 4.5 秒是 IO 等待，不计费。

因此，一个日均 10,000 session 的业务，年 session-hour 成本约为：
10,000 sessions/day * 0.5 seconds/session / 3600 seconds/hour * 365 days * $0.08/hour ≈ $40.56

这几乎可以忽略不计。真正的大头是 Claude token 费用（尤其是输入长文档时）。所以，Managed Agents 的经济价值不在于“省服务器钱”，而在于 省掉你组建一支 3-5 人 infra 团队的成本 ——他们要负责沙箱安全审计、凭证轮换、session 存储扩容、trace 日志分析、guardrail 规则迭代……这些隐性成本，远超 $0.08/session-hour 。

4. 竞争格局全景扫描：为什么说 runtime 层正在“归零”

4.1 三大云厂商的“降维打击”：免费即正义

Anthropic 的 Managed Agents 发布稿里没提一个字，但它的最大对手早已存在——AWS Bedrock AgentCore。后者在 2025 年底 GA，到 2026 年 3 月，SDK 下载量突破 200 万次。它的杀手锏是什么？ 不是技术更先进，而是“免费” 。

Bedrock AgentCore 的定价模型是： 无单独 runtime 费用 。你只需为底层的 Bedrock 模型调用（如 Claude、Llama 3）付费，AgentCore 的 Harness、Sandbox、Session 管理全部作为 Bedrock 服务的一部分，零成本使用。对于已经在 AWS 上有大量云支出的企业客户，采购决策链路是： 现有 AWS 账户 -> 已开通 Bedrock -> 直接启用 AgentCore 。不需要额外预算、无需安全评估新供应商、无需学习新 API。这就是“云厂商的护城河”。

同样，Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 也走此路径。它们的共同策略是： 将 runtime 层作为吸引客户使用自家模型的“诱饵”（loss leader） 。你用 Vertex 的 Gemini，就免费用 Vertex 的 Agent Runtime；你用 Azure 的 Phi-3，就免费用 Foundry 的 Sandbox。这种捆绑，让 Anthropic 的 $0.08/session-hour 在企业采购视角下，瞬间变成“多付一笔不必要的费用”。

提示：别被“GA”（General Availability）这个词迷惑。AWS AgentCore 的 GA 意味着它已通过金融、医疗等严苛行业的合规认证（SOC2, HIPAA），而 Anthropic 的“public beta”目前尚未公布同等认证状态。对银行客户而言，“GA”意味着“敢用”，“beta”意味着“再等等”。

4.2 开源势力的闪电崛起：Daytona 与 Kubernetes SIG 的挑战

如果说云厂商是“免费”，那开源社区就是“免费且开放”。2025 年初，原 DevOps 工具厂商 Daytona 宣布战略转向 AI Agent Infrastructure，并在 2026 年 2 月完成 2400 万美元 A 轮融资。其核心产品 Daytona Agent Runtime 的亮点是： 亚 90ms 的沙箱冷启动时间 （比 Anthropic 宣称的 200ms 快一倍以上），且完全开源（Apache 2.0）。

更值得关注的是 Kubernetes 社区的动作。2026 年 3 月，Kubernetes SIG-ai 正式发布了 k8s-agent-sandbox 项目，这是一个标准的 Kubernetes CRD（Custom Resource Definition），允许你用 kubectl apply -f agent-sandbox.yaml 在自己的 K8s 集群中一键部署一个符合 OPA（Open Policy Agent）策略的、基于 gVisor 的安全沙箱。这意味着：

• 你可以将 Managed Agents 的 YAML 配置，无缝转换为 k8s-agent-sandbox 的 CRD。
• 所有 session logs 自动流入你已有的 Loki/Prometheus 栈。
• Guardrail 策略用 Rego 语言编写，复用你现有的 OPA 策略库。

这种“标准化 + 开源”的组合拳，正在快速侵蚀 Managed Agents 的技术壁垒。当你能在自己的集群里，用熟悉的 kubectl 命令，获得媲美甚至超越 Anthropic 的沙箱性能和可观测性时， $0.08/session-hour 的溢价理由就只剩下一个： 品牌信任 。而品牌信任，在企业级采购中，往往是最先被砍掉的预算项。

4.3 垂直领域市场的爆发：Salesforce Agentforce 的启示

当 runtime 层在价格和技术上被压至“归零”时，价值必然向上迁移。Salesforce 的 Agentforce 是最清晰的信号灯。截至 2026 年 Q4，其 ARR（年度经常性收入）达 8 亿美元，同比增长 169%，签下 29,000 笔企业合同。它卖的不是“runtime”，而是 预装了 Salesforce CRM 深度集成、内置销售 SOP 流程、绑定 Sales Cloud 许可证的“销售开发 Agent” 。

客户采购 Agentforce，不是因为它比 Anthropic 的 Harness 快，而是因为：

• 它的 create_lead 工具，能直接写入客户 CRM 的 Lead 对象，字段映射、权限校验、触发工作流全部预置。
• 它的 research_account 工具，能自动关联客户在 LinkedIn、Crunchbase 的最新融资信息，并生成定制化 cold email。
• 它的 forecast_deal 工具，能基于历史赢单率、当前阶段停留时长、竞争对手情报，给出概率化预测。

这揭示了一个残酷现实： 企业愿意为“解决具体业务问题的 Agent”付费，而不是为“运行 Agent 的沙箱”付费 。所以，Virattt 的 ai-hedge-fund （金融对冲基金 Agent）、Vxcontrol 的 pentagi （渗透测试 Agent）这些开源项目，虽然技术上可能不如 Managed Agents 成熟，但它们正以极快的速度占领“垂直心智”。因为它们回答的是 CEO 的问题：“这个 Agent 能帮我多赚多少钱？少招几个人？”

5. 未来价值高地：Trace Store、Governance、Vertical Marketplace 三足鼎立

5.1 Trace Store：谁掌控了 Agent 的“行车记录仪”，谁就掌控了真相

当 runtime 层 commoditize，第一个被争夺的上层是 Trace Store ——Agent 行为的唯一、权威、可移植的记录系统。目前有三股力量在角力：

实操心得：我们为客户做的选型测试中，Arize Phoenix 的 trace_id 与 span_id 生成逻辑，完美兼容 OpenTelemetry 的 W3C Trace Context 标准。这意味着，你今天用 Phoenix 记录 Agent 的 execute() 调用，明天就能和你已有的微服务链路追踪（如 Jaeger）打通，形成端到端的“用户请求 -> Agent 决策 -> 后端服务”全景图。这种互操作性，是 Brainstore 和 LangSmith 目前不具备的硬实力。

5.2 Governance & Policy：从“能做什么”到“该做什么”的合规革命

OWASP Agentic Top 10 的发布，标志着 Agent 安全已从技术议题升级为合规议题。企业采购部门现在会问：

• 这个 Agent 被允许调用哪些外部 API？（网络策略）
• 它能访问哪些客户数据字段？（数据掩码策略）
• 当它生成代码时，是否禁止使用 eval() 或 exec() ？（代码安全策略）
• 如果它建议裁员，是否触发人工审核？（伦理策略）

AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls，正是对此的回应。它允许你用 JSON Schema 定义策略：

{
  "policy": {
    "network": {
      "allowed_domains": ["salesforce.com"],
      "blocked_patterns": [".*\.malware.*"]
    },
    "data_masking": {
      "pii_fields": ["email", "ssn"],
      "masking_rule": "redact"
    }
  }
}

但这只是起点。真正的治理战场在 Policy-as-Code 的编排层 。比如，一个金融客户的策略可能是：“当 Agent 处理 loan_application 类型 session 时，自动启用 financial_regulation_v2026 策略包，该包包含 17 条 GDPR 和 CCPA 合规规则”。这需要一个策略编排引擎，能根据 session metadata 动态加载、组合、执行策略。目前，这个领域尚无公认的领导者，但 Arize 和 LangSmith 都在快速跟进。 谁能提供最灵活、最可审计、最易与企业 IAM（如 Okta）集成的 Policy 编排，谁就拿到了下一张门票。

5.3 Vertical Marketplace：当 Agent 成为 SaaS 的新形态

Salesforce Agentforce 的成功，验证了一个公式： Vertical Agent = Pre-integrated Tools + Domain-Specific Workflow + Business Outcome Pricing 。它不按“调用次数”或“token 数”收费，而是按“每月成功转化多少销售线索”或“每季度节省多少客户服务工时”收费。

这催生了全新的商业模式。例如，医疗领域的 healthcare-claims-agent ，其核心价值不是“快”，而是“准”：

• 它必须 100% 正确识别 ICD-10 诊断码和 CPT 手术码。
• 它必须自动匹配保险公司最新的拒付规则（如 Medicare 的 Local Coverage Determinations）。
• 它的输出不是“建议”，而是可直接提交给保险公司的 EDI X12 837 电子理赔单。

这类 Agent 的交付，不再是部署一个 YAML 文件，而是：

1. 数据接入 ：连接医院的 EMR（如 Epic）和保险公司的 EDI 网关。
2. 规则训练 ：用历史理赔数据微调模型，确保编码准确率 >99.5%。
3. 合规认证 ：通过 HIPAA 审计，获得 BAA（Business Associate Agreement）。
4. 效果对赌 ：合同约定，若自动理赔通过率低于 95%，按差额退款。

这种深度绑定业务结果的模式，让 runtime 层的差异变得无关紧要。客户不在乎你是用 Anthropic 的沙箱，还是 AWS 的 microVM，只要 Agent 能把理赔单正确、合规、高效地送出去。 价值锚点，已经从“技术栈”彻底转移到“业务域”。 这就是为什么，资本正疯狂涌入 ai-hedge-fund 、 pentagi 这些项目——它们不是在卖技术，是在卖“金融”、“安全”这些百年老行业的数字化新入口。

6. 我的实战体会：如何在“归零浪潮”中站稳脚跟

我在过去一年，主导了三个不同规模的 Agent 项目：一个为电商客户做的“智能客服 Agent”，一个为律所做的“合同审查 Agent”，还有一个为制造业客户做的“设备故障诊断 Agent”。每一次上线，我都深刻体会到，技术选型的胜负手，从来不在 runtime 层的毫秒级差异，而在于你能否看清并押注于价值迁移的方向。

最深刻的教训来自那个律所项目。初期，我们花了三个月，精心打磨了一个基于自研 Harness 的、支持 128K context 的合同审查 Agent，自豪于它能一次性吃下整份并购协议。上线后，律师反馈却很冷淡：“它确实能总结条款，但当我问‘如果买方违约，我方索赔的最高限额是多少？’，它总在协议里找不到答案，或者答错。” 后来我们才发现，问题不在模型，而在 Trace Store 的缺失 。律师需要的不是一份摘要，而是一条可追溯的证据链： 问题 -> 定位到第 7.2 条 -> 提取‘Liability Cap’字段 -> 计算公式 -> 输出结果 。没有结构化 trace，模型的回答就是黑箱。我们立刻切换到 Arize Phoenix，重构了整个输出 pipeline，强制每个结论都附带 trace_id 。结果，律师们开始主动用 trace_id 去和对方律师辩论条款解释——因为那是可验证、可审计的“事实”，而非 AI 的“意见”。那一刻我明白了： 在专业服务领域，可信度比速度重要一百倍，而可信度的基石，是透明、可追溯的 trace。

另一个体会是关于“垂直”的执念。我们曾试图做一个通用的“法律 Agent”，支持合同、诉讼、知识产权。结果，每个领域的需求都南辕北辙：合同律师要精确到小数点后两位的金额计算，诉讼律师要能关联上百个判例的相似性，IP 律师要能解析复杂的专利权利要求书。最后，我们放弃了“通用”，专注做“并购合同审查 Agent”，把 80% 的精力投入到和顶尖并购律师合作，梳理出 37 个关键条款的审查 checklist，并将其固化为 Guardrail 规则和 Tool 的输出 schema。上线半年，它成了律所的“标配”，客户甚至愿意为它单独签一份年费合同。这印证了文章里的判断： 当 runtime 归零，价值必然沉淀在垂直场景的深度里。通才难赢，专才必胜。

最后一点，也是最容易被忽视的： 自我进化 Agent 的监管，已是迫在眉睫的现实 。Sakana AI 的 Darwin Gödel Machine 论文不是科幻。我们已在测试环境中部署了一个简单的“Agent 自优化”循环：它定期分析自己的 trace log，识别出高频失败的 search_case_law 工具调用，然后调用 rewrite_tool_code 工具，用 Claude 生成新的检索逻辑，并在沙箱中验证效果。一旦通过，就自动更新生产版本。这个过程，让我们的合同审查准确率在三个月内提升了 11%。但随之而来的是巨大的责任：如果它重写的代码引入了安全漏洞，或者改变了法律解释的倾向性，谁来担责？是 Anthropic？是我们？还是那个写初始 prompt 的实习生？这个问题，没有技术答案，只有治理答案。所以，我现在所有的新项目，第一件事就是和客户法务一起，起草一份《AI Agent 自进化治理协议》，明确规定：哪些模块允许自优化、优化后的代码必须经过几轮人工审计、失败回滚的 SLA 是多少。 技术可以飞速迭代，但信任的建立，永远需要坚实的治理框架来托底。 这，或许才是 runtime 归零之后，我们这一代 AI 工程师，最该认真对待的命题。