1. 这不是新赛道，是 runtime 层的“操作系统时刻”来了
你有没有在深夜调试一个跑了三小时的 AI 代理，突然发现它开始胡言乱语，而你翻遍日志也找不到它上一步到底调用了哪个 API、返回了什么数据？或者更糟——它把你的 AWS 密钥当成了普通字符串，直接塞进了curl命令里发了出去？我去年就亲手干过这事。当时我们用的是最朴素的方案：把整个对话历史、工具调用结果、中间状态，全堆进 Claude 的上下文窗口里。前四十分钟一切顺利，直到第 42 分钟，模型突然开始“自由发挥”，把用户刚上传的 PDF 内容和三天前的 Slack 消息混在一起编造出一份根本不存在的会议纪要。没有报错，没有警告，只有静默的崩塌。我们甚至没法重放那个 session——因为“session”本身只活在模型那 200K token 的记忆里，一刷新就清零。
Anthropic 在 4 月 8 日发布的Claude Managed Agents公共测试版，表面看是一套托管运行时，但它的核心价值，恰恰就是为了解决我上面描述的这两个噩梦。它不是在造一个更快的轮子，而是在重新定义“轮子该长什么样”。关键词不是“agent”，而是session-as-event-log（会话即事件日志）和credential isolation（凭证隔离）。前者把状态从模型上下文里彻底剥离出来，变成一个独立、持久、可查询、可回溯的数据库记录；后者则让敏感凭证永远不碰沙箱环境，连环境变量都不经过，从根本上堵死信息泄露的路径。这背后是一整套被刻意设计出来的稳定抽象层：Session 是持久化事件流，Harness 是无状态执行器，Sandbox 是按需启停的 cattle（牲畜），而非需要精心呵护的 pets（宠物）。这些词听着像教科书里的概念，但它们解决的全是真实世界里让人头皮发麻的生产事故。它面向的不是想写个玩具 demo 的初学者，而是那些已经把 agent 部署进 Notion 工作区、让 Rakuten 的销售团队每天靠它生成客户报告、让 Sentry 的工程师靠它自动修 bug 并提 PR 的真实业务线。如果你正在评估是否要把自己的 agent 架构迁移到托管平台，或者正纠结于要不要自建一套沙箱系统，那么这篇文章里拆解的每一个设计决策、每一处参数取舍、每一条踩过的坑，都是我用真金白银和无数个加班夜换来的经验。它不讲大道理，只告诉你：为什么 Anthropic 要这么设计，为什么 AWS 五个月前就做了类似的事，以及，当 runtime 层开始像当年的虚拟化一样被压向零成本时，你手里的筹码，到底值多少钱。
2. 核心架构拆解：为什么是“Session as Event Log”，而不是“Agent as Stateful Process”
2.1 传统 agent 架构的致命伤：上下文即牢笼
在 Managed Agents 出现之前，绝大多数生产级 agent 系统都卡在一个看似优雅、实则脆弱的范式里：State lives in context（状态活在上下文里）。这个设计的出发点很朴素——模型本身就是个黑盒推理引擎，既然它能理解自然语言，那我们就把所有需要它记住的东西：用户原始提问、历史对话、工具调用的输入输出、中间计算结果、甚至当前任务的进度标记，全部用精心编排的 prompt “喂”给它。LangChain 的ConversationBufferMemory、LlamaIndex 的ChatEngine，底层逻辑莫不如此。它的好处是开发快、上手易，一个system_prompt + history + tools就能跑起来。但它的代价，是把整个系统的可靠性，押注在模型上下文窗口这个极其有限且不可控的资源上。
我们来算一笔硬账。假设你用的是 Claude 3.5 Sonnet，上下文窗口是 200K tokens。一个典型的多步骤分析任务，比如“分析用户上传的财报 PDF，提取关键财务指标，对比过去三年趋势，并生成 PPT 大纲”，其流程可能包含：PDF 解析（约 15K tokens）、表格结构化（约 8K tokens）、指标计算（约 5K tokens）、趋势分析（约 12K tokens）、PPT 大纲生成（约 3K tokens）。光是这些“有效载荷”加起来就接近 43K tokens。再算上每次 tool call 的 wrapper（<tool_result>标签、JSON schema 描述、错误处理提示），以及为了保证模型理解而重复嵌入的 system prompt 和任务指令，实际消耗很容易突破 60K tokens。这意味着，在一个 200K 的窗口里，你最多只能容纳 3-4 个这样的完整分析链路。一旦用户中途插入一个新问题，或者要求“再补充一下现金流部分”，系统就必须做一次“上下文压缩”——也就是丢弃最早的历史片段。而这个过程，模型自己是不知道的。它不会说“我忘了你昨天让我查的应收账款数据”，它只会基于一个残缺的、被截断的历史，继续“自信地”编造答案。这就是我前面提到的“静默崩塌”：没有 crash，没有 exception，只有越来越离谱的输出。更可怕的是，这种失败是不可复现、不可审计的。你无法回放那个 session，因为你根本没有保存完整的事件流；你无法定位问题根源，因为日志里只有最终的 response，没有中间的tool_call → tool_result → model_thinking的完整链条。
提示：这不是理论风险。2025 年 Q3，一家头部 SaaS 公司的客服 agent 因为上下文溢出，将两位不同客户的隐私信息（姓名、电话、订单号）错误拼接，生成了一份虚假的“联合投诉报告”，并自动发送给了双方。事故的根本原因，正是其 state management 机制完全依赖于模型上下文。
2.2 Anthropic 的解法：把“大脑”和“记忆体”物理分离
Managed Agents 的核心创新，就是用工程手段，强行打破了“state in context”的魔咒。它引入了一个清晰、稳定、外部化的抽象层：Session。你可以把它想象成一个专门为 AI agent 设计的、轻量级的、只追加（append-only）的数据库表。每一次用户发起请求、每一次模型决定调用工具、每一次工具返回结果、每一次模型生成最终回复，都会被序列化为一条结构化的事件（event），并以原子操作的方式写入这个 Session。这个 Session 的生命周期，与模型实例的生命周期完全解耦。模型（Harness）可以随时启动、崩溃、重启，只要它拿到同一个sessionId，就能通过awake(sessionId)接口，从这个外部的事件日志里，精准地加载出上一次中断时的全部上下文状态，然后无缝续上。
这个设计带来的好处是颠覆性的：
- 无限上下文：Session 的存储空间理论上是无限的（受限于云存储配额），它不再受制于任何模型的 token 限制。一个运行了 72 小时、调用了 2000 次 API、处理了 50 份文档的复杂任务，其完整历史依然毫发无损。
- 可审计、可回放：所有事件都带有时间戳、唯一 ID、调用者身份、输入/输出 payload（脱敏后）。你可以用 SQL 查询：“找出所有在
2026-04-05T14:00:00Z到2026-04-05T15:00:00Z之间，对finance_api工具的调用，且返回状态码为401的事件。” 你也可以一键重放整个 session，从头到尾观察 agent 的每一个思考步骤，这对于 debug 和合规审查是刚需。 - 故障恢复能力：Harness 崩溃不再是灾难。它只是一个无状态的执行器，就像一个函数计算（Function Compute）实例。它只负责接收
execute(name, input)的指令，调用对应的容器，然后把结果打包成 event 写回 Session。崩溃后，新的 Harness 实例只需读取 Session 的最新状态，就能立刻接管工作。这极大地提升了系统的可用性（SLA）。 - 模型无关性：Session 的格式是标准化的 JSON Schema。今天你用 Claude 3.5，明天换成 Gemini 2.0 或 Llama 4，只要它们能解析相同的 event log 格式，就能无缝接入。这为未来的模型切换提供了技术保障。
2.3 Credential Isolation：安全不是功能，是架构的基石
如果说 Session-as-Event-Log 解决的是“状态管理”的问题，那么Credential Isolation（凭证隔离）解决的就是“安全治理”的问题。这是另一个被无数血泪教训反复验证过的真理：永远不要把密钥当作数据来处理。
在传统方案中，为了让 agent 能调用外部 API，开发者通常会把 API Key、OAuth Token、数据库密码等敏感信息，作为环境变量（API_KEY=xxx）注入到 agent 运行的容器或进程里。模型在生成curl命令时，如果 prompt 写得不够严谨，或者模型本身出现幻觉，它就可能把API_KEY这个字符串，当成一个普通的、需要被打印出来的变量，直接输出在 response 里。更危险的是，它可能把这个 key 当作一个“参数”，错误地拼接到 URL 中，导致密钥被明文暴露在第三方服务的日志里。2025 年底，一家金融科技公司的 agent 就因此泄露了其核心交易网关的访问令牌，造成了数百万美元的潜在损失。事后复盘，根本原因就是密钥被当作环境变量注入，而模型的输出过滤机制存在盲区。
Managed Agents 的做法是釜底抽薪：Credentials are never injected into the sandbox（凭证永不进入沙箱）。Anthropic 在其后台维护了一个独立的、高安全等级的凭证保险库（Vault）。当你在 YAML 配置中声明一个工具（例如notion_api）时，你只需要指定它需要哪种类型的凭证（如notion_oauth_token），而不需要提供具体的 token 值。当 Harness 执行execute("notion_api", {...})时，它会向 Anthropic 的凭证服务发起一个受控的、带严格权限校验的请求。凭证服务会根据当前 session 的身份、工具的声明、以及预设的策略（Policy），动态地、临时地生成一个具有最小必要权限的短期访问令牌（short-lived access token），并将其安全地传递给目标工具的执行容器。整个过程，模型和沙箱环境全程“看不见”原始密钥。它们看到的，只是一个已经授权完毕、可以直接使用的、有明确作用域和有效期的令牌。这是一种典型的“零信任”（Zero Trust）架构思想：不默认信任任何组件，所有访问都必须经过显式的、细粒度的授权。
注意：这种设计并非没有代价。它增加了系统调用的延迟（一次额外的 Vault 请求），也提高了架构的复杂度。但对于任何需要处理企业级敏感数据的场景，这个代价是绝对值得的。它把一个原本高度依赖“prompt 工程”和“人工 review”的安全薄弱点，变成了一个由基础设施强制保障的、可审计、可策略化的安全基线。
3. 实操落地：从 YAML 配置到生产部署的完整链路
3.1 定义你的 Agent：YAML 是新的“源代码”
在 Managed Agents 的世界里，你的 agent 不再是一段 Python 代码，而是一个声明式的 YAML 文件。这听起来像是倒退，实则是工程成熟度的标志——它把关注点从“如何实现”（how）转移到了“是什么”（what）上。一个典型的agent.yaml长这样：
# agent.yaml name: "Sales-Dev-Researcher" description: "An agent that researches leads and generates personalized outreach emails." system_prompt: | You are a senior sales development representative at Acme Corp. Your goal is to research a lead company and generate a highly personalized, value-driven email for the CEO. Rules: - Always use the 'company_research' tool first to get basic info. - Then use 'news_search' to find recent press releases or funding news. - Finally, synthesize all findings into a concise, 3-paragraph email. - Never invent facts. If a tool returns no data, state that clearly. tools: - name: "company_research" description: "Get basic company info (industry, size, HQ) from Crunchbase." type: "http" url: "https://api.crunchbase.com/api/v4" method: "POST" # Credentials are NOT defined here. They are managed by Anthropic's Vault. # This is just the *schema* of the request. request_schema: $schema: "https://json-schema.org/draft/2020-12/schema" type: "object" properties: filters: type: "object" properties: identifier: type: "string" description: "The company domain name, e.g., 'acmecorp.com'" required: ["filters"] - name: "news_search" description: "Search for recent news about a company using Google News API." type: "http" url: "https://newsapi.org/v2/everything" method: "GET" request_schema: $schema: "https://json-schema.org/draft/2020-12/schema" type: "object" properties: q: type: "string" description: "The company name or domain to search for" from: type: "string" format: "date" description: "Start date for news search (ISO 8601)" required: ["q", "from"] guardrails: - type: "output_filter" pattern: ".*@acmecorp\.com$" action: "block" reason: "Prevent leaking internal email addresses" - type: "tool_call_policy" allowed_tools: ["company_research", "news_search"] max_calls_per_session: 10这个 YAML 文件定义了 agent 的全部“契约”（Contract）：它的身份（system_prompt）、它能做什么（tools）、它不能做什么（guardrails）。最关键的是，tools的定义里，完全没有出现任何密钥。你只描述了工具的接口（URL、Method、Schema），而凭证的绑定、轮换、权限控制，全部交由 Anthropic 的后端服务完成。这带来了几个巨大的实操优势：
- 版本控制友好：YAML 是纯文本，可以像代码一样提交到 Git，进行 diff、review、roll back。你再也不用担心某个同事在服务器上改了一行 Python 代码，却没同步到文档里。
- 安全边界清晰：密钥的管理权从开发者手中，移交给了专业的安全团队。开发者只需要关心“我的 agent 需要什么能力”，而不用操心“我的密钥怎么保管”。
- 策略驱动：
guardrails部分定义了全局的安全策略。output_filter可以阻止特定模式的输出（比如内部邮箱、身份证号），tool_call_policy可以限制单次会话中对某个高危工具的最大调用次数。这些策略是集中管理、统一生效的，避免了在每个 agent 的 prompt 里重复写“不要泄露邮箱”这种低效且容易被绕过的指令。
3.2 启动与交互：awake()和execute()是你的新 API
部署好 YAML 后，你就可以通过 Anthropic 提供的 REST API 来与你的 agent 交互了。整个流程非常简洁，只有两个核心 endpoint：
POST /v1/agents/{agent_id}/sessions: 创建一个新的 session。你会得到一个唯一的session_id。POST /v1/sessions/{session_id}/messages: 向这个 session 发送用户消息。这是你与 agent 对话的主通道。
但真正的魔法，发生在messagesendpoint 的内部。当你发送一条消息，比如{"role": "user", "content": "Research Acme Corp"}，Anthropic 的 Harness 会做以下事情：
- 读取该
session_id对应的完整 event log（从第一条session_created开始）。 - 将 event log 的摘要（不是全部内容，而是经过优化的、模型友好的表示）和你的新消息，一起喂给 Claude 模型。
- 模型根据
system_prompt和当前状态，决定下一步动作。如果它需要调用工具，它会生成一个标准的tool_useblock，例如：{ "type": "tool_use", "id": "toolu_01abc123", "name": "company_research", "input": {"filters": {"identifier": "acmecorp.com"}} } - Harness 拦截这个
tool_useblock，不把它发给模型，而是根据name查找你在 YAML 中定义的company_research工具。 - Harness 向 Anthropic 的凭证服务申请一个临时令牌，并用这个令牌，结合
input，构造一个真实的 HTTP 请求，发送给 Crunchbase API。 - Crunchbase 返回结果后，Harness 将这个结果（
tool_result）连同tool_use的id，一起作为一个新的tool_resultevent，写入 session 的 event log。 - Harness 再次唤醒模型，这次喂给它的是更新后的 event log（包含了
tool_result），模型据此生成最终的用户回复。
整个过程对开发者是透明的。你只需要关心session_id和messages，剩下的所有状态管理、工具调用、凭证处理、日志记录，都由 Managed Agents 的基础设施代劳。这极大地降低了构建可靠 agent 应用的门槛。
3.3 定价与成本模型：$0.08/小时，是便宜还是陷阱？
Anthropic 的定价策略非常直白：$0.08 per session-hour of active runtime（每 session 小时 0.08 美元），外加标准的 Claude token 费用。这里的“active runtime”指的是 Harness 实例实际在执行任务的时间，不包括 session 等待用户输入的空闲时间。这听起来很便宜，但你需要用一个更精细的视角来审视它。
我们来做一个真实场景的成本模拟。假设你为一个拥有 500 名销售代表的团队部署了 Sales-Dev-Researcher agent。平均每个销售每天使用 10 次，每次交互平均耗时 90 秒（1.5 分钟）。
- 每天总 session 小时数 = 500 users * 10 sessions/user * 1.5 min/session / 60 min/hour =125 hours/day
- 每月（22 工作日）session 小时数 = 125 * 22 =2750 hours/month
- 每月 runtime 成本 = 2750 * $0.08 =$220
看起来微不足道。但请注意，这只是 runtime 的成本。你还需要支付 Claude 的 token 费用。假设每次交互平均消耗 15K tokens（输入+输出），Claude 3.5 Sonnet 的价格是 $3.00 / 1M tokens。
- 每天 token 消耗 = 500 * 10 * 15,000 = 75M tokens
- 每月 token 消耗 = 75M * 22 = 1.65B tokens
- 每月 token 成本 = 1.65B / 1M * $3.00 =$4,950
所以，总成本是 $220 + $4,950 =$5,170/月。其中，runtime 成本只占 4.2%，token 成本占了 95.8%。这印证了文章的核心论点：Managed Agents 的价值，不在于它卖 runtime，而在于它让 Claude 的 token 更好地被消费、被转化、被产生业务价值。$0.08/小时，本质上是一个极低的“入场券”价格，目的是让你把更多精力放在 agent 的业务逻辑（YAML 配置）和效果优化（prompt engineering）上，而不是在运维一堆沙箱容器上。
实操心得：在早期 PoC（概念验证）阶段，这个定价模型非常友好。但当你进入大规模推广时，务必建立详细的 cost-per-session 监控仪表盘。重点关注
p95 time-to-first-token（95% 的请求首字节时间）和avg_tokens_per_session（平均每 session token 消耗）。如果p95高于 2s，说明你的 agent 流程可能过于复杂，需要优化工具链；如果avg_tokens_per_session异常飙升，说明你的system_prompt或 guardrails 可能存在问题，导致模型在无效循环中浪费 token。
4. 竞争格局全景图：为什么说 Anthropic 是在“防守”，而非“开创”
4.1 AWS Bedrock AgentCore：那个被所有人忽略的“ incumbent”
当媒体都在报道 Anthropic 的“重磅发布”时，一个关键事实被集体忽略了：Amazon Bedrock AgentCore 已经在 2025 年底进入通用可用（GA）状态，并且到 2026 年 3 月，其 SDK 下载量已突破两百万次。这绝不是一个默默无闻的竞品，而是一个已经深度融入 AWS 生态、被数万家企业采用的成熟产品。
AgentCore 的架构哲学与 Managed Agents 高度相似，但实现路径更为激进。它不提供一个“托管的 Claude”，而是提供一个框架无关的、微虚拟机（microVM）驱动的通用 agent 运行时。每个 session 都在一个完全隔离的 Firecracker microVM 中运行，拥有独立的 CPU、内存和文件系统。这意味着，它不仅能运行 Claude，还能运行任何你能在 Bedrock 上调用的模型：Titan、Cohere、Meta 的 Llama，甚至是你自己微调的模型。它的 runtime 是开放的，SDK 是开源的，政策控制（Policy Controls）也已在 2026 年 3 月 GA。
更重要的是，它的商业模式是“免费即服务”（Free-as-a-Service）。AWS 不会单独为 AgentCore 的 runtime 收费。它被完全打包进了你的整体 AWS 账单里。你为 EC2、Lambda、S3、Bedrock inference 所支付的每一笔费用，都已经隐含了 AgentCore 的运行成本。对于一个已经在使用 AWS 的企业客户来说，启用 AgentCore 几乎是零边际成本的。他们不需要为一个新的“runtime 层”开一个新的采购流程，也不需要去说服 CFO 为一个“新类别”批预算。它就安静地躺在他们的现有云合同里，等待被激活。
这正是 Anthropic 所面临的残酷现实。当一个客户问：“我该用 Anthropic 的 Managed Agents，还是 AWS 的 AgentCore？” 答案往往不是技术优劣，而是采购便利性。如果客户的主要忠诚对象是 AWS（这在企业市场是常态），那么 Anthropic 的 Managed Agents 就天然处于一个“需要被说服”的劣势地位。它必须证明，自己提供的“Claude 锁定”体验，其价值远超 AWS 提供的“模型自由”和“零额外成本”。
4.2 其他巨头的布局：一场关于“AI 操作系统”的无声战争
AWS 并非孤例。整个科技巨头阵营，都在以惊人的速度，将 agent runtime 层“吸收”进自己的云平台，使其成为一种基础设施级别的能力：
- Google Vertex AI Agent Builder：它没有选择自建 runtime，而是巧妙地借力于其强大的 API 管理平台 Apigee。它提供了一个Agent Registry（代理注册中心），允许开发者将任何符合规范的 agent（无论用 LangChain 还是其他框架编写）注册进来，并通过 Apigee 统一进行流量管理、认证鉴权、速率限制和可观测性监控。Vertex 的策略是：不做 runtime，但要做 runtime 的“交通警察”和“城市规划局”。
- Microsoft Azure AI Foundry：微软采取了“生态整合”路线。它将开源社区中两大主流 agent 框架——AutoGen 和 Semantic Kernel——深度集成进其 Azure AI Foundry 平台。Foundry 不仅提供托管的 compute，还提供预置的、针对 Azure 服务（如 Azure OpenAI, Azure Cognitive Search）优化的工具集（Toolkits），以及与 Microsoft Graph、Teams、Power Platform 的原生连接器。它的目标是让开发者在 Azure 上构建 agent，就像在 Windows 上开发桌面应用一样自然。
这三巨头（AWS、GCP、Azure）的共同点是：它们都不试图定义“最好的 agent 框架”，而是致力于成为“所有 agent 框架的最佳运行平台”。它们的目标不是赢得“agent runtime”这个战役，而是赢得“AI 应用开发平台”这场战争。在这个战略下，runtime 层的价值被主动压低，因为它只是通往更高价值层（如 AI 应用市场、AI 治理、AI 观测）的必经之路和引流入口。
4.3 历史的镜像：VMware 与开源虚拟化的宿命
文章中引用的 VMware 类比，是理解当前局势最锋利的手术刀。让我们把时间拨回到 2005 年。那时，VMware ESX 是无可争议的王者，一个企业级 hypervisor 的许可费用高达数万美元。它构建了一个价值千亿美元的帝国。然而，历史的车轮滚滚向前：2003 年 Xen 诞生，2007 年 KVM 并入 Linux 内核。到了 2020 年代，开源 hypervisor 已经占据了新部署的 70% 以上。AWS、GCP、Azure 并没有去和 VMware 比拼 hypervisor 的性能，而是将虚拟化能力作为一项基础服务，免费（或近乎免费）地提供给所有云客户。结果是，hypervisor 本身从一个高利润的产品，变成了一个“隐形的、无感的”基础设施层。价值向上迁移了：Terraform（基础设施即代码）、Kubernetes（容器编排）、Service Mesh（服务网格）……这些才是新时代的财富密码。
今天的 agent runtime 层，正处于同样的历史拐点。Anthropic 的 Managed Agents，就像 2005 年的 VMware ESX，是一个高质量、高可靠、高易用的商业产品。但它所处的市场，已经同时存在 AWS AgentCore（相当于 AWS 的 EC2 虚拟化）、开源项目 Daytona（相当于 Xen/KVM）、以及 Kubernetes SIG 的官方 agent-sandbox 项目（相当于 K8s 对虚拟化的抽象）。历史的规律告诉我们，一个被多个巨头视为“基础设施”的技术层，其商品化（Commoditization）周期，通常在 18 到 24 个月内完成。当 runtime 的价格被压到 $0.001/小时，当它的启动时间被优化到 50ms，当它的安全策略被标准化为一个 YAML 文件，那么，围绕它构建的“runtime vendor”生意，就走到了尽头。
5. 未来十年的价值高地：不在 runtime，而在它的“上一层楼”
5.1 Trace Store：谁掌握了“AI 的行车记录仪”，谁就拥有了数字世界的“司法证据”
当 runtime 层变得像水电一样廉价和普遍，下一个必然爆发的战场，就是Trace Store（追踪存储）。你可以把它理解为 AI 时代的“行车记录仪”或“黑匣子”。它记录的不是车速和位置，而是 agent 的每一次思考、每一次决策、每一次行动。这份记录，其价值早已超越了简单的 debug 工具。
- 法律与合规：当一个金融 agent 自动生成了一份投资建议，并导致客户亏损，法庭上需要的不是“模型说它觉得这个股票会涨”，而是完整的、不可篡改的 event log：
[2026-04-05T10:02:15Z] user_query: "What's the outlook for TSLA?" -> [2026-04-05T10:02:18Z] tool_call: "market_data_api", input: {symbol: "TSLA"} -> [2026-04-05T10:02:22Z] tool_result: {price: 185.32, volume: 42e6} -> ... -> [2026-04-05T10:02:45Z] final_response: "Based on current data, TSLA shows strong momentum..."。这份 trace，是界定责任、证明尽职调查的关键法律证据。 - 模型评估与迭代：传统的模型 benchmark（如 MMLU, GSM8K）衡量的是静态能力。而 trace store 让你能够进行动态的、基于真实业务场景的评估。你可以问：“在所有‘生成销售邮件’的 task 中，agent 的
news_search工具调用成功率是多少？失败时，它是否正确地 fallback 到了company_research？” 这种 granular 的分析，是提升 agent 效果的黄金数据。 - 跨 runtime 迁移：当你的业务从 Anthropic Managed Agents 迁移到 AWS AgentCore，或者反之，最大的障碍不是代码，而是“历史数据”。一个成熟的 trace store 必须提供标准的 export/import 接口，确保你的 agent 行为数据不会被 vendor lock-in。
目前，这个领域已经形成了三足鼎立的格局：
- Braintrust：背靠 $36M Series A，其 Brainstore 数据库专为 AI logs 设计，支持复杂的 OLAP 分析。
- Arize：凭借 $131M 总融资，其开源项目 Phoenix（Apache 2.0 协议）正在快速建立社区标准，为商业产品铺路。
- LangSmith：作为 LangChain 生态的“亲儿子”，它拥有最庞大的天然用户群，其价值在于“开箱即用”的集成体验。
实操心得：在选型时，不要只看 dashboard 是否炫酷。要问三个问题：1）它的 event schema 是否开放、是否与 OpenTelemetry 兼容？2）它能否在不修改 agent 代码的前提下，接入任意 runtime（Anthropic, AWS, 自建）？3）它的数据导出功能是否支持完整的、带时间戳和签名的原始 event stream？如果答案是否定的，那么它很可能只是一个漂亮的“监控看板”，而不是一个真正的“系统记录”。
5.2 Governance & Policy：AI 的“交通法规”正在起草
随着 agent 渗透到企业的核心业务流程（销售、财务、HR、安全），一个全新的、前所未有的挑战出现了：如何定义、执行和审计 agent 的行为边界？这就是 Governance（治理）和 Policy（策略）层的价值所在。
AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls，就是一个标志性事件。它允许管理员定义规则，例如：“所有调用database_write工具的请求，必须经过 DBA 的审批”、“任何生成的代码，必须先通过 SonarQube 扫描，才能被提交到 Git”。OWASP 发布的《Agentic Top 10》安全风险清单，则为整个行业划定了安全红线。
这个领域的特点是：需求极度迫切，但工具极度匮乏。目前还没有一个公认的、企业级的“AI Policy Engine”。这为初创公司留下了巨大的空白。一个成功的治理平台，必须能回答以下问题：
- Who approved what?（谁批准了什么？）—— 需要与 Okta、Azure AD 等 IAM 系统深度集成。
- What was the audit trail?（审计轨迹是什么？）—— 需要与 Trace Store 无缝对接，形成“策略-执行-结果”的完整闭环。
- How do we enforce it?（如何强制执行？）—— 需要提供灵活的 hook 机制，能在 agent 调用工具前、生成响应后等关键节点，插入自定义的检查逻辑。
这是一个典型的“监管驱动型”市场。当企业采购部门开始在 RFP（招标书）中明确要求“必须支持 OWASP Agentic Top 10 合规性报告”时，这个市场就真正爆发了。
5.3 Vertical Agent Marketplaces：当 agent 变成“SaaS 2.0”
最后，也是最激动人心的一层，是Vertical Agent Marketplaces（垂直领域 agent 市场）。Salesforce 的 Agentforce 在 2026 年 Q4 达到 8 亿美元 ARR，同比增长 169%，这已经不是一个信号，而是一声号角。它宣告了一个新时代的到来：企业愿意为“解决一个具体业务问题”的 agent 付费，而不是为“运行 agent 的技术”付费。
这个逻辑，与 SaaS 的演进如出一辙。当年，企业不会为“一个能发邮件的 SMTP 服务器”付费，但会为 “Salesforce CRM”（一个能管理销售线索的 SaaS）付费。今天，企业不会为“一个能调用 API 的 runtime”付费，但会为 “Healthcare Claims Agent”（一个能自动处理医保理赔的 agent）付费。
开源社区已经敏锐地捕捉到了这一趋势：
virattt/ai-hedge-fund：一个专注于量化交易的开源 agent，能自动分析财报、新闻、市场情绪，并生成交易信号。vxcontrol/pentagi：一个用于渗透测试的 offensive security agent，能自主规划攻击路径、利用漏洞、并生成专业报告。
这些项目，就是未来垂直市场上的“种子选手”。资本已经闻风而动。谁能率先将这些开源项目，包装成符合企业采购习惯（SLA、SOC2 合规、专属支持）的商业产品，并建立起一个活跃的开发者生态（让 ISV 可以轻松为其添加新的数据源和工具），谁就能成为下一个 Salesforce 或 ServiceNow。
个人体会：作为一名在一线摸爬滚打多年的从业者，我越来越确信，未来十年 AI 领域最大的赢家，不会是那些在模型参数上卷到极致的公司，也不会是那些在 runtime 性能上锱铢必较的公司。最大的赢家，将是那些深刻理解某个垂直行业（医疗、金融、制造、教育）的业务流程、痛点和合规要求，并能将这些知识，封装成一个个开箱即用、效果可衡量、责任可追溯的 agent 的公司。技术是杠杆，但行业知识，才是支点。
