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都会被序列化为一条结构化事件写入这个日志。你可以把它理解成数据库的 WALWrite-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 会清晰记录[t12:03:01] CALL news_api → TIMEOUT[t12:03:05] EXECUTE fallback_logic → SKIP[t12: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 AgentManaged 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核心是两个 endpointPOST /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, jsonpayload, timeout30) resp.raise_for_status() return resp.json() except requests.exceptions.RequestException as e: if attempt 2: raise RuntimeError(fFailed 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, jsonpayload, timeout60) 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(fFailed 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(fUnknown 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, jsonpayload) # 使用示例 client ManagedAgentClient(your_api_key_here) session client.create_session( agent_idagnt_abc123, initial_message评估线索公司 acme.com联系人 John Doe职位 CTOLinkedIn 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 runtimestandard Claude token rates。这个“session-hour”是按实际 CPU 时间计费不是按 session 存活时长。一个 session 从创建到结束如果中间有 10 分钟 idle空闲这 10 分钟不计费。但一旦 harness 开始执行包括模型推理、tool call 等待、网络 I/O计时就开始。实测下来一个典型的中等复杂度 agent3-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 成本是大头。但这里有三个极易被忽视的成本陷阱我踩过坑Tool Call 超时黑洞如果你的某个 tool比如一个慢 SQL 查询设置了 30 秒超时而 harness 的默认等待是 60 秒那么这额外的 30 秒 idle 时间会被计入 session-hour。解决方案在 YAML 的tools定义中显式设置timeout_ms: 30000让 harness 在 30 秒后主动放弃避免空转。Session 泄漏一个 session 创建后如果没有显式调用DELETE /v1/sessions/{id}它会默认存活 7 天。如果你的前端每点一次按钮就创建一个新 session而没清理旧的几天后就会堆积成百上千个 dormant session虽然不活跃不计费但会占用资源配额且 event log 存储有成本。生产中必须实现 session 生命周期管理前端创建 session 时后端记录session_id和created_at用户离开页面或任务完成时后端主动调用 delete endpoint。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 tokenscope 仅限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 的机会。目前市场上三家领跑者打法截然不同BrainstoreBraintrust专为 AI log 设计的列式 OLAP 数据库。它把event_type,session_id,tool_name,duration_ms,status等字段作为一级维度支持亚秒级聚合查询。我们用它实现了“agent 健康度大盘”实时显示各 agent 的成功率、平均延迟、高频失败 tool。它的优势是性能劣势是封闭商业版价格不菲。PhoenixArizeApache 2.0 开源核心是langchain和llama_index的 tracing SDK。它把 event log 导出为 OpenTelemetry 格式你可以用任何兼容 OTel 的 backend如 Jaeger, Grafana Tempo来存储和查询。我们选择将其接入自建的 ClickHouse 集群因为我们可以完全掌控 schema 和索引策略。开源的好处是自由代价是运维成本。LangSmithLangChain 生态的“亲儿子”安装即用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服务把所有 runtimeAnthropic, 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 之上的、尚未被标准化的、充满人性洞察的领域。