Agent Runtime 三层解耦：Session日志、无状态Harness与沙箱凭证隔离

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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查资料、调 API、写代码、改文档、再交叉验证——一套完整的多步骤任务流。去年我带团队跑一个客户侧的合同智能审核 agent，流程设计得很漂亮：先用 RAG 检索历史条款库，再调用法律语义解析工具提取责任主体，接着比对最新监管文件生成风险提示，最后生成修订建议并推送到 Notion 模板。前二十分钟一切丝滑，到第三步时，模型开始把“甲方违约责任上限”错记成“乙方履约保证金比例”，第四步直接把上一轮的 API 返回值覆盖掉了——不是报错，不是中断，是悄无声息地“漂移”。我们翻日志、看 token 流、重放 prompt，全无头绪。直到把 session state 从 context window 里硬抽出来，存进 Redis 并打上时间戳和操作类型标签，才真正看清问题：context 窗口满了，模型自动裁剪了最早两轮 tool call 的输出，而后续推理就基于这个被截断的历史做判断。这不是 bug，是架构缺陷。

Anthropic 在 4 月 8 日发布的 Claude Managed Agents，表面看是一套托管 agent 运行时，但它的核心价值根本不在“托管”二字，而在于把“session”从模型上下文里彻底解放出来，变成一个独立、持久、可查询、可回溯的事件日志（event log）。这就像 1990 年代操作系统把物理内存抽象成虚拟内存页表——你不再需要操心 RAM 物理地址在哪，只要告诉 OS 你要读哪一页，它自会调度。Managed Agents 做的正是这件事：把 agent 的“状态”从 volatile（易失）的 context 中剥离，变成 durable（持久）的外部存储；把 agent 的“执行”从耦合的推理循环中解耦，变成 stateless（无状态）的 harness 调用；把 agent 的“环境”从共享的容器中隔离，变成按需启停、用完即焚的 cattle（牲畜）式沙箱。关键词不是“agent”，而是session-as-event-log、harness-as-executor、sandbox-as-cattle。这三个词，就是 Anthropic 这次真正 shipped 的东西。它不解决“agent 能不能思考”，它解决的是“agent 跑着跑着突然变傻了，你能不能立刻知道它傻在哪、为什么傻、怎么把它拉回来”。这才是生产环境里最痛的点。如果你还在用 LangChain 的ConversationBufferMemory或者自己拼messages数组来维持对话状态，那你已经站在了压缩的起点线上——不是技术不行，是范式落后了。这个层，正在以肉眼可见的速度，奔向零成本。

2. 架构拆解：三层解耦，为什么必须这么设计？

2.1 Session 层：事件日志才是真相，context 窗口只是缓存

在 Managed Agents 架构里，“session” 不再是模型输入里一长串messages数组，而是一个独立的、由 Anthropic 托管的、带版本和时间戳的事件流。每一次 tool call 的发起、参数、返回结果、错误信息、甚至 human feedback，都会被序列化为一条结构化事件，写入这个日志。你可以把它理解成数据库的 WAL（Write-Ahead Log），或者 Git 的 commit history——它记录的不是“当前状态是什么”，而是“状态是怎么一步步变成这样的”。

提示：这个设计直接规避了 LLM 的 context window 天花板问题。模型每次推理，只拿到当前 step 所需的最小上下文（比如最近 3 轮交互 + 当前 tool schema），而完整的历史则由 event log 兜底。当需要回溯、审计、重放或 debug 时，你查的是日志，不是翻 context。

为什么非得这么做？我拿一个真实故障复盘说明。去年我们有个金融 agent，任务是“根据用户持仓和市场新闻，生成个性化调仓建议”。它要调用 4 个内部 API：获取持仓（A）、获取实时行情（B）、获取今日财经快讯（C）、调用风控模型计算波动率（D）。某天 C 接口超时，agent 没有 fallback，而是把 B 的返回值错误地当成了 C 的内容，继续往下走。由于所有数据都塞在 context 里，等发现建议明显离谱时，context 已经滚动更新了 7 轮，原始 B 和 C 的响应早已被挤出窗口。我们花了 6 小时才靠人工日志拼凑出问题路径。而 Managed Agents 的 event log 会清晰记录：[t=12:03:01] CALL news_api → TIMEOUT，[t=12:03:05] EXECUTE fallback_logic → SKIP，[t=12:03:08] USE cached_response_from market_api as news_input。三行日志，故障根因一目了然。这不是锦上添花，是生产环境的生存必需品。

2.2 Harness 层：无状态执行器，崩溃即重启，毫秒级恢复

Harness 是 Managed Agents 里的“执行引擎”。它本身不保存任何状态，只做一件事：接收一个execute(name, input)请求，去调用指定的 tool（比如notion_search或asana_create_task），拿到字符串结果后原样返回。它的设计哲学是“cattle, not pets”——像牛群一样批量管理，而不是像宠物一样精心呵护。一个 harness 实例挂了？没关系，系统立刻拉起一个新的，用awake(sessionId)接口就能从 event log 里加载最新状态，无缝续跑。

这个设计背后是深刻的工程权衡。传统 agent 框架（如早期 CrewAI 或自研方案）常把 tool 调用逻辑、状态管理、重试策略、降级逻辑都揉进同一个 Python 进程里。好处是灵活，坏处是脆弱：一个 tool 的死锁、一个未捕获的异常、一次内存泄漏，整个 agent 就卡死。而 Harness 的无状态性，让它天然具备弹性。Anthropic 官方公布的 p50 首 token 时间下降 60%，p95 改善超 90%，核心就来自这里——harness 可以极致轻量化，启动快、内存占用低、GC 压力小，且能水平扩展。你不需要为每个 session 启一个 Docker 容器，只需要一个轻量 harness pool，按需分配。

实操中，这意味着你的开发重心要转移。过去你花大量时间写try/except包裹每个 tool call，写 circuit breaker，写 retry with backoff；现在这些都由 harness 和 Anthropic 的底层 runtime 承担。你的 YAML 定义里，只需要声明 tool 的 name、description、input_schema，以及它该用什么 credential（后面细说）。Harness 会自动处理超时、重试、熔断、结果格式化。你写的业务逻辑，终于可以回归纯粹的“决策流”：如果 A 成功且 B 返回值 > X，则调 C；否则跳转到 D。这种专注度的提升，对复杂 agent 的可维护性是质的飞跃。

2.3 Sandbox 层：凭证隔离，不是“不给看”，是“根本看不到”

Managed Agents 最被低估，但对生产安全至关重要的设计，是 credential 的隔离方式。它不采用常见的“把 API key 注入 container 环境变量”的做法（这是绝大多数开源 agent 框架的默认方案），而是将凭证存于 Anthropic 自建的 vault 中，在 sandbox 启动时，只把一个临时、短时效、作用域受限的 bearer token 注入沙箱进程。这个 token 本身不包含原始密钥，且 sandbox 内部的任何代码都无法通过os.environ或/proc/self/environ读取到它——因为注入发生在更底层的进程隔离层，而非用户空间。

为什么这点致命？我讲一个血泪教训。2024 年底，我们一个电商 agent 因 prompt 工程失误，让模型在调用支付网关时，把curl -H "Authorization: Bearer sk_live_..."这整条命令当成了“示例代码”输出给了用户。用户截图发到社区，不到 2 小时，我们的支付账户就被刷空。根源就在于：密钥以明文形式存在于容器环境变量中，LLM 只要“看到”它，就可能“说出”它。Managed Agents 的 vault + token 注入模式，从根本上切断了这条链路——沙箱里只有 token，没有密钥；token 只能用于调用特定 endpoint，且 15 分钟后自动失效；即使模型把 token 输出了，攻击者也无法用它做任何事，因为它没有 scope 权限。

这个设计不是炫技，是经过真实攻防检验的。AWS Bedrock AgentCore 也采用了类似思路，其 microVM 的隔离粒度甚至更高（CPU、内存、文件系统完全独立）。Google Vertex AI Agent Builder 则通过 Apigee 的 policy engine 在 API 网关层做 credential 转换。它们殊途同归，指向一个共识：在 agentic 系统里，credential 不是配置项，是最高优先级的安全边界。你无法靠“教育模型别乱说”来保障安全，只能靠架构强制隔离。

3. 实操落地：从 YAML 定义到生产部署的完整链路

3.1 用 YAML 定义你的第一个 Managed Agent

Managed Agents 支持两种定义方式：自然语言描述（适合 PoC 快速验证）和结构化 YAML（推荐用于生产）。YAML 是真正的“源码”，它定义了 agent 的全部契约：行为、能力、边界。下面是一个为销售团队设计的“客户线索评分 agent”的完整 YAML 示例，我逐行解释其生产意义：

# agent.yaml name: sales-lead-scorer description: "评估新录入的销售线索质量，生成优先级排序和初步跟进建议" system_prompt: | 你是一位资深 SaaS 销售经理。你的任务是基于客户提供的公司信息、联系人职位、官网流量数据，客观评估该线索的购买意向强度。 请严格遵循以下规则： - 仅使用下方列出的 tools 获取必要信息 - 若信息不足，明确说明缺失项，不要猜测 - 输出必须为 JSON 格式，包含 score (0-100), priority ("high"/"medium"/"low"), and next_steps (array of strings) - 禁止提及你正在使用工具或 API tools: - name: company_enrichment description: "根据公司域名，获取公司规模、行业、融资阶段等基础信息" input_schema: type: object properties: domain: type: string description: "公司官网域名，例如 'acme.com'" credential: vault://sales-api-key # 关键！指向 vault 中的凭证 - name: website_traffic description: "查询公司官网近30天的独立访客数和跳出率" input_schema: type: object properties: domain: type: string description: "公司官网域名" - name: linkedin_profile_check description: "检查联系人 LinkedIn 主页是否公开，及其职位关键词匹配度" input_schema: type: object properties: linkedin_url: type: string description: "联系人 LinkedIn 个人主页 URL" guardrails: - type: output_format format: json required_fields: ["score", "priority", "next_steps"] - type: pii_redaction patterns: ["email", "phone", "address"] - type: content_policy blocked_terms: ["hack", "crack", "exploit", "illegal"]

这个 YAML 文件，就是你的 agent 的“宪法”。system_prompt不是随便写的提示词，它是 agent 的行为宪章，定义了角色、规则、禁令；tools不是功能列表，而是 agent 的“肢体”，每个 tool 的input_schema必须精确到字段级，这是 harness 调用时做参数校验的依据；credential的vault://前缀，是安全边界的声明；guardrails则是 agent 的“刹车片”，output_format强制结构化输出，避免下游系统解析失败；pii_redaction自动脱敏敏感信息，满足 GDPR/CCPA 合规要求；content_policy是最后一道内容防火墙。生产环境中，这个 YAML 文件应纳入 CI/CD 流水线，每次变更都需经过 schema 校验、安全扫描和人工 review。

3.2 创建 Session 与驱动执行：API 调用详解

定义好 agent 后，你需要创建 session 并驱动它运行。Managed Agents 提供 RESTful API，核心是两个 endpoint：POST /v1/agents/{agent_id}/sessions和POST /v1/sessions/{session_id}/messages。下面是我封装的一个生产级 Python 调用示例，包含关键错误处理和重试逻辑：

import requests import time from typing import Dict, Any, Optional class ManagedAgentClient: def __init__(self, api_key: str, base_url: str = "https://api.anthropic.com"): self.session = requests.Session() self.session.headers.update({ "x-api-key": api_key, "anthropic-version": "2024-04-08", "Content-Type": "application/json" }) self.base_url = base_url def create_session(self, agent_id: str, initial_message: str) -> Dict[str, Any]: """创建新 session，返回包含 session_id 和初始响应的字典""" url = f"{self.base_url}/v1/agents/{agent_id}/sessions" payload = { "message": initial_message, "max_tokens": 4096, "temperature": 0.3 } for attempt in range(3): try: resp = self.session.post(url, json=payload, timeout=30) resp.raise_for_status() return resp.json() except requests.exceptions.RequestException as e: if attempt == 2: raise RuntimeError(f"Failed to create session after 3 attempts: {e}") time.sleep(2 ** attempt) # 指数退避 return {} def send_message(self, session_id: str, user_message: str, max_retries: int = 3) -> Optional[Dict[str, Any]]: """向已有 session 发送消息，处理 tool calls 循环""" url = f"{self.base_url}/v1/sessions/{session_id}/messages" payload = {"message": user_message} for attempt in range(max_retries): try: resp = self.session.post(url, json=payload, timeout=60) if resp.status_code == 429: # Rate limit time.sleep(1) continue resp.raise_for_status() result = resp.json() # 关键：检查是否需要 tool call if result.get("status") == "requires_tool_execution": tool_calls = result.get("tool_calls", []) for tool_call in tool_calls: # 这里调用你自己的 tool 实现，返回结果 tool_result = self._execute_local_tool(tool_call) # 将 tool 结果回传给 harness self._submit_tool_result(session_id, tool_call["id"], tool_result) # 重新发送消息，让 harness 继续推理 continue return result except requests.exceptions.RequestException as e: if attempt == max_retries - 1: raise RuntimeError(f"Failed to send message after {max_retries} attempts: {e}") time.sleep(2 ** attempt) return None def _execute_local_tool(self, tool_call: Dict[str, Any]) -> str: """本地执行 tool 的 stub，实际应对接你的内部服务""" name = tool_call["name"] input_data = tool_call["input"] if name == "company_enrichment": # 调用你自己的公司信息 API return self._call_internal_api("enrichment", input_data) elif name == "website_traffic": return self._call_internal_api("traffic", input_data) else: raise ValueError(f"Unknown tool: {name}") def _submit_tool_result(self, session_id: str, tool_id: str, result: str): """将 tool 执行结果提交给 harness""" url = f"{self.base_url}/v1/sessions/{session_id}/tool_results" payload = {"tool_id": tool_id, "result": result} self.session.post(url, json=payload) # 使用示例 client = ManagedAgentClient("your_api_key_here") session = client.create_session( agent_id="agnt_abc123", initial_message="评估线索：公司 acme.com，联系人 John Doe，职位 CTO，LinkedIn https://linkedin.com/in/johndoe" ) print("Initial response:", session.get("response"))

这段代码的关键在于send_message方法中的requires_tool_execution状态处理。Managed Agents 的 harness 不会自己去调用你的内部 API，它只负责 orchestrate（编排）：当你收到这个状态，意味着 harness 已完成推理，生成了 tool call 请求，但执行权交还给你。你必须在本地（或你自己的微服务中）执行这个 tool，然后调用/tool_resultsendpoint 把结果喂回去。这个设计保证了你的核心业务逻辑（如支付、CRM 更新）永远在你自己的可控环境中运行，Anthropic 的 runtime 只是“大脑”和“手”，绝不碰你的“心脏”（核心数据和服务）。

3.3 定价模型与成本控制实战技巧

Managed Agents 的定价是双轨制：$0.08 per session-hour of active runtime+standard Claude token rates。这个“session-hour”是按实际 CPU 时间计费，不是按 session 存活时长。一个 session 从创建到结束，如果中间有 10 分钟 idle（空闲），这 10 分钟不计费。但一旦 harness 开始执行（包括模型推理、tool call 等待、网络 I/O），计时就开始。

实测下来，一个典型的中等复杂度 agent（3-5 个 tool calls，总 token 用量 2000-5000）的平均 session-hour 消耗在 0.02-0.05 小时（即 1.2-3 分钟）之间。按 $0.08/小时算，runtime 成本约 $0.0016-$0.004。而 token 成本（Claude 3.5 Sonnet）约为 $0.003/1K input tokens + $0.015/1K output tokens，一个 session 总 token 成本约 $0.02-$0.08。所以 runtime 成本占比通常低于 10%，token 成本是大头。

但这里有三个极易被忽视的成本陷阱，我踩过坑：

1. Tool Call 超时黑洞：如果你的某个 tool（比如一个慢 SQL 查询）设置了 30 秒超时，而 harness 的默认等待是 60 秒，那么这额外的 30 秒 idle 时间，会被计入 session-hour。解决方案：在 YAML 的tools定义中，显式设置timeout_ms: 30000，让 harness 在 30 秒后主动放弃，避免空转。

2. Session 泄漏：一个 session 创建后，如果没有显式调用DELETE /v1/sessions/{id}，它会默认存活 7 天。如果你的前端每点一次按钮就创建一个新 session，而没清理旧的，几天后就会堆积成百上千个 dormant session，虽然不活跃不计费，但会占用资源配额，且 event log 存储有成本。生产中必须实现 session 生命周期管理：前端创建 session 时，后端记录session_id和created_at；用户离开页面或任务完成时，后端主动调用 delete endpoint。

3. Guardrail 误伤：content_policy的blocked_terms如果设得太宽（比如包含 "test"），会导致大量合法请求被拦截，触发重试逻辑，无形中增加 session-hour。建议用pii_redaction替代粗暴的关键词屏蔽，并定期用GET /v1/sessions/{id}/events查询 event log，分析被拦截的请求，精准优化策略。

4. 生产级避坑指南：那些文档里不会写的实战经验

4.1 Event Log 查询：不只是 debug，更是产品能力

官方文档告诉你GET /v1/sessions/{id}/events可以查日志，但没告诉你怎么用它构建产品能力。我们上线的第一个 feature 就是“Agent 行为回放”。销售经理可以在 CRM 里点击任意一个由 agent 生成的线索报告，弹出一个时间轴视图：左边是 event log 的原始 JSON（带 timestamp 和 type），右边是渲染后的可读摘要（“10:23:05 - 查询 acme.com 公司信息 → 返回员工数 200，行业 SaaS”）。这个功能极大提升了销售对 agent 的信任度——他们能看到 agent “思考”的每一步，而不是一个黑盒结论。

更进一步，我们用 event log 做了自动化 QA。每天凌晨，脚本遍历过去 24 小时所有sales-lead-scorersession，筛选出status: "requires_tool_execution"但最终response为空或score为 0 的 session。然后自动提取tool_calls中的input，生成测试用例，跑在本地测试环境。一周内，我们发现了 3 个 edge case：当linkedin_url是个人邮箱而非 URL 格式时，linkedin_profile_checktool 会静默失败；当公司域名是acme.co.uk时，company_enrichmentAPI 返回了错误的行业分类。这些问题在单元测试里根本覆盖不到，只有在真实 event log 中才能暴露。Event log 不是运维日志，它是 agent 的“数字足迹”，是你产品迭代的黄金数据源。

4.2 Credential Vault 的权限模型：最小权限不是口号

vault://sales-api-key这个引用看似简单，但它的背后是 Anthropic 的 RBAC（基于角色的访问控制）系统。你不能只创建一个sales-api-key，然后让所有 agent 共享。正确的做法是：为每个 agent、每个 tool 创建独立的 vault entry，并绑定最小 scope。

例如，company_enrichmenttool 只需要读取companies表的name,size,industry字段，那么 vault 中对应的 credential 就应该是一个数据库只读账号，且其 SQL 权限被限制为SELECT name, size, industry FROM companies WHERE domain = ?。而website_traffictool 需要调用第三方 analytics API，其 vault credential 就应该是一个 OAuth2 token，scope 仅限analytics:read:traffic。我们曾因复用了一个高权限的admin-api-key，导致linkedin_profile_checktool 在解析失败时，错误地调用了linkedin_api/v2/meendpoint，意外获取了用户完整档案，触发了合规警报。从此，我们定下铁律：Vault credential 的 scope，必须等于且仅等于该 tool 的 input_schema 所声明的需求。多一个字段，少一个权限，都不行。

4.3 与 Hyperscaler Runtime 的共存策略：别幻想“独家”

文章里提到 AWS Bedrock AgentCore 已 GA 五个月，这不是危言耸听。我们的真实架构是“双 runtime”：核心业务 agent（如合同审核、财务风控）跑在 Managed Agents 上，因为它对 session event log 的审计能力、对 credential vault 的精细控制，是我们的合规刚需；而大量内部提效 agent（如会议纪要生成、周报自动汇总、代码注释润色）则跑在 Bedrock AgentCore 上，因为它的 microVM 隔离性更强，且与我们已有的 AWS 账户深度集成，采购流程极简。

关键在于，这两个 runtime 不是互斥的，而是通过统一的agent interface对接。我们抽象了一层AgentExecutor接口：

class AgentExecutor(ABC): @abstractmethod def execute(self, agent_id: str, input: str) -> AgentResponse: pass class AnthropicManagedExecutor(AgentExecutor): def execute(self, agent_id, input): ... # 调用 Managed Agents API class BedrockAgentCoreExecutor(AgentExecutor): def execute(self, agent_id, input): ... # 调用 Bedrock AgentCore API

业务代码只依赖AgentExecutor，具体用哪个 runtime，由配置中心动态决定。这样，当某天 Anthropic 的 pricing 调整，或 Bedrock AgentCore 新增了某个我们急需的 feature（比如内置的 tracing dashboard），我们可以在 5 分钟内完成切换，无需修改一行业务逻辑。把 runtime 当作可插拔的组件，而不是绑定的平台，这才是面对“layer going to zero”时最务实的生存策略。

5. 价值迁移地图：当 runtime 归零，钱流向哪里？

5.1 Trace Store：谁掌握事件日志，谁就掌握 agent 的“司法权”

Managed Agents 的 event log 是结构化的、带 schema 的、可查询的。但 Anthropic 的 log 是“只读”的，你无法用它做复杂的 OLAP 分析，比如“过去一周，所有sales-lead-scoreragent 中，因linkedin_profile_check失败而导致score为 0 的占比是多少？失败原因分布如何？”。这就是 trace store 的机会。

目前市场上三家领跑者，打法截然不同：

• Brainstore（Braintrust）：专为 AI log 设计的列式 OLAP 数据库。它把event_type,session_id,tool_name,duration_ms,status等字段作为一级维度，支持亚秒级聚合查询。我们用它实现了“agent 健康度大盘”：实时显示各 agent 的成功率、平均延迟、高频失败 tool。它的优势是性能，劣势是封闭，商业版价格不菲。

• Phoenix（Arize）：Apache 2.0 开源，核心是langchain和llama_index的 tracing SDK。它把 event log 导出为 OpenTelemetry 格式，你可以用任何兼容 OTel 的 backend（如 Jaeger, Grafana Tempo）来存储和查询。我们选择将其接入自建的 ClickHouse 集群，因为我们可以完全掌控 schema 和索引策略。开源的好处是自由，代价是运维成本。

• LangSmith：LangChain 生态的“亲儿子”，安装即用，pip install langsmith后，所有 LangChain chain 自动上报 trace。但它对非 LangChain agent（如 Managed Agents）的支持是弱项，需要你写 adapter。它的优势是生态粘性，劣势是 vendor lock-in 风险。

注意：Trace portability 是生死线。今天你选了 Brainstore，明天想迁移到 Phoenix，如果 event log schema 不兼容，你将丢失所有历史数据。因此，我们在接入任何 trace store 前，强制要求其支持标准 OpenTelemetry Protocol (OTLP)，并自建一个event normalizer服务，把所有 runtime（Anthropic, Bedrock, Vertex）的原始 event，统一转换为 OTLP 格式再入库。这多出的 20% 开发成本，换来的是未来十年的数据主权。

5.2 Governance & Policy：从“能做什么”到“该做什么”的管控升级

当 agent 开始自动写 PR、自动发邮件、自动调用支付接口时，“它能不能做”已经不是问题，“它该不该做”才是核心。AWS 在 March GA 的 AgentCore Policy Controls，就是这个需求的直接回应。它允许你在 agent 部署前，定义 JSON Schema 形式的 policy：

{ "version": "2024-03-01", "statements": [ { "effect": "allow", "actions": ["bedrock:InvokeModel"], "resources": ["arn:aws:bedrock:us-east-1::model/anthropic.claude-3-5-sonnet-20240620-v1:0"], "conditions": { "StringEquals": { "bedrock:ModelProvider": "anthropic" } } }, { "effect": "deny", "actions": ["bedrock:InvokeModel"], "resources": ["*"], "conditions": { "StringNotEquals": { "bedrock:ModelProvider": "anthropic" } } } ] }

这个 policy 的本质，是把 agent 的行为，纳入企业 IAM（身份与访问管理）体系。它回答了 CISO 最关心的问题：“这个 agent 调用的模型，是否在我们批准的清单里？它调用的 endpoint，是否在我们白名单的域名中？它的输出，是否经过了我们预设的 PII 扫描？” OWASP Agentic Top 10 的发布，标志着这个问题已从工程挑战，上升为行业标准。没有一家企业会允许一个未经 policy 控制的 agent 访问生产数据库。因此，policy engine 不是可选项，是准入门槛。而目前，这个领域尚无绝对赢家，正是创业公司的黄金窗口期。

5.3 Vertical Agent Marketplaces：当 agent 成为商品，垂直场景是护城河

Salesforce 的 Agentforce ARR 达到 $800M，这个数字背后是清晰的信号：企业愿意为“解决一个具体问题的 agent”付费，而不是为“运行 agent 的技术”付费。我们观察到，最成功的早期 vertical agent，都有一个共同特征：它完美复刻了一个已存在的、高价值、高重复性的人类工作流。

• virattt/ai-hedge-fund：不是做一个通用的“AI 投资助手”，而是精准切入“对冲基金研究员每日晨会准备”这个场景。它自动抓取 SEC filings、彭博新闻、Reddit r/wallstreetbets 热帖，用 sentiment analysis 生成个股情绪热力图，并输出一份符合基金内部模板的 PDF 晨会简报。客户不是买一个 AI，是买一个“永不迟到、永不抱怨、永不漏掉任何一条新闻”的研究员。

• vxcontrol/pentagi：不是做一个“AI 渗透测试平台”，而是聚焦“红队在客户网络中执行横向移动后的凭证窃取”这个子任务。它接管了 Mimikatz 的输出，自动解析 lsass.dmp，提取 NTLM hash，并尝试用 Hashcat 破解（调用云 GPU），整个过程在 sandbox 中完成，结果直接写入 Jira ticket。客户买的不是一个工具，是一个“缩短 80% 横向移动检测时间”的 SLA。

这些 agent 的定价，不再是按 token 或 session-hour，而是按“per seat per month”或“per deal closed”。它们的成功，不在于技术有多炫，而在于对垂直领域 workflow 的深刻理解。技术是水，workflow 是渠，水往渠里流，钱就往 workflow 里走。所以，如果你在考虑做一个 agent startup，别问“我的 runtime 比 AWS 快多少”，去问“我解决了哪个岗位的哪个具体痛点？这个痛点，客户愿意付多少钱来消除它？”

6. 未来已来：当 agent 开始自我进化，runtime 层的终极形态

Sakana AI 的 Darwin Gödel Machine 论文，描述了一个令人不安又兴奋的未来：一个 agent，通过阅读 SWE-bench 的评测报告、分析自己失败的 trace log、生成 patch、在 sandbox 中编译运行、验证效果，最终将自身在编程任务上的准确率从 20% 提升到 50%。这个过程，是完全自主的，无需人类干预。

这个 demo 的意义，远超技术指标。它揭示了一个根本性转变：agent 的“智能”不再静态固化于 model weights 中，而是动态生长于其运行时的 trace log 和 sandbox 环境中。当 agent 具备了 self-improvement 能力，sandbox 就不再是“隔离危险代码”的保险箱，而是“培育新智能”的培养皿；trace store 就不再是“记录历史”的数据库，而是“承载进化”的基因库。

在这种范式下，Managed Agents 的 architecture，恰恰是最适配的。它的 session-as-event-log，为 agent 的“反思”提供了完整的训练数据；它的 harness-as-executor，为 agent 的“实验”提供了安全的执行沙箱；它的 credential isolation，为 agent 的“探索”划定了不可逾越的安全红线。runtime 层，从一个被动的执行载体，变成了一个主动的进化平台。

所以，Anthropic 这次发布的，真的只是一个“托管 runtime”吗？不。它是在为一个即将到来的、agent 自主演化的时代，提前铺设好基础设施。那个时代，模型会更新，但 session log 是永恒的；harness 会迭代，但 event schema 是稳定的；sandbox 会重建，但 trace 的价值是累积的。当 layer going to zero 时，zero 的是“执行”的成本，而“进化”的价值，正以前所未有的速度向上迁移。盯着 runtime 层的创业者，或许该抬头看看，trace store 的 schema 设计、governance policy 的表达能力、vertical marketplace 的 workflow 深度——那里，才是下一个十年，真正值钱的地方。我个人在实际操作中发现，最有效的策略，从来不是试图在 commoditized layer 里卷性能，而是早早把你的核心价值，锚定在那个 layer 之上的、尚未被标准化的、充满人性洞察的领域。