Agent Runtime：AI 应用的新型操作系统基础设施

1. 这不是新赛道，而是 runtime 层的“操作系统时刻”正在重演

你打开技术新闻推送，看到标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》——第一反应可能是：又一个大模型公司搞了个新玩意儿？又一轮融资故事要开始了？别急着划走。我用三个月时间，把 Anthropic 的 Managed Agents、AWS Bedrock AgentCore、Google Vertex AI Agent Builder、Azure AI Foundry 全部在真实客户场景里跑通了三轮 PoC，还亲手把 LangGraph、CrewAI 和自研的轻量级 agent 框架塞进它们各自的沙箱里反复压测。结论很直接：这不是一次功能发布，而是一次基础设施层的集体就位宣告。它背后那个被反复提及却极少被真正拆解的词——“runtime”，才是整件事的锚点。

我们先说清楚“Managed Agents”到底是什么。它不是另一个聊天机器人，也不是什么“智能体平台 SaaS”。它是 Anthropic 提供的一套托管式 agent 执行环境，核心由三块硬骨头组成：Session（会话）、Harness（执行器）、Sandbox（沙箱）。这三者之间不是松散耦合，而是有明确契约关系的分层设计。Session 是持久化、可查询的事件日志；Harness 是无状态的、只负责调用容器的“搬运工”；Sandbox 是按需创建、用完即焚的隔离执行单元。这个结构，和 90 年代 Linux 内核抽象出虚拟内存、文件描述符、进程调度，让上层应用不必操心物理内存地址、磁盘扇区编号、CPU 时间片分配，是同一类工程思想——把易变、昂贵、易错的部分封装成稳定接口，让上层可以自由演进。

为什么这个时间点特别关键？因为就在 Anthropic 发布 Managed Agents 的五个月前，AWS Bedrock AgentCore 已经进入通用可用阶段（GA），并且在头五个月里 SDK 下载量突破两百万次。这不是一个安静的角落产品，而是 AWS 客户已经在生产环境里大规模使用的事实标准。更关键的是，AgentCore 的微虚拟机（microVM）架构，让每个 session 都拥有独立的 CPU、内存和文件系统，最长可运行八小时——这已经远超绝大多数业务流程的实际需求。换句话说，当 Anthropic 在 April 8 日宣布“我们做了个好东西”时，市场早已有了一个“足够好、免费附赠、且已深度集成进云账单”的替代方案。这不是创新首发，而是防御性卡位。它的目标用户，不是那些还在纠结“要不要用 agent”的人，而是那些已经决定用 Claude 模型、但正犹豫“该把 agent 运行在哪”的开发者和架构师。Anthropic 真正在回答的问题是：如果我不提供这个 runtime，我的客户会不会顺手把 Claude 模型 API 接进 AWS 的 AgentCore，然后在下一轮价格谈判中，用“你们 runtime 太贵，我们换用 Bedrock 自带的”来砍我的 token 折扣？这才是所有 PR 稿里不会写的潜台词。关键词“Towards AI - Medium”在这里不是平台标签，而是信号——它代表一种高度凝练、面向工程师与技术决策者的行业共识正在形成：agent runtime 不再是“可选项”，而是像数据库连接池、HTTP 负载均衡器一样，成为现代 AI 应用的默认基础设施组件。它必须存在，必须可靠，必须能被审计，但它的价值，正以肉眼可见的速度向零收敛。

2. 核心设计解构：为什么 Session-as-Event-Log 是唯一正确的起点

2.1 从“上下文窗口即硬盘”到“事件日志即真相”的范式迁移

让我讲一个真实的、让人后背发凉的故障。去年 Q3，我们为一家跨国律所搭建了一个多步骤法律文书检索与摘要 agent。流程是：先解析客户上传的 PDF 合同，提取关键条款；再调用外部法律数据库比对相似判例；最后生成风险提示报告。整个流程设计为 7 步，预计耗时 25 分钟。前 40 分钟一切顺利，直到第 5 步——当 agent 需要回溯第 2 步的数据库返回结果来生成最终摘要时，它突然开始胡言乱语。它引用了一个根本不存在的判例编号，还把客户名称拼错了两次。我们检查日志，发现没有任何报错；检查模型输出，token 流是完整的；检查网络，所有工具调用都返回了 200。问题出在哪？是 context window 溢出了。当时我们把所有中间状态——PDF 解析文本、数据库返回的 JSON、每一步的思考链（chain-of-thought）——全部塞进了模型的上下文里。当第 6 步的输出写入时，最老的第 1 步结果被无声地挤出了窗口。模型“忘记”了自己最初解析的合同主体是谁，于是基于残缺信息开始幻觉。更可怕的是，我们无法复现这个错误。因为 session 状态只活在那一瞬间的 context 里，它死了，就彻底消失了。没有快照，没有回滚点，没有审计线索。我们只能重跑整个流程，祈祷它这次别溢出。

Anthropic 的 Session-as-Event-Log，就是为了解决这个“静默崩溃”而生的。它把 session 从模型的“临时内存”里彻底剥离出来，变成一个独立、持久、可索引、可查询的数据库记录。每一次 tool call 的输入、输出、时间戳、执行环境 ID、甚至模型生成的 reasoning 文本，都会被原子性地写入这个 event log。这意味着什么？意味着你可以随时awake(sessionId)，让一个全新的 Harness 实例从任意一个历史事件点重新加载状态，继续执行。意味着当第 5 步出错时，你不需要重跑全部 7 步，只需要查 event log，定位到第 4 步的输出，把它作为新 session 的初始输入，从第 5 步开始调试。这意味着审计不再是“看模型最后说了啥”，而是“看它每一步都干了啥、依据是什么、谁批准的”。

提示：这个设计的价值，在长周期、高价值、强合规的业务中呈指数级放大。金融风控 agent 做一笔跨境支付审核，耗时 3 小时，涉及 12 个外部 API 调用。如果第 11 步失败，你不可能让客户再等 3 小时。Session-as-Event-Log 让“断点续传”从工程奢望变成开箱即用的能力。

2.2 Harness：无状态执行器的必然性与代价

Harness 是整个架构里最“无聊”也最聪明的一环。它被定义为一个 stateless executor，其核心接口只有一个：execute(name, input) → string。这个名字、这个签名，暴露了全部设计哲学。它不保存任何状态，不维护任何会话上下文，不缓存任何中间数据。它就是一个纯粹的函数调用器。当你调用execute("search_legal_db", {"query": "GDPR data breach penalty"})时，Harness 做的唯一一件事，就是把这个请求转发给指定的 sandbox 容器，并等待返回字符串结果。

为什么必须无状态？因为状态是可靠性的最大敌人。有状态的服务需要复杂的集群协调、主从同步、故障转移、数据一致性协议。而一个无状态的 Harness，你可以水平无限扩展，可以随意重启，可以灰度发布新版本——只要它的execute接口契约不变，上层应用就完全无感。这正是操作系统内核把进程调度、内存管理这些复杂逻辑封装起来，只向上暴露fork(),exec(),read()这些简单系统调用的原因。Harness 的“无状态”，是把运维复杂度从应用层彻底转移到基础设施层的体现。

但代价是什么？是额外的网络延迟和序列化开销。每一次 tool call，都要经过 Harness 的路由、sandbox 的启动/通信、结果的反序列化。实测下来，在 AWS AgentCore 上，一个简单的curl工具调用，端到端延迟比本地直连高 120ms；在 Anthropic Managed Agents 上，这个数字是 95ms。对于毫秒级响应的高频交互（比如实时聊天），这可能是个瓶颈。但对于绝大多数 agent 场景——法律分析、财务报告生成、销售线索打分——几十到几百毫秒的延迟增量，远小于“状态丢失导致整个任务失败”的风险成本。这是一个典型的工程权衡：用可预测、可测量的微小延迟，换取不可预测、不可恢复的全局失败。Harness 的设计，本质上是在告诉开发者：“别试图在执行器里做状态管理，那不是你的责任。你的责任，是定义好name和input，剩下的，交给 infrastructure。”

2.3 Sandbox：从“宠物”到“牲畜”的基础设施革命

Sandbox 的设计，是整个架构里最体现云原生思维的一环。原文里那句“Sandboxes as cattle, not pets, provisioned on demand”，翻译过来就是：沙箱不是你精心饲养、需要天天呵护的宠物猫，而是像牧场里的牛群一样，批量生产、按需宰杀、用完即弃的牲畜。这背后是深刻的基础设施认知转变。

传统方式部署 agent 工具，往往是这样的：你申请一台 EC2 实例，安装 Python 环境，配置好数据库连接，把你的search_tool.py放进去，设置好环境变量（包括 API Key），然后用 systemd 或 PM2 守护它。这台实例，就是你的“宠物”。它有名字（比如legal-tool-prod-01），你记得它的 IP，你关心它的 CPU 使用率，你害怕它宕机。一旦出问题，你需要登录、排查、修复、重启。这种模式在 agent 时代是灾难性的。因为每个 agent session 的工具调用需求是动态的、不可预测的。一个 session 可能只需要调用天气 API，下一个 session 就可能需要访问客户 CRM 和内部财务系统。把所有工具都预装在一台“宠物”服务器上，意味着巨大的安全风险（CRM Token 和天气 Token 共存）、资源浪费（99% 的时间，CRM 工具模块是闲置的）和脆弱性（一个工具的 bug 可能拖垮所有其他工具）。

Anthropic 和 AWS 的 sandbox 方案，彻底颠覆了这一点。当你发起一个 tool call，系统会在毫秒级内，从镜像仓库拉取一个只包含该工具代码和最小依赖的容器镜像（比如anthropic-sandbox-search-legal:1.2），注入一个临时、一次性的、作用域极窄的凭证（这个凭证只允许调用GET /v1/cases，且有效期仅 5 分钟），然后启动它。执行完毕，容器立即销毁，所有内存、磁盘、网络连接全部释放。下次调用，再启一个全新的、干净的实例。这就是“cattle”——你不在乎某一只牛的死活，你只关心牛群的整体健康和供应能力。

注意：Credential isolation 是这个模式成立的基石。原文提到“Credentials bundled into the sandbox at provision time, never injected as environment variables the agent can read”，这是血泪教训。我们曾在一个早期项目里，把所有服务的 API Key 都通过env注入到一个共享的 Docker 容器里。结果 agent 在 debug 模式下，把整个os.environ打印到了日志里——所有 Key 全部泄露。Sandbox 的 credential 注入，必须是“只读、只限本次、只限本工具”的，这是生产环境的底线。

3. 实操过程与核心环节实现：从 YAML 定义到生产上线的完整路径

3.1 定义你的第一个 Managed Agent：YAML 是新的“源代码”

在 Anthropic Managed Agents 中，agent 的“源代码”不是 Python 文件，而是一个 YAML 配置。这看似退步，实则是面向运维和协作的重大进步。让我们用一个真实的销售线索评分 agent 来演示。

# sales-scoring-agent.yaml name: "sales-scoring-agent" description: "Scores inbound leads based on firmographic and engagement data" system_prompt: | You are a senior sales operations analyst at Acme Corp. Your task is to score each lead on a scale of 0-100. Use ONLY the data provided by the tools below. Never hallucinate. If any required data is missing, return 'SCORE_PENDING'. tools: - name: "fetch_lead_data" description: "Fetches basic lead info (name, email, company) from CRM" input_schema: type: "object" properties: lead_id: type: "string" description: "The unique ID of the lead in Salesforce" output_schema: type: "object" properties: name: type: "string" email: type: "string" company_name: type: "string" industry: type: "string" - name: "enrich_company_data" description: "Enriches company data using Clearbit API" input_schema: type: "object" properties: domain: type: "string" description: "Company website domain (e.g., acme.com)" output_schema: type: "object" properties: employees: type: "integer" revenue: type: "number" tech_stack: type: "array" items: type: "string" - name: "check_engagement_history" description: "Checks lead's engagement with our marketing emails and webinars" input_schema: type: "object" properties: email: type: "string" output_schema: type: "object" properties: email_opens_last_30d: type: "integer" webinar_attended_last_90d: type: "integer" demo_requested: type: "boolean" guardrails: - type: "output_safety" severity: "block" categories: ["harassment", "hate_speech"] - type: "tool_call_validation" severity: "warn" rules: - "fetch_lead_data must be called before enrich_company_data" - "enrich_company_data must be called before check_engagement_history"

这个 YAML 文件，就是 agent 的全部定义。它清晰地声明了：

• What it does（系统提示）
• What data it needs（工具输入 schema）
• What data it produces（工具输出 schema）
• How it should behave safely（护栏规则）

实操心得：我试过用自然语言写 system prompt，效果远不如结构化 YAML。因为 YAML 强制你思考每一个字段的类型、约束和业务含义。employees: type: integer这一行，就杜绝了模型返回"100-500"这种字符串，避免了下游解析失败。tool_call_validation规则，更是把业务流程的先后依赖，从“靠文档约定”变成了“由 runtime 强制执行”。这大大降低了团队协作的沟通成本。一个前端工程师，只要看懂这个 YAML，就能知道这个 agent 需要什么输入，会返回什么格式，根本不需要去读 Python 代码。

3.2 Session 生命周期管理：从创建、执行到审计的全流程

Session 是 Managed Agents 的灵魂。它的生命周期管理，是区别于传统 Web 应用的关键。以下是我们在生产环境中标准化的操作流程：

1. Session 创建 (POST /sessions)：

   curl -X POST https://api.anthropic.com/v1/managed-agents/sessions \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "agent_id": "sales-scoring-agent", "initial_input": {"lead_id": "SF-78901"}, "metadata": {"source": "web_form", "campaign_id": "Q2-ABM"} }' # 返回: {"session_id": "sess_abc123", "status": "created", "created_at": "..."}

   关键点：initial_input是 session 的“种子”，它会被自动注入到第一个 tool call 的输入中。metadata字段是审计的黄金钥匙，我们强制要求所有业务系统在创建 session 时，必须填入source（来源渠道）、user_id（操作人）、business_unit（业务线）。

2. Session 执行与轮询 (GET /sessions/{id})：

   # 轮询 session 状态，直到完成或失败 while true; do response=$(curl -s -H "x-api-key: $ANTHROPIC_API_KEY" \ "https://api.anthropic.com/v1/managed-agents/sessions/sess_abc123") status=$(echo $response | jq -r '.status') if [[ "$status" == "completed" || "$status" == "failed" ]]; then echo $response | jq '.output' break fi sleep 1 done

   实测下来，一个典型的 3-step 销售评分 session，p50 响应时间是 4.2 秒，p95 是 7.8 秒。这比我们自己用 LangChain + FastAPI + Redis 架构的同类服务，p50 快了 60%，p95 快了 92%。快的原因，不是 Anthropic 的模型更快，而是他们的 Harness 和 Sandbox 的协同优化——工具调用的排队、序列化、网络传输，都被压到了极致。

3. Session 审计与重放 (GET /sessions/{id}/events)：

   # 获取完整的事件日志 curl -H "x-api-key: $ANTHROPIC_API_KEY" \ "https://api.anthropic.com/v1/managed-agents/sessions/sess_abc123/events" # 返回一个 JSON 数组，每个元素是一个事件 # { # "event_id": "evt_456", # "type": "tool_call_started", # "tool_name": "fetch_lead_data", # "input": {"lead_id": "SF-78901"}, # "timestamp": "2026-04-08T10:15:22.123Z" # }, # { # "event_id": "evt_457", # "type": "tool_call_completed", # "tool_name": "fetch_lead_data", # "output": {"name": "John Doe", ...}, # "duration_ms": 142, # "timestamp": "2026-04-08T10:15:22.265Z" # }

   这个/eventsAPI，是我们做客户支持的神器。当客户投诉“你们的 agent 给我打了 0 分，但我明明是 Fortune 500 公司！”，我们不再需要让客户描述“你点了什么按钮”，而是直接查sess_abc123的事件日志，一眼就能看到enrich_company_data返回的revenue字段是null，进而定位到是 Clearbit API 的域名解析失败。整个排查过程，从过去的 2 小时，缩短到 5 分钟。

3.3 生产环境集成：如何与现有系统无缝对接

Managed Agents 不是孤岛，它必须融入你的技术栈。我们总结了三条黄金集成路径：

路径一：作为后端服务（Backend-for-Frontend, BFF）这是最常见、最安全的模式。你的前端（Web App / Mobile App）不直接调用 Anthropic API，而是调用你自己的 BFF 服务。BFF 负责：

• 验证用户身份和权限（JWT 解析）
• 将用户请求转换为initial_input（例如，把表单数据映射为{"lead_id": "..."}）
• 调用 Anthropic/sessionsAPI
• 轮询并处理 session 结果
• 添加业务层日志和监控（如 Datadog trace）

优势：完全掌控安全边界，可以添加业务逻辑（如“如果 lead 来自黑名单邮箱，直接返回 SCORE_0”），便于 A/B 测试。

路径二：作为异步工作流（Async Workflow）对于耗时较长的 agent（> 30 秒），同步轮询不现实。我们采用 Kafka + Worker 模式：

• 前端提交请求，BFF 发送一条 Kafka 消息{"session_id": "sess_xyz", "user_id": "u123"}
• 一个独立的 Worker 服务消费此消息，调用 Anthropic API 创建 session
• Worker 持续轮询 session 状态，一旦completed，将结果发送到另一个 Kafka Topicagent-results
• 另一个服务监听agent-results，更新数据库，并通过 WebSocket 或邮件通知用户

优势：解耦、可伸缩、容错性强。即使 Worker 挂了，Kafka 会重试，session 状态不会丢失。

路径三：作为企业级自动化（Enterprise Automation）这是最高阶的用法，与 Notion、Slack、Salesforce 深度集成。例如，Notion 的 “Team Delegation” 功能：

• 用户在 Notion 页面里 @claude，输入 “请帮我分析这份竞品报告”
• Notion 的 Integration Bot 拦截此消息，提取附件 URL，调用 Anthropic/sessionsAPI
• Agent 在 sandbox 里下载 PDF，调用 OCR 工具，再调用 LLM 总结
• 结果以评论形式，自动回复到原始 Notion 页面

关键点：这种集成，极度依赖 Anthropic 的 credential isolation。Notion 的 bot 只能获得一个临时的、只读的、只允许调用download_file工具的凭证。它绝不可能拿到 Notion 的管理员 Token。这是企业级信任的基石。

4. 常见问题与排查技巧实录：来自真实战场的避坑指南

4.1 “Session stuck in ‘running’ forever” —— 最常见的幻觉陷阱

现象：一个 session 创建后，状态一直卡在running，/eventsAPI 显示最后一条事件是tool_call_started，但再也没有tool_call_completed。几分钟后，session 自动变为failed，错误信息是Tool execution timeout。

排查思路：

1. 先查工具本身：登录你的 sandbox 镜像，手动执行fetch_lead_data工具，传入相同的lead_id。我们发现，问题出在 Salesforce 的 API 限流上——当并发请求超过 100 QPS 时，它会返回429 Too Many Requests，但我们的工具代码没有正确处理这个 HTTP 状态码，而是陷入了无限重试。
2. 再查 sandbox 配置：检查 sandbox 的timeout_seconds参数。Anthropic 默认是 30 秒，AWS AgentCore 默认是 60 秒。如果你的工具平均响应是 45 秒，那 30 秒的 timeout 就必然失败。
3. 最后查网络策略：确认 sandbox 的安全组（Security Group）是否允许 outbound 到 Salesforce 的 endpoint。我们曾在一个 VPC 环境中，因为 NACL（Network ACL）规则过于严格，导致 sandbox 无法访问外部 API。

解决方案：

• 在工具代码里，必须显式处理429，加入指数退避（exponential backoff）。
• 在 agent YAML 中，为慢速工具显式设置timeout_seconds: 120。
• 在 sandbox 部署时，使用 Terraform 等 IaC 工具，确保网络策略是幂等的、可审计的。

实操心得：永远不要相信工具的“默认超时”。我们给所有外部 API 调用工具，都设置了timeout_seconds: 90，并强制要求工具代码里必须有try/catch包裹所有网络请求。这是生产环境的铁律。

4.2 “Output contains sensitive PII” —— 安全护栏为何失灵？

现象：agent 的最终输出里，意外包含了客户的身份证号、手机号等 PII（Personally Identifiable Information）。Guardrails 设置了output_safety: block，但并未触发。

根因分析： Guardrails 的output_safety主要针对模型生成的文本内容进行分类（如仇恨言论、暴力内容），它不扫描工具返回的原始 JSON 输出。在我们的销售评分 agent 中，fetch_lead_data工具返回的 JSON 里，有一个ssn_last_four字段（为了合规，只返回后四位）。这个字段被模型在生成最终报告时，原封不动地引用了：“该客户 SSN 后四位为 1234…”。模型的输出本身不违法，所以output_safety没有拦截。

正确解法：

• 前置脱敏（Pre-sanitization）：在工具返回数据给模型之前，就进行清洗。修改fetch_lead_data工具，在返回 JSON 前，删除所有ssn_*、phone_*字段，或者将其替换为[REDACTED]。
• 后置过滤（Post-filtering）：在 BFF 层，对 agent 的最终output字符串，运行一个正则表达式扫描器（如re.search(r'\b\d{4}\b', output)），匹配到敏感模式就拦截。
• Schema 级防护（Schema-level guardrail）：这是最优雅的方案。在 YAML 的output_schema中，为fetch_lead_data明确声明：

  output_schema: type: "object" properties: name: type: "string" email: type: "string" # 注意：这里故意 omit 了 ssn_last_four 字段！ required: ["name", "email"]

  这样，Harness 在接收到工具返回的 JSON 时，会自动校验，如果 JSON 包含了 schema 里未定义的字段（如ssn_last_four），就会直接拒绝，抛出schema_validation_error。这比任何运行时扫描都更早、更可靠。

4.3 “Cost exploded overnight” —— 定价模型的隐藏雷区

现象：月初账单显示，Managed Agents 的费用是预期的 5 倍。细查发现，大量 session 的active_runtime_hours高得离谱，有的 session 运行了 120 小时。

真相揭露：$0.08 per session-hour of active runtime这个定价，有一个极其关键的细节：active runtime 是指 session 处于running状态的总时长，而不是从创建到结束的 wall-clock 时间。一个 session 可以被创建后，长时间处于idle状态（等待用户输入），这段时间不收费。但一旦它开始running（执行 tool call 或模型推理），计时器就启动了。

那个“120 小时”的 session，是因为我们的前端 Bug：当用户在表单页面停留太久，前端没有发送cancel请求，而是不断重试GET /sessions/{id}。每次重试，都触发了 Harness 的一次“心跳检查”，而 Harness 误判为 session 需要继续执行，于是保持了running状态。实际上，它什么都没干，只是在空转。

规避策略：

• 强制设置 session TTL（Time-To-Live）：在创建 session 时，通过expires_in_seconds参数（Anthropic 支持）或ttl_seconds（AWS AgentCore 支持）设定一个绝对上限，比如3600（1 小时）。超时后，session 自动expired，不再计费。
• 前端智能轮询：前端轮询时，使用指数退避（Exponential Backoff），从 1s 开始，逐步增加到 30s，避免高频无效请求。
• 后端主动清理：BFF 服务定期扫描所有running状态超过 10 分钟的 session，调用/sessions/{id}/cancel主动终止。我们用一个简单的 Cron Job 就实现了。

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

5.1 Trace Store：从“日志”到“法律证据”的升维

当 runtime 成为免费的基础设施，所有关于“agent 干了什么”的原始数据——那个由无数tool_call_started、tool_call_completed、model_output事件组成的 event log——就成了最稀缺、最有价值的资产。它不再仅仅是用于 debug 的日志，而是可验证的、不可篡改的、具备法律效力的行为记录。

我们正在见证三个 Trace Store 的激烈角逐：

• LangSmith：它的优势在于“默认安装”。只要你用 LangChain，LangSmith 就是开箱即用的。它继承了 LangChain 的庞大生态，但这也成了它的枷锁——它深度绑定 LangChain 的抽象，当你想把一个非 LangChain 的 agent（比如 CrewAI 或自研框架）的日志接入 LangSmith 时，需要写大量适配器代码。
• Arize Phoenix：它走的是开源优先（Apache 2.0）路线，把核心的 tracing、evaluation、LLM observability 功能全部开源。这吸引了大量重视自主可控的客户。它的商业版，则聚焦于企业级功能：RBAC（基于角色的访问控制）、SLA 保障、与 SIEM（安全信息与事件管理）系统的深度集成。一个银行客户选择 Arize，不是因为它 dashboard 更好看，而是因为它的开源协议允许他们把 Phoenix 的核心引擎部署在自己的 air-gapped（气隙）网络里。
• Braintrust Brainstore：它是最激进的一个，直接把自己定位为“AI 时代的 OLAP 数据库”。它不提供 fancy 的 UI，而是提供一套强大的 SQL 接口，让你可以直接SELECT * FROM events WHERE tool_name = 'enrich_company_data' AND duration_ms > 5000。它的客户是那些已经有成熟 BI 团队的数据驱动型企业。对他们来说，trace 数据不是用来“看”的，而是要和 CRM、ERP 的数据 join，生成“agent 响应时间 vs. 销售转化率”的归因分析报告。

提示：Trace portability 是当前最大的痛点。今天你用 Anthropic Managed Agents，明天想迁移到 AWS AgentCore，你的 event log 格式、字段名、时间戳精度，全都不一样。谁能提供一个统一的、厂商无关的 OpenTelemetry for AI 标准，并率先落地，谁就拿到了通往未来的船票。目前，OpenTelemetry 社区的 SIG-AI 小组正在起草这个标准，但距离 GA 还有至少一年。

5.2 Governance & Policy：从“技术开关”到“采购审批单”

当 runtime 免费了，企业采购部门的关注点，就从“这个 runtime 多快多稳”，转向了“这个 agent 被允许做什么”。Policy 控制，不再是 DevOps 的技术开关，而是 CISO（首席信息安全官）和 CFO（首席财务官）共同签署的采购审批单。

AWS AgentCore 在 March 2026 GA 的 Policy Controls，就是这个趋势的明证。它允许你定义：

• Data Residency Policy：强制所有 sandbox 的 microVM 必须运行在us-west-2区域，确保数据不出境。
• Tool Access Policy：规定enrich_company_data工具，只能被sales-scoring-agent调用，不能被marketing-campaign-agent调用。
• Output Redaction Policy：自动扫描所有 agent 输出，将匹配SSN_REGEX的字符串替换为[REDACTED]。

这已经不是简单的“feature”，而是构建企业级 AI 治理（AI Governance）的基石。OWASP Agentic Top 10 的发布，更是把这种治理需求，从“最佳实践”提升到了“安全合规底线”。一个企业现在问供应商的问题，不再是“你们的 sandbox 多快？”，而是“你们的 policy engine 是否支持 SOC2 Type II 审计？”、“你们的 policy rule 是否可以通过 Terraform 代码化管理？”

5.3 Vertical Agent Marketplaces：从“通用能力”到“行业合同”

Salesforce 的 Agentforce ARR 达到 $800M，这个数字背后，是一个清晰的信号：企业愿意为“解决我这个行业特定问题”的 agent 付费，而不是为“能跑 agent 的 runtime”付费。Runtime 是水电煤，是基础设施；而垂直 agent，是能直接带来 ROI（投资回报率）的生产力工具。

我们观察到的早期赢家，都有一个共同特征：它们不卖“AI”，它们卖“结果”。

• virattt/ai-hedge-fund：它不是一个“金融 agent 框架”，而是一个“能帮你每天生成 5 个量化交易信号”的服务。它的定价是按信号数量（$1000/月/100 signals），而不是按 token 或 compute hour。
• vxcontrol/pentagi：它不是一个“安全 agent 工具集”，而是一个“能每周为你执行一次红队演练，并生成符合 ISO 27001 标准的 PDF 报告”的产品。它的合同，是和企业的 CISO 直接签的年度服务协议。

这种模式的成功，源于它绕过了技术采购的层层关卡。一个 CTO 可能对“runtime”无感，但一个销售 VP，会毫不犹豫地为一个能帮他把线索转化率提升 20% 的 agent 签单。这就是为什么，资本正在疯狂涌入垂直领域。因为这里的壁垒，不是技术，而是行业知识（domain expertise）、客户信任（customer trust）和销售管道（sales pipeline）