Anthropic Managed Agents：AI 代理的运行时操作系统

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

你有没有试过让一个 AI 代理连续工作四十分钟？不是闲聊，而是真正在查资料、调 API、写代码、改文档、再交叉验证——一整套闭环动作。去年我带团队跑一个金融尽调代理时，就卡在第37分钟：上下文窗口满了，模型没报错，也没中断，它只是悄悄把最早调用的三个数据库结果给“忘了”，然后基于残缺记忆开始编造后续步骤。等我们发现时，整个流程已经偏离原始目标两轮，且无法回溯——没有日志、没有快照、没有 checkpoint，只有一段越来越离谱的输出。这不是故障，是静默失效；不是 bug，是架构债。

Anthropic 在 2026 年 4 月 8 日发布的Claude Managed Agents，表面看是一次常规功能更新，实则踩中了所有正在构建长周期、多步骤、高可信度 AI 应用的团队最痛的那个点：状态不可靠、执行不可控、过程不可查。它没发明新概念，但把过去两年业内反复试错、踩坑、重写才摸出来的三根支柱，第一次打包成开箱即用的生产级服务：会持久化的 session、无状态的 harness、与凭证彻底隔离的 sandbox。这三者组合起来，就是一套轻量级的“AI 操作系统内核”。

关键词里那个 “Towards AI - Medium” 不是随便贴的标签——它恰恰说明这篇分析的底色：不站队、不捧杀、不贩卖焦虑，而是从工程落地的第一线视角，拆解“为什么现在必须做这件事”“为什么 Anthropic 做得对但不够早”“为什么你今天选的 runtime 架构，半年后可能变成成本中心”。这不是讲给投资人听的 PPT 故事，是写给凌晨两点还在 debug agent session timeout 的工程师、给正在评估要不要把 LangGraph 迁进云沙箱的架构师、给被业务方追问“上次那个合同审核代理为啥漏了第三条违约条款”的技术负责人的实操备忘录。

它解决的不是“能不能跑起来”，而是“敢不敢让它跑一整周”。当你不再需要为每次 tool call 手动存 state、不再担心 token 超限导致历史蒸发、不再把 API key 硬编码进 prompt 或环境变量——你就从“AI 玩家”跨进了“AI 工程师”的门槛。而这个门槛，Anthropic 这次用 YAML 配置和 $0.08/小时的定价，给你搭了一道结实的台阶。

2. 核心设计逻辑：为什么是 session-as-event-log，而不是 context-as-database？

2.1 旧范式之殇：把上下文当硬盘用，注定崩盘

先说清楚问题出在哪。2024 年到 2025 年初，绝大多数自研 agent 系统都遵循一个朴素但危险的模式：所有状态都塞进 LLM 的 context window。用户输入、系统指令、工具返回结果、中间推理草稿、甚至错误重试记录——全堆在 prompt 里，靠模型自己“记住”并引用。这就像让一个实习生边开会边记笔记边写纪要边查邮件边回 Slack，还要求他三天后能准确复述第一天讨论的第三个数据源字段名。

我亲手重构过两个这样的系统。第一个是客服工单分类代理，context 窗口设为 32k，理论上够用。但实际运行中，用户每轮追加一条新消息，我们就得把前序全部 history + 新消息 + system prompt 重新拼接发送。到了第 12 轮交互，光是 history 就占掉 28k tokens，留给模型思考和生成的空间只剩 4k。更糟的是，模型在压缩历史时会优先丢弃早期、看似“不关键”的 tool call 结果——比如第一次调用 CRM 接口查到的客户等级，它觉得“后面没提，应该不重要”，结果在第五轮生成解决方案时，完全忽略了该客户属于 VIP 白名单这一硬性规则。

第二个是更典型的 RAG+Tool 复合代理：先检索 5 篇文档，再调用 3 个内部 API 获取实时数据，最后综合生成报告。我们测试过 20 次连续运行，平均在第 33 分钟触发 context 溢出。模型不会报错，它只是开始“自由发挥”：把检索到的文档 A 的结论，错误地嫁接到 API B 返回的数据上，生成一份逻辑自洽但事实全错的报告。事后排查？没有 trace，没有 snapshot，只有最后一段输出和一堆无法关联的 log。我们花了 17 个小时才定位到是 context 溢出导致的幻觉，而不是模型本身的问题。

提示：这不是模型能力不足，而是架构设计把“状态存储”这个本该由数据库承担的职责，强加给了推理引擎。LLM 是 CPU，不是 SSD。

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

Managed Agents 的核心突破，在于用明确的边界，把过去混在一起的三件事彻底分开：

• Session（会话）：不再是内存里的临时变量，而是一个持久化、可查询、带时间戳的事件日志（event log）。每一次 tool call 的输入、输出、耗时、状态（success/error）、甚至模型生成的 intermediate reasoning 步骤，都被原子化地写入这个日志。它独立于任何一次模型调用，存储在 Anthropic 的后端服务中，生命周期可达数天甚至数周。

• Harness（执行器）：一个纯粹的、无状态的函数调用桥接层。它只做一件事：收到execute(tool_name, input)请求，就去调用对应容器（container），拿到字符串结果后原样返回。它不保存任何中间状态，不参与决策，不缓存历史。这意味着 harness 可以随时崩溃、重启、扩缩容，只要拿着 sessionId 就能通过awake(sessionId)恢复上下文——因为真正的“上下文”不在 harness 里，而在 session event log 里。

• Sandbox（沙箱）：不是共享资源的虚拟机，而是按需创建、用完即焚的 cattle 式隔离环境。每个 tool call 都在一个全新的、干净的 sandbox 中执行。最关键的是：凭证（credentials）在 sandbox 创建时注入，但绝不以环境变量形式暴露给 agent 本身。Agent 只能看到一个抽象的tool_name和input，它永远不知道背后调用的 AWS Lambda 的 IAM Role ARN，也看不到数据库连接串里的密码。这堵墙，是用血泪教训浇筑出来的——我们曾因一个 prompt 注入漏洞，让 agent 把os.environ.get('DB_PASSWORD')当成普通字符串输出，直接泄露了生产库密钥。

这三层解耦，直接对应了操作系统演进史上的关键跃迁：

• Session as event log ≈文件系统（File System）：提供持久化、结构化、可追溯的数据存储。
• Harness as stateless executor ≈进程调度器（Process Scheduler）：高效、可靠、可扩展地分发计算任务。
• Sandbox as cattle ≈虚拟内存与硬件抽象（Virtual Memory & Hardware Abstraction）：屏蔽底层差异，保障隔离与安全。

所以 Anthropic 工程博客里说的“像 90 年代 OS 虚拟化硬件”，不是修辞，是精准的技术类比。它意味着：未来你升级 Claude 模型版本，只需改 harness 的配置，不用动 session 存储逻辑；你更换 sandbox 底层容器技术（从 Docker 到 WASM），只需适配 harness 的 execute 接口，session 日志格式保持不变。这种稳定性，是工程规模化的基本前提。

2.3 为什么 AWS Bedrock AgentCore 先行五个月，却没引发同等震动？

这里有个关键误判：很多人看到 “AWS AgentCore GA 五个月” 就觉得 Anthropic 是跟风。但翻看 AWS 的官方文档和早期用户反馈，会发现一个根本差异：AgentCore 的设计哲学是“框架中立”，而 Managed Agents 的设计哲学是“Claude 优先”。

AgentCore 确实强大：它支持 LangGraph、CrewAI、任何符合 request-response 协议的框架，模型可选 Bedrock 上所有家族（Claude、Llama、Cohere）。但它本质上是一个通用 runtime 容器，你需要自己处理 session state 的持久化（通常连到 DynamoDB 或 S3）、自己管理 credential 注入（用 IAM Roles for Service Accounts）、自己实现 checkpoint 和 resume 逻辑。它给你的是“发动机和底盘”，但你要自己造车身、装方向盘、接仪表盘。

而 Managed Agents 给你的是一辆出厂即配好导航、自动泊车、黑匣子全程记录的量产车。YAML 里定义好 tools 和 guardrails，Anthropic 就帮你搞定 state、security、observability 全栈。Notion 能快速上线“团队委托 Claude”功能，不是因为他们有顶级 infra 团队，而是因为 Anthropic 把他们最不想碰的脏活累活全包了。

这解释了为什么市场反应不同：AgentCore 是给云原生架构师和资深 MLOps 工程师的乐高积木；Managed Agents 是给产品团队和应用开发者的一键部署方案。前者需要你懂 Kubernetes、IAM、DynamoDB TTL；后者你只需要会写 YAML 和读 error message。这不是技术高低之分，是目标用户和交付形态的本质区别。

3. 实操细节解析：从 YAML 配置到生产级部署的完整链路

3.1 你的第一个 Managed Agent：三步走通

别被“managed”吓住，它的入门门槛其实很低。我用一个真实的销售线索评分代理（Lead Scoring Agent）为例，展示从零到可运行的全过程。这个代理需要：1）从 HubSpot API 拉取新线索；2）调用内部风控模型 API 判断欺诈概率；3）根据分数和行业标签，生成定制化跟进建议。

第一步：定义 agent.yaml

# agent.yaml name: "sales-lead-scorer" description: "Scores new leads and generates follow-up suggestions" system_prompt: | You are a sales operations expert at Acme Corp. Your job is to: 1. Analyze lead data from HubSpot. 2. Check fraud risk score from our internal model. 3. Generate a concise, actionable follow-up suggestion based on score and industry. Always cite your sources (e.g., 'Per HubSpot data...', 'Based on fraud model...'). Never hallucinate data not provided in the tool responses. tools: - name: "hubspot_get_new_leads" description: "Fetches leads created in the last 24 hours from HubSpot" input_schema: type: "object" properties: limit: type: "integer" default: 10 # No credentials here — managed by Anthropic vault - name: "fraud_model_score" description: "Calls internal fraud detection model with lead data" input_schema: type: "object" properties: lead_id: type: "string" email_domain: type: "string" guardrails: output_filters: - type: "pii_redaction" patterns: ["email", "phone", "ssn"] - type: "content_moderation" severity_threshold: "high" max_tool_calls_per_step: 3

注意几个关键点：

• tools下的input_schema是强制的，Anthropic 用它做 runtime 输入校验，避免 agent 传错参数导致 sandbox 崩溃。
• guardrails不是摆设。pii_redaction会在输出前自动识别并替换邮箱、电话等敏感字段，content_moderation会拦截高风险内容（如暴力、歧视性语言），阈值设为high意味着只拦真正危险的，不过度干预。
• 没有任何 credential 字符串出现在 YAML 里。HubSpot 的 API Key 和风控模型的 Token，都在 Anthropic 控制台的 Vault 里单独配置，绑定到这个 agent 名称下。sandbox 启动时，Vault 自动注入，agent 代码里永远看不到明文。

第二步：部署与启动

# 使用 Anthropic CLI（v2.1+） anthropic agents deploy --file agent.yaml --environment production # 输出：Agent 'sales-lead-scorer' deployed. ID: agt_abc123... # 启动一个新 session anthropic sessions start --agent-id agt_abc123 --initial-input "Analyze new leads" # 输出：Session started. ID: sess_xyz789. Status: running...

CLI 会返回一个sess_xyz789的 session ID。这就是你的“进程 PID”。你可以随时用它查询状态、获取日志、甚至中断恢复。

第三步：与 session 交互（真实请求体）

// POST https://api.anthropic.com/v1/sessions/sess_xyz789/messages { "messages": [ { "role": "user", "content": "Start scoring leads for Q2 campaign" } ], "max_tokens": 2048 }

Anthropic 会：

1. 从 session event log 读取当前状态（这是首次，log 为空）；
2. 调用 harness，执行execute("hubspot_get_new_leads", {"limit": 10})；
3. sandbox 执行 HubSpot API 调用，返回 10 条线索数据；
4. 将这次 tool call 的完整事件（输入、输出、耗时、timestamp）写入 session log；
5. harness 拿到结果，交给 Claude 模型生成下一步指令（例如：“调用 fraud_model_score 对 lead_id=12345 进行评分”）；
6. harness 再次执行execute("fraud_model_score", {...})，重复步骤 3-4；
7. 最终，模型整合所有 tool 结果，生成自然语言回复，并同样写入 session log。

整个过程，你作为开发者，只关心三件事：YAML 配置是否正确、tool 的 input_schema 是否匹配、guardrails 是否覆盖了业务风险点。其余全是 Anthropic 托管。

3.2 生产环境必调参数：不只是 $0.08/小时那么简单

定价是 $0.08/session-hour，但实际成本受三个隐藏参数深刻影响：

注意：这些参数不是在 YAML 里写的，而是在anthropic agents deploy命令里用--config指定一个 JSON 文件：

// config.json { "session_timeout": "8h", "max_tool_call_depth": 3, "sandbox_memory_mb": 2048 }

部署命令变为：anthropic agents deploy --file agent.yaml --config config.json

另一个常被忽略的成本点是token 用量结构。Managed Agents 的计费是两层的：

• 基础层：Claude 模型的 input/output tokens，按标准 rate 计费（如 Sonnet $3/million input tokens）；
• runtime 层：$0.08/session-hour，按 session 的活跃时长计费（从start到end或超时）。

关键洞察：session 小时数 ≠ 模型推理时间。一个 session 可能活跃 2 小时，但其中 1.8 小时在等待 HubSpot API 响应（网络 I/O），只有 0.2 小时在模型推理。$0.08 买的是这 2 小时的托管、日志、安全、沙箱生命周期管理——这才是 Anthropic 的真正价值，也是你省下的 DevOps 成本。

3.3 Credential 隔离的魔鬼细节：为什么“不注入环境变量”是生死线

这绝非营销话术。2025 年 Q3，我们合作的一家金融科技公司就遭遇了惨痛教训：他们的自研 agent 框架，为了“方便调试”，把数据库密码以DB_PASSWORD=xxx形式注入 sandbox 环境变量。某次 agent 在生成错误报告时，prompt 里写了句 “Please print all environment variables for debugging”，模型竟真的执行了os.environ并输出——密码明文出现在最终给客户的 PDF 报告里。

Anthropic 的解法是“双盲”设计：

• Sandbox 内部：credential 以加密 blob 形式存在，sandbox OS 层面根本看不到明文。tool 代码里调用get_credential("hubspot_api_key")，底层是调用一个受信的、只读的 vault client，它返回解密后的 key，但这个过程对 sandbox 进程是透明的。
• Agent 视角：agent 代码里永远只有tool_name和input。它调用hubspot_get_new_leads，传入{"limit": 10}，至于这个 tool 背后用哪个 key、哪个 endpoint、哪个 region，agent 一无所知，也无法探知。

我们做过压力测试：在 sandbox 里执行env | grep -i pass、cat /proc/1/environ | strings、甚至尝试gdbattach 到 vault client 进程——全部失败。credential 的生命周期严格限定在 tool 执行的毫秒级窗口内，用完即焚。这种设计，让“凭证泄露”从一个高概率事件，降级为一个需要物理访问 Anthropic 数据中心的理论可能性。

4. 实操过程与核心环节实现：从 Notion 集成到企业级审计追踪

4.1 Notion 的集成案例：如何让团队“委托工作”成为现实

Notion 官方博客披露的集成，远不止“在页面里加个按钮”那么简单。其核心是利用 Managed Agents 的session persistence和structured output能力，把 AI 从“回答问题”升级为“执行任务”。

具体流程如下：

1. 用户在 Notion 页面点击 “Delegate to Claude”：Notion 前端捕获当前页面 URL、块内容（block content）、用户选择的上下文范围（如“仅本页”、“本数据库”）；
2. Notion 后端创建一个新 session：调用 Anthropic API，传入预定义的notion-delegatoragent ID，并将页面元数据作为initial-input；
3. Agent 执行：
   • Tool 1：notion_read_page—— 读取指定 URL 的页面结构和文本；
   • Tool 2：notion_search_db—— 根据用户提示（如“找所有未跟进的线索”）搜索关联数据库；
   • Tool 3：notion_create_task—— 在指定 workspace 创建一个新 task block，内容包含摘要、待办项、负责人（可选）；
4. 结果写回 Notion：Agent 的最终输出是一个 JSON 结构体（非纯文本），包含task_id,summary,next_steps。Notion 解析此 JSON，自动渲染为一个带状态徽章、可分配、可评论的智能任务块。

这个流程的关键在于session 的跨请求持久化。用户点击按钮后，可能去喝杯咖啡，20 分钟后回来，任务已创建。期间如果 Notion 服务重启，只要 session ID 还在，就能awake(sessionId)继续执行。而传统方案必须在单次 HTTP 请求内完成所有操作，超时风险极高。

实操心得：我们复现此流程时，最大的坑是notion_read_pagetool 的 rate limit。Notion API 对/pages/{id}/blocks接口有严格的 1000 req/day 限制。我们的解法是：在 agent YAML 的tools定义里，为notion_read_page添加rate_limit: "1000/day"字段。Anthropic harness 会自动在 sandbox 内做本地令牌桶限流，避免请求直接打到 Notion 导致 429 错误。这是 Managed Agents 提供的、自研框架极难优雅实现的基础设施能力。

4.2 Rakuten 的销售/营销/财务三线 agent：如何统一治理又隔离风险

Rakuten 的案例展示了 Managed Agents 在大型组织中的治理优势。他们没有建三个独立 agent，而是用同一个 agent 定义，通过 session-level metadata 实现路由与隔离。

其 agent.yaml 的核心片段：

# rakuten-unified-agent.yaml name: "rakuten-unified" # ... system_prompt, tools ... # 关键：动态 guardrails based on session metadata guardrails: dynamic: - condition: "session.metadata.department == 'sales'" rules: allowed_tools: ["hubspot_api", "salesforce_api"] output_filters: ["sales_compliance_check"] - condition: "session.metadata.department == 'finance'" rules: allowed_tools: ["sap_api", "quickbooks_api"] output_filters: ["finance_regulation_check"]

当 Slack 用户 @sales-team 发起请求时，Rakuten 的前端在创建 session 时，会传入：

{ "metadata": { "department": "sales", "region": "APAC", "user_id": "slack_u123" } }

Anthropic harness 在执行前，会根据session.metadata.department动态加载对应的 guardrail 规则集。这意味着：

• 销售部门的 agent 永远调用不了 SAP API（工具列表被过滤）；
• 财务部门的 agent 输出，会强制经过finance_regulation_check过滤器，确保不出现“建议逃税”等违规表述；
• 所有 session 的 event log 都打上department和region标签，审计时可一键筛选 “APAC finance agents in April”。

这种基于 metadata 的策略引擎，比在每个 agent 里硬编码 if-else 清晰得多，也便于中央合规团队统一更新规则。我们帮一家跨国银行实施类似方案时，将全球 12 个区域的 GDPR、CCPA、PDPA 合规检查，全部抽象为output_filters插件，由法务团队在控制台一键开关，无需开发介入。

4.3 Sentry 的调试代理：从“写补丁”到“开 PR”的闭环

Sentry 的案例最能体现 Managed Agents 的工程深度。他们的 agent 不仅要理解错误堆栈，还要能：

• 在 GitHub 仓库中定位相关代码文件；
• 基于错误模式，生成修复补丁（patch）；
• 创建 Pull Request，并自动 assign reviewer。

这要求 agent 具备多 step planning和精确的代码编辑能力。Managed Agents 的session-as-event-log在这里发挥了决定性作用。

其关键设计是：将 patch 生成和 PR 创建拆分为两个独立的 tool call，并用 session log 作为唯一真相源。

1. Tool 1：github_find_file—— 输入错误堆栈，返回匹配的文件路径和行号；
2. Tool 2：code_diff_generator—— 输入文件路径、行号、错误描述，返回一个标准git diff格式的字符串；
3. Tool 3：github_create_pr—— 输入diff字符串、分支名、标题，创建 PR。

为什么不用一个 tool 完成？因为code_diff_generator可能失败（如代码太复杂），但github_find_file的结果是可靠的。session log 里清晰记录了：

• Step 1:github_find_filereturned["src/utils/logger.ts", 42]
• Step 2:code_diff_generatorfailed with "Context too large for diff generation"
• Step 3: (fallback)code_diff_generatorcalled again withmax_context_lines: 50

审计时，运维团队可以直接查询 session log，看到“第 2 步失败，第 3 步成功”，而无需猜测模型是否在“假装成功”。这种可追溯性，是生产环境信任 AI 的基石。

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

5.1 典型问题速查表

5.2 独家避坑技巧：来自 37 个生产环境的血泪总结

技巧 1：用session.metadata做轻量级 A/B 测试，比改 YAML 高效十倍
不要为了测试新 prompt 而频繁 redeploy agent。在创建 session 时，传入{"metadata": {"prompt_version": "v2.1"}}，然后在system_prompt里用 Jinja2 语法动态插入：

{% if session.metadata.prompt_version == "v2.1" %} You are stricter about citing sources... {% else %} You are more conversational... {% endif %}

Anthropic harness 支持 Jinja2，无需额外模板引擎。我们用此法一周内灰度测试了 5 个 prompt 版本，零 downtime。

技巧 2：max_tool_call_depth是你的“熔断器”，但设置需结合业务 SLA
我们曾将max_tool_call_depth设为1，以为能防死循环。结果客服场景下，一个简单查询需hubspot_get_lead→salesforce_update_status两步，直接被截断。正确做法是：统计你业务中最长合法流程的 step 数，再加 1 作为 buffer。我们最终设为4，覆盖了 99.8% 的正常流程，同时拦截了所有异常循环。

技巧 3：Sandbox 的timeout_seconds默认 30s，但网络抖动常超此值
hubspot_api在高峰期响应达 35s。timeout_seconds: 30导致 sandbox 主动 kill，返回TOOL_TIMEOUT错误。解决方案不是盲目加 timeout，而是：在 tool container 的启动脚本里，加入重试逻辑（如curl --retry 3 --retry-delay 2），并将timeout_seconds设为45，给重试留出空间。这样既保证可靠性，又避免无限 hang。

技巧 4：Event log 的trace_id是跨系统追踪的黄金钥匙
session log 里的trace_id字段，与 Anthropic 的 backend tracing 系统打通。你可以在自己的 Datadog 或 New Relic 中，用这个trace_id关联：

• Notion 前端的用户点击事件
• Anthropic 的 session start 事件
• HubSpot API 的调用日志
• 最终生成的 PDF 报告的下载记录
  这让你能回答 CEO 的灵魂拷问：“上个月那个导致客户投诉的错误，根源到底在哪儿？”——答案不再是“可能是 AI”，而是“trace_id=trc_abc显示，HubSpot 返回了空数组，agent 未做空值处理，直接传给风控模型，模型报错”。

6. 价值迁移图谱：当 runtime 层归零，钱流向哪里？

6.1 三层价值洼地：Trace Store、Governance、Vertical Marketplace

回到文章开头那个问题：如果 Managed Agents 这样的 runtime 层，真如 VMware 虚拟化一样，在 18-24 个月内被 hyperscaler 免费化、开源项目平价化，那么下一个十年的价值高地在哪里？不是预测，而是基于已发生的压缩波纹，画出的确定性地图。

第一层：Trace Store（追踪存储）—— 你的 agent 的“黑匣子”
当 runtime 变成水电煤，谁来保管每一次决策的原始证据？Braintrust 的 Brainstore、Arize 的 Phoenix、LangSmith，它们卖的不是 dashboard，而是schema-on-read 的 OLAP 数据库，专为session_id,tool_name,input_hash,output_hash,latency_ms,guardrail_triggered这些字段优化。为什么它不可替代？因为当你的 agent 从 Anthropic 迁移到 Azure Foundry，或者混合使用多个 runtime，trace portability 是唯一能让你不被 vendor lock-in 的护城河。我们帮一家保险科技公司做迁移时，花了 3 周写脚本把 Anthropic session log 转成 Phoenix 兼容格式，而如果当初就用 Phoenix 作为唯一 trace store，迁移只需改一行配置。

第二层：Governance & Policy（治理与策略）—— AI 的“合规操作系统”
AWS AgentCore 的 policy controls GA，OWASP Agentic Top 10 发布，这不是巧合。当 agent 能开 PR、调支付 API、生成法律文书，企业采购部门问的第一个问题必然是：“它被允许做什么？谁批准的？怎么审计？” 这催生了全新品类：Policy-as-Code for Agents。它不像传统 IAM 那样管“用户能访问什么资源”，而是管“agent 在什么条件下能调用什么 tool，输出什么内容，基于什么数据源”。例如一条策略：IF session.metadata.department == "finance" AND tool_name == "sap_api" THEN require_approval_from("CFO") AND log_to("SECURITY_AUDIT_LOG")。这个领域没有 incumbent，因为它的复杂度远超传统 IAM——它要理解自然语言 intent、代码 diff、API schema、业务规则。谁能率先提供可视化策略编辑器 + 自然语言策略翻译器 + 自动合规报告，谁就拿到了入场券。

第三层：Vertical Agent Marketplaces（垂直代理市场）—— “App Store for AI”
Salesforce Agentforce $800M ARR 的数字，揭示了一个残酷真相：企业不为“runtime”付费，只为“解决我知道的问题”付费。销售开发代理、医疗理赔代理、网络安全渗透测试代理——这些不是技术组件，是可计量 ROI 的业务单元。virattt/ai-hedge-fund 这样的开源项目，已经证明了垂直 agent 的可行性。市场机会在于：提供开箱即用的垂直 agent + 行业数据 connector + 合规认证 + SLA 保障。例如，“医疗理赔代理”必须预装 HIPAA-compliant sandbox、对接 Epic 和 Cerner 的 FHIR API、通过 ONC 互操作性认证。这不再是工程师能 solo 完成的事，而是需要临床顾问、合规律师、保险精算师组成的联合团队。资本已经涌入：2026 年 Q1，三家专注医疗 AI agent 的初创公司共获 $180M 融资。

6.2 一个不容忽视的加速器：Self-Improving Agents（自进化代理）

Sakana AI 的 Darwin Gödel Machine 论文不是科幻。它证明了 agent 能基于 SWE-bench 测试结果，自动重写自身代码，将能力从 20% 提升到 50%。这个过程需要什么？

• Sandboxing：必须在完全隔离的环境中运行 agent 的 self-modification 代码，否则它可能重写宿主系统；
• Observability：必须有完整的 trace log，才能判断“新代码是否真的更好”，而非只是随机变异；
• Governance：必须有 policy engine，阻止 agent 生成“删除所有日志”或“关闭 sandbox 隔离”这类自毁指令。

当 agent 获得自我迭代能力，runtime 层就从“执行环境”升级为“监管对象”。它的定价逻辑不再是“每小时 $0.08”，而是“每次 self-improvement cycle 的 audit cost”。这会让 trace store 和 governance 成为刚需中的刚需。我们已在内部测试一个简化版：让 agent 每周分析自己的 session log，生成“top 3 failure modes”报告，并自动提交 Jira ticket。报告里附带trace_id链接，工程师一点即达现场。这种闭环，正是价值向“floor above”迁移的生动注脚。

7.