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

你有没有试过让一个 AI 代理连续工作四十分钟，处理一份需要反复查文档、调 API、改代码的复杂任务？我去年就干过这事。当时所有状态都堆在模型上下文里——系统提示、用户对话、工具返回结果、中间思考链，全塞进那个有限的 token 窗口。前二十分钟还行，到第三十分钟后开始掉链子：它突然把刚查到的数据库字段名记成另一个表里的，接着生成的 SQL 就全错了；再往后，它甚至开始编造没调用过的 API 响应。最要命的是，它没报错，没中断，只是安静地、持续地、越来越离谱地胡说八道。等我们发现时，整个 session 已经不可逆地污染了。没有日志可查，没有快照可回滚，没有事件流可审计——你只能重来，从头开始，损失掉那四十分钟里所有人工无法复现的推理路径和决策依据。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents，表面看是一套托管运行时，但它的核心价值，恰恰就是为了解决我上面描述的这个“安静崩溃”的噩梦。它把 session 拆成了三块： 事件日志（state） 、 无状态执行器（harness） 和 隔离沙箱（sandbox） 。这三块不是营销话术，而是经过生产环境验证的架构分层。Session 不再是模型上下文里一团混沌的文本流，而是一个持久化、可查询、可回放的结构化事件序列，存在 Anthropic 的后端服务里；harness 只负责按需拉起、传入输入、拿到输出，它本身不存任何状态，挂了就挂了， awake(sessionId) 一调，立刻从上次 checkpoint 继续；沙箱则彻底与凭证隔离——你的 AWS 密钥、Slack Bot Token、数据库密码，全由 Anthropic 的密钥管理服务注入沙箱内部，绝不会以环境变量形式暴露给 agent 代码。这意味着，哪怕 agent 被 prompt 注入攻破，它也拿不到任何真实凭证。

这个设计，本质上是在复刻上世纪 90 年代操作系统的虚拟化革命。当年，操作系统把物理内存、磁盘、CPU 这些硬邦邦的硬件，抽象成虚拟内存地址、文件描述符、进程 ID 这些稳定接口，让上层应用不必关心底层硬件型号。今天，Managed Agents 把模型推理、状态存储、工具执行、安全隔离这些原本耦合在一起的“硬件级”能力，抽象成 execute(name, input) → string 这样干净的函数调用，以及 session_id 这样可跨请求传递的句柄。开发者写 agent 逻辑时，不再需要自己搭 Redis 存 session、写 Dockerfile 隔离工具、轮询密钥 Vault、手动记录 trace——这些都变成了平台提供的、稳定的、向后兼容的“系统调用”。关键词不是“AI agent”，而是“runtime abstraction”；不是“Claude 多强”，而是“state 与 harness 的解耦有多彻底”。这才是它值得被认真对待的原因：它不是又一个聊天机器人后台，而是 AI 应用真正开始具备操作系统级可靠性的第一个工业级信号。

2. 核心细节解析：为什么 session-as-event-log 是唯一正确的解法

2.1 上下文窗口不是数据库，它是易失性缓存

很多团队在构建长周期 agent 时，第一反应是“加大上下文窗口”。Claude 3.5 Sonnet 支持 200K tokens，GPT-4o 也到了 128K，看起来够用了？错。上下文窗口的本质，是模型推理时的一块高速缓存（cache），不是持久化存储（storage）。它的设计目标是让模型在单次推理中看到足够多的“当前上下文”，以便做出连贯响应。但它有三个致命缺陷：

• 无序覆盖 ：当新内容写入导致超限，模型或框架通常采用 LRU（最近最少使用）策略丢弃旧内容。但 agent 的关键状态（比如第一步查到的客户 ID、第三步生成的临时文件路径）往往不是“最近使用”的，它们会被静默淘汰，而模型对此毫无感知。
• 语义模糊 ：缓存里存的是自然语言文本，不是结构化数据。模型需要自己从一堆对话历史里“理解”出当前 session 的 state，这个过程本身就是一次不可靠的推理，极易出错。
• 不可审计 ：一旦 session 结束，这段文本就散落在日志里，没有 schema，没有索引，无法按时间戳、工具名、错误类型做聚合分析。你想知道“过去一周里，有多少次 Slack 工具调用失败是因为 token 过期？”，答案是：基本查不到。

Anthropic 的 event log 方案，直接绕开了这三个缺陷。它把每一次关键动作都固化为一个带 schema 的事件：

{
  "event_id": "evt_abc123",
  "session_id": "sess_xyz789",
  "timestamp": "2026-04-08T14:22:31.456Z",
  "type": "tool_call",
  "tool_name": "notion_search_pages",
  "input": {"query": "Q4 marketing plan"},
  "output": [{"id": "page_111", "title": "Q4 Marketing Plan Draft"}],
  "status": "success"
}

这个结构天然支持按任意字段过滤、排序、聚合。更重要的是，它把“状态”从模型的“认知负担”里剥离出来，变成一个外部可验证、可回放、可版本化的事实源。当你需要 debug 一个失败的 session，你不是去翻几千行对话日志，而是直接查 SELECT * FROM events WHERE session_id = '...' AND status = 'error' ORDER BY timestamp ，几秒内就能定位到问题源头。

2.2 Credential isolation：不是“防君子”，是防“被利用的君子”

关于凭证隔离，很多团队会想：“我们自己用环境变量传 token，加个 .env 文件，再 gitignore 掉，不就安全了吗？” 这种思路在传统 Web 开发里或许勉强可行，但在 agent 场景下，它是灾难性的。原因在于：agent 的行为是动态生成的，它的代码路径不是静态编译好的，而是由模型实时决定的。

举个真实案例：去年一家 SaaS 公司的客服 agent，系统提示里明确写了“禁止调用任何非客服 API”。但某次用户问：“能帮我查下我的 AWS 账户余额吗？”，模型在思考链里判断“查余额”属于客服范畴，于是自动生成了一段 Python 代码，调用 boto3.client('billing').get_cost_and_usage(...) 。这段代码被沙箱执行，而它的环境变量里，恰好有公司预设的、拥有 billing:Describe* 权限的 IAM Role 凭证。结果 agent 不仅查了余额，还顺手把近三个月的详细账单导出并发送给了用户。这不是恶意攻击，是模型在“善意”执行指令时，被自己的权限放大了错误。

Managed Agents 的解法是釜底抽薪：凭证根本不在沙箱的环境变量里。Anthropic 的沙箱启动时，会向其内部的 credential service 发起一个受控的、单向的、带 TTL 的请求，换取一个临时的、作用域极窄的访问令牌（例如，只允许对特定 Notion workspace 的 pages.search 接口调用一次）。这个令牌甚至不会以字符串形式出现在沙箱的内存里，而是由沙箱内的一个轻量级 proxy 进程持有，并在每次调用时动态注入。agent 代码看到的，只是一个普通的 notion_search_pages(input) 函数调用，它完全不知道背后发生了什么。这种设计，让“模型生成危险代码 + 环境变量泄露凭证”这个经典攻击链，在架构层面就被切断了。它不是靠开发者自觉，而是靠基础设施强制。

2.3 Pricing model：$0.08/session-hour 的真实成本结构

定价从来不是拍脑袋定的。$0.08 每 session-hour 的背后，是 Anthropic 对 runtime 成本的精细拆解。我们来算一笔账：

• Compute Cost ：一个典型的 agent session，大部分时间其实是在等待 I/O（API 响应、数据库查询、文件读写）。真正占用 CPU 做模型推理的时间，可能只占 5%-10%。Anthropic 的 harness 是无状态的，可以极致复用——一个 harness 实例可以轮询处理成百上千个 session 的 execute 请求，只要它们不同时触发。这大幅摊薄了 CPU 成本。
• State Storage Cost ：event log 是 append-only 的，写入密集但读取稀疏。用对象存储（如 S3）+ 索引服务（如 DynamoDB）的组合，成本极低。一个 session 一天产生 100 个事件，每个事件平均 2KB，一年下来也就 70MB，存储成本不到 $0.01。
• Sandbox Orchestration Cost ：沙箱是 on-demand provisioned 的“cattle”，不是“pets”。它用的是轻量级容器（很可能是 Firecracker microVM 或类似技术），启动时间 < 100ms，生命周期短（通常几分钟到几小时）。AWS Lambda 的冷启动成本已经压到毫秒级，Anthropic 作为专业玩家，只会更低。
• Security & Compliance Overhead ：凭证管理、审计日志、合规认证（SOC2, ISO27001）这些隐性成本，是自建方案最烧钱的部分。Anthropic 把它打包进 $0.08 里，对中小团队反而是省钱的——你不用再养一个专职的安全工程师来 review 每个 agent 的 sandbox 配置。

所以，$0.08 不是“高价抢市场”，而是“精准覆盖成本+合理毛利”的理性定价。它暗示了一个关键信号：这个 runtime 层，已经进入了可规模化、可预测成本的工业化阶段。当你能清晰地算出每小时的边际成本，就意味着它不再是实验室玩具，而是可以放进企业 IT 预算表里的正式基础设施。

3. 实操过程与核心环节实现：从 YAML 定义到生产部署

3.1 Agent 定义：YAML 是生产力，不是妥协

很多人看到“用 YAML 定义 agent”，第一反应是“这太原始了，不如写 Python 灵活”。但 Anthropic 的 YAML 设计，恰恰是深谙工程实践后的克制选择。它不是为了取代代码，而是为了分离关注点。一个典型的 agent.yaml 长这样：

# agent.yaml
name: "sales-assistant-v2"
description: "Helps sales reps draft personalized emails and track follow-ups"

system_prompt: |
  You are a senior sales development representative at Acme Corp.
  Your goal is to help reps close deals faster by drafting emails and updating CRM.
  Always use the tools provided. Never fabricate CRM data.

tools:
  - name: "hubspot_search_contacts"
    description: "Search HubSpot contacts by email or company name"
    input_schema:
      type: "object"
      properties:
        email: { type: "string" }
        company: { type: "string" }

  - name: "gmail_send_email"
    description: "Send an email via Gmail API"
    input_schema:
      type: "object"
      properties:
        to: { type: "string" }
        subject: { type: "string" }
        body: { type: "string" }

guardrails:
  - type: "content_filter"
    severity: "block"
    categories: ["harassment", "hate_speech"]
  - type: "tool_call_policy"
    allowed_tools: ["hubspot_search_contacts", "gmail_send_email"]
    disallowed_patterns: ["rm -rf", "curl.*--data.*token"]

lifecycle:
  max_session_duration_hours: 8
  auto_terminate_on_idle_minutes: 30

这个 YAML 文件，定义了 agent 的 身份（system_prompt） 、 能力边界（tools） 、 安全红线（guardrails） 和 生命周期规则（lifecycle） 。它之所以高效，是因为：

• 可版本化 ：YAML 是纯文本，可以像代码一样 git commit 、 git diff 、 git revert 。你能清晰地看到“v1.2 版本增加了 gmail_send_email 工具，移除了 curl 工具”。
• 可审查 ：安全团队不需要懂 Python，就能读懂这个 YAML 是否符合公司的数据政策。他们可以直接在 PR 里评论：“ hubspot_search_contacts 的 input_schema 必须增加 company 字段的长度限制，防止 DoS”。
• 可生成 ：前端 UI 可以基于这个 schema 生成配置表单，后端也可以用它自动生成 OpenAPI 文档和 SDK。它是一个事实的单一来源（Single Source of Truth）。

提示：不要试图在 YAML 里写复杂逻辑。复杂的业务规则（比如“如果客户来自金融行业且预算 > $100K，则邮件模板用 A，否则用 B”）应该放在你自己的业务服务里，通过 execute("get_email_template", {...}) 这样的工具调用来获取。YAML 只管“能做什么”，不管“怎么做”。

3.2 Session 生命周期管理：从 start_session 到 awake

Managed Agents 的 session API 极其简洁，只有三个核心 endpoint：

1. POST /v1/agents/{agent_id}/sessions —— 创建新 session，返回 session_id 和初始 state （通常是空）。
2. POST /v1/sessions/{session_id}/messages —— 向 session 发送用户消息，触发 agent 执行。这是最常用的接口。
3. POST /v1/sessions/{session_id}/awake —— 当 harness 因为资源回收而退出后，用此接口唤醒 session，它会自动加载最新的 event log 并恢复执行。

实操中，最关键的不是调用哪个 API，而是如何设计你的客户端状态管理。我们团队踩过的一个坑是：在 Web 应用里，把 session_id 存在前端 localStorage 里。这看似方便，但带来了两个严重问题：

• 安全性 ： session_id 是一个长期有效的凭证，如果被 XSS 攻击窃取，攻击者就能冒充用户操作 agent。正确做法是： session_id 只存在于后端服务的 session store（如 Redis）里，前端只持有一个短期的、绑定用户身份的 client_token ，由后端服务在每次请求时转换为真实的 session_id 。
• 一致性 ：多个浏览器标签页同时操作同一个 session，会导致 event log 冲突。因为每个标签页都可能独立调用 /messages ，而 Anthropic 的 event log 是严格按时间戳追加的，后发的请求如果时间戳略早，其事件可能会被插入到前面，破坏因果顺序。解决方案是引入一个轻量级的乐观锁：在每次 /messages 请求头里带上一个 expected_event_count ，服务端检查当前 session 的 event 数量是否匹配，不匹配则返回 409 Conflict，前端重试。

注意： awake 接口不是“热备高可用”的银弹。它解决的是 harness 进程级别的故障，不是数据中心级别的灾备。如果你的应用要求 RPO=0（零数据丢失），你仍然需要在自己的业务层实现双写或异步备份 event log 到自有存储。

3.3 生产部署：与现有架构的无缝缝合

Managed Agents 不是让你推倒重来，而是让你把已有的服务“插”进去。我们上线的第一个生产 agent，是对接公司内部的 Jira 和 Confluence。整个过程只花了三天，关键步骤如下：

Step 1: 工具封装（Day 1）
我们没有让 Anthropic 直接调用 Jira REST API，而是写了一个轻量级的 Go 服务 jira-bridge ，它只暴露两个 endpoint：

• POST /search-issues ：接收 {"jql": "project = ENG AND status = 'In Progress'"} ，返回 issue 列表。
• POST /create-comment ：接收 {"issue_key": "ENG-123", "body": "..."} ，在 issue 下添加评论。

这个服务负责所有认证（Jira OAuth2）、错误重试、速率限制、日志埋点。它把 Jira 的复杂性，封装成两个干净的、幂等的、带明确 schema 的 HTTP 接口。

Step 2: YAML 配置（Day 2）
在 agent.yaml 里定义这两个工具：

tools:
  - name: "jira_search_issues"
    description: "Search Jira issues using JQL"
    input_schema:
      type: "object"
      properties:
        jql: { type: "string" }

  - name: "jira_create_comment"
    description: "Add a comment to a Jira issue"
    input_schema:
      type: "object"
      properties:
        issue_key: { type: "string" }
        body: { type: "string" }

Step 3: 安全集成（Day 3）
将 jira-bridge 部署在公司内网，只允许 Anthropic 的沙箱出口 IP 访问。在 Anthropic 控制台里，为 jira_search_issues 工具配置一个专用的、最小权限的 API Key，并设置该 Key 只能调用 jira-bridge 的 /search-issues 接口。整个过程，我们没有修改一行 Anthropic 的代码，也没有暴露任何内部系统凭证给 agent 本身。

这个模式，完美体现了 Managed Agents 的设计哲学：它不强迫你改变技术栈，而是提供一个标准化的“插座”，让你把已有的、经过验证的、符合安全规范的服务，“插”进来即可。你的 Jira 服务、Confluence 服务、CRM 服务，都可以用同样的方式接入。这大大降低了 adoption 的摩擦成本。

4. 常见问题与排查技巧实录：那些文档里不会写的坑

4.1 “P50 time-to-first-token down 60%” 的真相与陷阱

媒体稿里吹的“p50 TTFT 下降 60%”，听起来很震撼。但实测下来，这个数字有严格的前置条件：它指的是 从 POST /messages 请求发出，到收到第一个 token 的延迟 ，并且前提是 agent 的 system prompt 很短，且第一次调用不触发任何工具 。一旦你的 agent 需要先调用 hubspot_search_contacts 获取客户信息，再生成回复，那么真正的端到端延迟（从用户点击发送，到看到最终回复）并不会下降 60%，可能只降了 15%-20%。

为什么？因为 TTFT 只衡量了模型推理的第一小段，而 agent 的总延迟 = TTFT + (Tool Call Latency × Number of Tools) + (Model Inference Time for Final Response) 。Managed Agents 优化的是 TTFT 和 Model Inference Time ，但 Tool Call Latency 完全取决于你自己的后端服务。我们曾遇到一个 case：agent 调用一个内部搜索服务，该服务平均响应 800ms，但偶尔会因 GC 卡顿到 3s。这 3s 的毛刺，会直接拖垮整个 session 的用户体验，而 Anthropic 的指标对此毫无感知。

排查技巧 ：

• 在你的工具服务里，强制加入 X-Request-ID 和详细的 trace_id 日志，确保能关联到 Anthropic 的 event log。
• 对所有工具调用，设置严格的 timeout（建议 1.5s），并在超时后返回一个友好的、带 fallback 信息的 error message，而不是让 agent 无限等待。
• 使用 Anthropic 的 event log 中的 tool_call 事件的 duration_ms 字段，定期统计 P95/P99 延迟，绘制趋势图。这才是影响你用户的真实指标。

4.2 “Sandboxed execution” 不等于“绝对安全”

沙箱能防住大部分问题，但不是万能的。我们遇到过一个非常隐蔽的漏洞：agent 的 system prompt 里有一段示例，展示如何用 Python 代码解析 JSON。示例代码里，它用了 json.loads(response_text) 。问题在于， response_text 是从一个不受信的第三方 API 返回的，里面嵌入了恶意的 Unicode 字符（ \u202e ，右向左覆盖字符）。当这段代码在沙箱里执行时， json.loads 会正常解析，但后续的字符串拼接操作，因为 RTL 字符的存在，导致生成的最终 HTML 输出被浏览器渲染成完全不同的内容（比如把“Approved”显示成“Denied”）。沙箱完美运行了所有代码，但业务逻辑被无声地扭曲了。

避坑心得 ：

• 永远不要信任任何外部 API 的原始响应。在你的工具服务里，对所有返回的字符串进行严格的 Unicode 规范化（ NFC ）和控制字符过滤（ U+0000 到 U+001F ， U+202A 到 U+202E ）。
• 对于所有会生成 HTML/CSS/JS 的 agent 输出，必须在你的前端或后端服务里，进行二次的、基于白名单的 HTML sanitizer（如 DOMPurify），不能依赖 agent 自己的“不生成恶意代码”的承诺。
• 沙箱保护的是你的基础设施，不是你的业务逻辑。安全的重心，必须从“防 agent 做坏事”，转移到“防 agent 的输出被坏人利用”。

4.3 “Credential vault” 的权限爆炸风险

Anthropic 的密钥管理很强大，但它的权限模型是“工具粒度”的，不是“数据粒度”的。比如，你为 jira_search_issues 工具配置了一个 Jira API Key，这个 Key 在 Jira 里拥有 Browse Projects 权限。那么，agent 就能搜索你公司所有的 Jira 项目，包括那些标记为 Confidential 的 HR 项目。这违反了最小权限原则。

实操方案 ：

• 我们在 jira-bridge 服务里，增加了一层 RBAC（基于角色的访问控制）。当 agent 调用 /search-issues 时， jira-bridge 会根据发起请求的 session_id 关联的用户身份（从我们的 Auth 服务获取），动态构造 JQL 查询，自动加上 AND project IN ('ENG', 'MKT') 这样的项目白名单过滤。
• 这意味着，Anthropic 的凭证只拥有一个“通用”的、低权限的 Jira 用户身份，而真正的数据访问控制，由我们自己的业务服务完成。这是一种“纵深防御”：沙箱隔离了网络和凭证， jira-bridge 隔离了数据范围。

4.4 事件日志的“可回放性”陷阱

session-as-event-log 的最大优势是可回放，但这里有个巨大的认知陷阱： 回放一个 event log，不等于复现当时的业务状态 。Event log 记录的是“agent 做了什么”，但不记录“外部世界发生了什么”。

举个例子：agent 在 t=0s 调用 stock_price("AAPL") ，得到 $192.34 ；在 t=60s 调用 place_order("AAPL", 100) ，下单成功。这个 event log 完美记录了全过程。但如果你在 t=120s 回放这个 log， stock_price("AAPL") 返回的可能是 $195.88 ，而 place_order 可能因为价格变动而失败。回放成功，不代表业务逻辑成功。

经验总结 ：

• Event log 的核心价值是 debugging 和 auditing ，不是 replaying for production effect 。把它当作一个强大的“黑匣子”，用于事后分析，而不是一个“时光机”，用于重演业务。
• 如果你真的需要确定性的回放（比如做 A/B 测试），你必须在自己的工具服务里，实现“mock mode”。当检测到请求头里有 X-Replay-Mode: true 时， jira-bridge 就不调真实 Jira，而是从一个预录制的 fixture 文件里返回固定数据。这个 fixture 文件，就是你 event log 的“配套资产”。

5. 竞争格局与价值迁移：为什么 runtime 层注定走向“零价”

5.1 不是 Anthropic 在开创，而是在追赶与固守

把 Anthropic 的 Managed Agents 放在更大的图景里看，它远非一个“开创性”产品。AWS Bedrock AgentCore 在 2025 年底就已 GA，到 2026 年 3 月，SDK 下载量已超两百万次。Google Vertex AI Agent Builder、Microsoft Azure AI Foundry 也都已发布各自的托管 runtime。这说明， agent runtime 作为一个基础设施层，已经被三大云厂商共同确认为“必需品” ，并已进入大规模普及阶段。

Anthropic 的发布，本质上是一场防御战。它的核心商业逻辑，不是“我要卖 runtime”，而是“我不能让我的客户（那些为 Claude 付费的用户）把 agent 运行在 AWS 或 GCP 上”。因为一旦 agent 运行在 AWS 上，客户就很容易在同一个 AgentCore runtime 里，混用 Claude、Llama、Gemini 等多种模型，Anthropic 的模型锁定效应就会被削弱。更可怕的是，AWS 的 pricing 是“免费赠送”——AgentCore 的 session-hour 是按你整体的 Bedrock 账单折扣计算的，对于大客户，几乎是零成本。Anthropic 的 $0.08，无论怎么优化，都很难在价格上赢过“免费”。

提示：不要被“Anthropic 发布了新东西”的新闻标题带偏。真正值得关注的，是 AWS、GCP、Azure 这三家，如何把 agent runtime 变成他们云服务的“空气和水”——你买他们的计算、存储、网络，runtime 就是附赠的。这才是 runtime 层 commoditization 的终极形态。

5.2 价值正在向上迁移：Trace Store、Policy Engine、Vertical Marketplace

当 runtime 层的价格被压向零，价值必然向上迁移。目前，有三个方向已经清晰浮现：

1. Trace Store（追踪存储）
谁拥有最完整、最标准、最易迁移的 agent 事件日志？Braintrust 的 Brainstore、Arize 的 Phoenix、LangChain 的 LangSmith，都在争夺这个“系统记录”的位置。它们的价值不在于“展示日志”，而在于“成为事实的权威来源”。当你的 agent 从 Anthropic 迁移到 AWS，或者从 AWS 迁移到自建 Kubernetes，你的 event log 能否一键导入、无缝查询、保持 schema 兼容？谁能解决这个问题，谁就卡住了 runtime 层的咽喉。

2. Policy Engine（策略引擎）
OWASP Agentic Top 10 的发布，标志着 agentic 安全已从“最佳实践”升级为“合规要求”。企业采购部门现在会问：“这个 agent 被允许调用哪些外部 API？它的输出是否经过 PII 扫描？它的所有操作是否有不可篡改的审计证明？” AWS 的 AgentCore Policy Controls 已 GA，但这只是起点。一个成熟的 policy engine，需要能定义跨工具、跨 session、跨用户的复杂策略，比如：“Sales agent 可以调用 HubSpot，但不能调用 Stripe；Finance agent 可以调用 Stripe，但所有支付金额必须小于 $10,000，且需二级审批”。这个领域，目前还是蓝海。

3. Vertical Marketplace（垂直市场）
Salesforce 的 Agentforce ARR 达到 8 亿美元，证明了企业愿意为“能解决具体业务问题的 agent”付费，而不是为“能跑 agent 的 runtime”付费。未来的赢家，将是那些深耕某个垂直领域的 agent 供应商：医疗领域的病历摘要 agent、法律领域的合同审查 agent、金融领域的风控 agent。它们的成功，不依赖于 runtime 多快，而依赖于对垂直领域知识、流程、合规要求的深刻理解。开源社区已经在行动： ai-hedge-fund 项目提供了量化交易的完整 agent 框架， pentagi 项目则专注于渗透测试的自动化 agent。资本正疯狂涌入这些“floor above”。

5.3 自我进化 agent：从工程问题到监管问题

最后，一个正在加速逼近的 force function： self-improving agents（自我进化 agent） 。Sakana AI 的 Darwin Gödel Machine 论文，展示了 agent 如何通过阅读自身代码、运行单元测试、分析失败原因，然后自动重写代码，将 SWE-bench 分数从 20% 提升到 50%。这个过程，是完全自主的、无需人类干预的。

当 agent 能修改自己的代码时，runtime 层的意义就彻底变了。它不再只是一个“执行环境”，而是一个“监管沙箱”。你必须能 100% 确保：

• 它的代码修改，只发生在受控的、可审计的沙箱内；
• 每一次修改，都必须被完整记录在 event log 中，包括修改前后的 diff、触发修改的测试用例、修改后的测试结果；
• 它的修改，不能突破预先设定的 policy boundary（比如，不能给自己增加新的工具调用权限）。

这已经超出了传统 DevOps 的范畴，进入了 RegTech（监管科技）的领域。未来的 agent runtime，其核心竞争力，将不是“多快”，而是“多可信”；其核心产品，将不是“API”，而是“审计报告”和“合规证明”。Anthropic 今天发布的，是一个优秀的 runtime；但明天真正值钱的，是能为这个 runtime 生成具有法律效力的审计证据的系统。

我个人在实际操作中发现，与其花大力气去优化 runtime 的性能，不如把精力投入到构建一个坚不可摧的 trace store 和 policy engine 上。因为前者终将免费，后者才是你未来十年的护城河。