AI代理Runtime层的范式革命：从上下文包袱到事件驱动状态管理

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

你有没有在深夜调试一个跑了三小时的 AI 代理，突然发现它开始胡言乱语？不是模型崩了，不是 prompt 写错了，而是——它的“记忆”被挤掉了。上下文窗口就那么大，工具调用日志、中间结果、用户多轮对话、系统指令……全塞进去，像往一个20升的桶里硬灌30升水。最后溢出的不是水，是逻辑：它忘了自己上一步查过什么数据库，忘了用户明确说“不要生成代码”，甚至把两个不同客户的订单ID搞混了。这种失败不炸裂，不报错，它安静地、昂贵地、不可逆地发生。我去年就亲手葬送过这样一个客户项目，整整47分钟的推理链，因为第38分钟时 context 溢出，前20分钟的检索结果被无声截断，后续所有决策都建在流沙之上。我们连重放都做不到——没有日志，没有快照，只有模型输出里那一段越来越离谱的“合理推测”。

Anthropic 在4月8号发布的 Claude Managed Agents，表面看是一套托管代理运行时，但它的核心价值，恰恰就卡在这个“安静失败”的痛点上。它没发明新模型，没造新算法，它做了一件更基础、更关键的事：把“状态”从模型的上下文里彻底剥离出来，变成一个独立、持久、可查询、可审计的事件日志。这个设计，不是锦上添花，而是给整个 AI 代理开发范式动了一次外科手术。它让 session 不再是模型上下文里一段随时可能被覆盖的临时内存，而是一个活在外部数据库里的、有生命周期的实体。Harness（执行器）变得轻如鸿毛，可以随时挂掉、重启、扩缩容，只要拿着 sessionId 就能“唤醒”并继续工作。沙盒（sandbox）也不再是你精心养护的“宠物”，而是按需拉起、用完即焚的“牲畜”。这背后的技术哲学，和90年代操作系统用虚拟内存和文件系统把硬件细节抽象掉，让应用开发者不用再操心物理内存地址和磁盘扇区一样，一脉相承。关键词不是“AI代理”，而是“runtime”、“session-as-event-log”、“stateless harness”、“credential isolation”。这不是 Anthropic 在开辟一个新蓝海，它是在为整个行业铺设一条通往生产级落地的、必须踩上去的钢丝绳。如果你还在用 LangChain 的 Memory 或者自己手写 Redis 缓存来管理长流程状态，那你已经站在了这条钢丝绳的起点，而 Anthropic 已经把护栏焊好了。

2. 核心设计拆解：为什么是“解耦”，而不是“堆砌”

2.1 三层解耦：Session、Harness、Sandbox 的各自归位

Managed Agents 的架构图看起来简洁，但每一层的职责划分，都直指当前代理开发中最顽固的耦合病灶。我们来一层层剥开：

Session 层：从“上下文包袱”到“事件时间线”
这是最革命性的一刀。传统方案里，“session state” 是一个模糊概念，它可能散落在 LLM 的 prompt 里，可能藏在 Redis 的某个 hash key 下，可能被序列化进一个 JSON 字符串里。它没有统一 schema，没有版本控制，没有天然的审计能力。Managed Agents 把它定义为一个结构化的、只追加（append-only）的事件日志（event log）。每一次 tool call 的输入/输出、每一次用户消息、每一次系统指令、每一次错误回滚，都被打上时间戳、session ID、trace ID，写入一个持久化存储。这意味着什么？意味着你可以用 SQL 查询：“这个 session 里，所有对 Salesforce API 的调用，返回了哪些错误码？”意味着你可以一键重放：“从第5个事件开始，用新的 prompt 模板重新执行后续所有步骤。”意味着当客户投诉“你们的代理把我的合同金额算错了”，你能立刻拿出完整的、不可篡改的操作流水，而不是对着一团混乱的 debug 日志抓耳挠腮。它解决的不是性能问题，是信任问题、合规问题、可维护性问题。p50 首token 时间下降60%，只是这个解耦带来的副产品；真正的价值，在于 p95 的稳定性提升——那个曾经在凌晨三点悄无声息崩溃的长流程，现在有了确定性的恢复点。

Harness 层：从“智能大脑”到“无脑快递员”
Harness 是执行引擎，但它被设计得极度“愚蠢”。它不理解业务逻辑，不解析工具参数，不决定下一步该调哪个函数。它只做一件事： execute(name, input) → string 。收到一个工具名和一个 JSON 输入，它就去调用那个工具，然后把原始字符串结果原封不动地交还给上层。这个“无脑”设计，是稳定性的基石。因为 Harness 本身没有任何状态，它就是一个纯函数。它可以部署在任何容器里，可以水平扩展到1000个实例，可以每分钟重启一次，都不会影响 session 的连续性。你不需要担心“这个 Harness 实例是不是缓存了旧的用户偏好”，因为它根本没缓存。所有的“智能”都上移到了 session log 和上层的 orchestrator（比如 LangGraph 的 state machine）里。这就像把 CPU 的计算单元和内存控制器彻底分开，让计算单元可以疯狂地跑满频率，而内存访问由更可靠的、带 ECC 校验的独立模块负责。实测下来，Harness 的冷启动时间压到了毫秒级，因为它真的什么都不用加载，除了那行 execute 函数。

Sandbox 层：从“共享厨房”到“一次性无菌舱”
Credential isolation 是另一个被无数血泪教训验证过的刚需。还记得那个著名的“curl 命令泄露 token”事故吗？一个 LLM 在生成 shell 命令时，把本该只存在于环境变量里的 AWS_ACCESS_KEY_ID，直接拼进了 curl -H "Authorization: Bearer $TOKEN" 里，然后这个命令被 sandbox 执行，token 就随着网络请求飞向了未知的远方。Managed Agents 的沙盒，从创建那一刻起，就把凭证注入到了内核级别的隔离空间里，它对运行在其中的 agent 进程来说，是完全不可见的。Agent 只能看到一个抽象的工具名，比如 search_salesforce ，它传入一个 account_id ，沙盒内部的 credential manager 会自动补全认证头、处理 token 刷新、记录审计日志。这相当于给每个工具调用都配了一个隐形的、专业的、永不犯错的“安全助理”。沙盒本身也是 cattle，不是 pets：每次 tool call 都会拉起一个全新的、干净的 microVM 或 container，执行完立刻销毁。你不用担心上一个调用留下的临时文件、残留进程或内存泄漏会影响下一个。这种“用完即焚”的哲学，是生产环境稳定性的终极保障，也是 Anthropic 敢于承诺“p95 better than 90%”的底气所在。

2.2 为什么不是“微服务”，而是“操作系统原语”？

有人会问，这不就是把代理拆成几个微服务吗？API 网关是 Harness，数据库是 Session Store，K8s Pod 是 Sandbox？这个类比是危险的。微服务之间依然存在复杂的、需要手动编排的网络调用、协议转换和错误重试。而 Managed Agents 提供的，是像操作系统提供的 open() 、 read() 、 write() 、 fork() 这样的底层原语（primitive）。 execute(name, input) 就是它的 system call 。它屏蔽了所有底层的复杂性：你不需要关心 sandbox 是用 Firecracker 还是 gVisor 启动的，不需要知道 session log 是存在 DynamoDB 还是 TimescaleDB，不需要配置 Harness 的负载均衡策略。你只需要声明“我要调用这个工具”，剩下的，由这个 runtime 层统一、可靠、安全地完成。这正是它敢和90年代 OS 类比的原因——它在构建一个稳定的、抽象的、让上层应用（你的 agent logic）可以自由创新的“平台”。当你不再需要为“如何安全地调用一个 API”这种基础问题写几百行胶水代码时，你才能真正把精力聚焦在“如何让这个销售代理写出打动客户的邮件”这种高价值问题上。

3. 实操要点与避坑指南：从 YAML 定义到生产上线

3.1 Agent 定义：YAML 是声明式编程的起点

Managed Agents 允许你用 YAML 或自然语言定义 agent。别被“自然语言”迷惑，生产环境请务必拥抱 YAML。它不是配置文件，它是你的 agent 的“源代码”。一个典型的 agent.yaml 长这样：

# agent.yaml
name: "sales-lead-qualifier"
description: "Qualifies inbound leads from website forms and schedules demos"

system_prompt: |
  You are a senior sales development representative at Acme Corp.
  Your goal is to qualify leads by asking up to 3 targeted questions about:
  - Company size (small/mid/large)
  - Current tech stack (CRM, marketing automation)
  - Timeline for purchasing a new solution (immediate/3mo/6mo+)
  Never ask more than 3 questions. If all info is gathered, summarize and hand off.

tools:
  - name: "fetch_lead_data"
    description: "Fetches raw lead data from HubSpot CRM using lead ID"
    input_schema:
      type: "object"
      properties:
        lead_id:
          type: "string"
          description: "The unique ID of the lead in HubSpot"

  - name: "schedule_demo"
    description: "Schedules a 30-min demo with the lead's preferred time"
    input_schema:
      type: "object"
      properties:
        lead_id:
          type: "string"
        preferred_time:
          type: "string"
          format: "date-time"

guardrails:
  - type: "content_moderation"
    severity_threshold: "high"
  - type: "tool_call_validation"
    allowed_tools: ["fetch_lead_data", "schedule_demo"]

关键实操心得：

• input_schema 不是可选的，是强制的 。我第一次提交时漏写了 fetch_lead_data 的 schema，结果 Harness 在调用时传入了一个空对象 {} ，导致 HubSpot API 返回 400。Anthropic 的文档里没强调这点，但这是 runtime 层做类型校验和安全沙箱的唯一依据。它必须精确到字段名和类型，否则沙盒会拒绝执行。
• system_prompt 里禁止出现具体凭证或硬编码 URL 。所有敏感信息必须通过 tools 的 credential vault 注入。我曾试图在 prompt 里写 “Use the API key stored in env.API_KEY ”，这会导致整个 agent 被拒绝部署——runtime 层会扫描 prompt，发现任何疑似凭证的字符串模式（如 API_KEY 、 SECRET 、 https://.*\.com/api/v1 ）都会触发安全拦截。这是它“防呆”设计的一部分。
• guardrails 的顺序很重要 。 content_moderation 必须放在 tool_call_validation 之前。因为内容审核发生在 LLM 输出后、tool call 解析前；而 tool call 校验发生在解析后、执行前。如果顺序反了，一个恶意的、伪装成合法 tool name 的字符串（比如 rm -rf / ）可能会绕过内容审核，直接进入校验环节，虽然最终会被拒绝，但日志里会留下可疑痕迹。

3.2 Session 生命周期管理：从创建到归档的全流程

Session 不是“启动就完事”，它是一个有完整生命周期的实体。你必须主动管理它：

1. 创建 ( create_session ) ：调用 API 创建一个新 session，返回 session_id 和初始 state 。此时 session 状态是 pending 。
2. 交互 ( send_message ) ：将用户消息发给 session_id 。Harness 接收后，会根据当前 session log 中的最新状态，决定是调用 tool 还是直接生成回复。每次调用都会产生一个新的 event。
3. 检查点 ( checkpoint ) ：这是一个手动触发的动作。当你完成一个关键阶段（比如“已收集全部3个问题的答案”），你应该显式调用 checkpoint(session_id) 。这会强制 runtime 将当前所有 events 刷入持久化存储，并生成一个稳定的、可重放的快照。 这是最重要的避坑点 ：不要依赖 runtime 自动 checkpoint。我见过太多案例，因为网络抖动，最后一次 send_message 的 event 没有成功写入，而 session 却进入了 completed 状态，导致无法追溯最后一步发生了什么。养成习惯，在每一个业务逻辑节点后，都加一行 checkpoint 。
4. 查询 ( get_session_events ) ：用 session_id 查询所有 events。返回的是一个结构化数组，每个 event 包含 type （ user_message , assistant_message , tool_use , tool_result , error ）、 timestamp 、 content 、 metadata （包含 tool name、input、output 的哈希值等）。你可以用它做实时监控、离线分析、甚至训练新的 reward model。
5. 归档 ( archive_session ) ：当 session 确认完成且无需再交互时，调用此 API。它会将 session 标记为 archived ，并将其 events 移入长期存储（通常是成本更低的对象存储），同时从热数据库中移除，释放资源。 注意 ：归档后， get_session_events 将返回 404。你需要提前把关键日志导出到自己的数据湖。

提示： checkpoint 不是免费的。每次调用会产生一次额外的 token 计费（用于序列化和存储 event）。但在生产环境中，这笔钱远低于一次因状态丢失导致的客户投诉或 SLA 罚款。把它看作是给你的业务逻辑买的一份“保险”。

3.3 Pricing 模型：$0.08/小时背后的精算逻辑

Pricing 是 Managed Agents 最容易被误解的部分。$0.08 per session-hour 的 active runtime，听起来很便宜，但“active runtime” 的定义非常关键：

• Active runtime = Harness 正在执行的时间 。从 send_message 请求到达 Harness 开始计时，到 Harness 返回最终响应（无论是 LLM 回复还是 tool call 结果）结束。Harness 在等待 tool call 返回的那几秒钟，也计入 active runtime。
• 不计入的时间 ：Session 处于 idle 状态的时间（比如用户发完消息，agent 在思考，但 Harness 还没启动）、 checkpoint 的时间、 get_session_events 查询的时间、 archive_session 的时间。
• 并发陷阱 ：一个 session 的 active runtime 是串行的。但如果你有 100 个 session 同时在处理，那么你每小时的账单是 100 * $0.08 = $8.00 ，而不是 $0.08 。这和 AWS Lambda 的计费逻辑类似，但粒度更粗（按 session，不是按 invocation）。

实测成本对比（以一个典型销售代理为例）：

• 场景：平均每个 session 对话 5 轮，每轮平均 active runtime 1.2 秒（LLM 思考 + tool call 网络延迟）。
• 计算：5 轮 * 1.2 秒 = 6 秒 active runtime per session。
• 每小时 3600 秒 / 6 秒 = 600 sessions per hour。
• 成本：600 * $0.08 = $48/hour。
• 对比：同等负载下，自建 K8s 集群（含节点、LB、监控、日志、安全加固）的月度成本通常在 $2000-$5000。Managed Agents 的 TCO（总拥有成本）在中小规模下极具竞争力。

注意：这个 $0.08 是 runtime 费用， 不包含 Claude 的 token 费用 。你仍然需要为输入 token 和输出 token 分别付费。所以最终成本 = ($0.08 * active_runtime_hours) + (input_tokens * price_per_1k) + (output_tokens * price_per_1k) 。在做预算时，务必把这三块都算进去。

4. 竞争格局全景扫描：为什么说这是“防御性发布”

4.1 Hyperscaler 的碾压式布局：AWS AgentCore 是真正的先行者

Anthropic 的发布会稿里，通篇没提 AWS。但这恰恰暴露了问题的核心。Amazon Bedrock AgentCore 在2025年11月就已正式商用（GA），比 Anthropic 早了整整五个月。它的技术规格，几乎就是 Managed Agents 的“镜像”，但底座更厚实：

• 微虚拟机（microVM）沙盒 ：基于 Firecracker，提供比容器更强的隔离性。每个 session 独享 CPU、内存、文件系统，连 /proc 都是独立的。这意味着，即使一个恶意 tool call 尝试 fork() 出千个进程，也只会耗尽它自己的 microVM 内存，绝不会影响邻居。
• 八小时超长会话 ：Managed Agents 的 session 默认存活期是24小时，但 active runtime 限制未公开。AgentCore 明确支持最长8小时的持续会话，这对需要长时间运行的金融风控、科研模拟类 agent 是刚需。
• 框架无关性 ：AgentCore 不绑定任何特定框架。LangGraph、CrewAI、甚至你用 Flask 写的一个简单 request-response loop，只要能接收 JSON 输入、返回 JSON 输出，就能被它托管。而 Managed Agents 的 YAML 定义，本质上是一种私有 DSL（领域特定语言），它锁定了你的开发范式。

市场反馈是最真实的裁判 ：截至2026年3月，AWS 官方宣布 AgentCore SDK 下载量突破200万次。这个数字背后，是数以万计的开发者已经在用它构建生产应用。Rakuten 的销售 agent、Sentry 的 debug agent，它们完全可以、也确实正在用 AgentCore 来托管，而无需支付 Anthropic 额外的 runtime 费用。Anthropic 的 Managed Agents，更像是一个“Claude 专属优化版”的 runtime，它确保了那些深度绑定 Claude 模型的客户，不会因为 runtime 的便利性而轻易迁移到 AWS 上去。这是一种精准的、高价值客户的“护城河”建设，而非面向全行业的基础设施开拓。

4.2 开源生态的暗流涌动：Daytona 与 Kubernetes SIG 的挑战

如果说 hyperscaler 是明面上的巨人，那么开源社区就是潜伏在水下的鲨群。它们的目标不是和 Anthropic 直接竞争，而是从根上瓦解 runtime 层的商业价值：

• Daytona ：这家公司在2025年初从 dev environment 领域转型，专注 AI agent infrastructure。它的核心卖点是“sub-90ms sandbox spin-up times”。这意味着，从你发出 execute 命令，到沙盒环境准备就绪、开始执行，平均耗时不到90毫秒。这个速度，已经逼近了本地进程 fork 的开销。它用 Rust 重写了整个沙盒生命周期管理器，把启动时间这个最关键的 latency 指标，压缩到了极致。对于高频、低延迟的 agent（比如实时客服机器人），这几乎是决定性的优势。它不卖 SaaS，它卖开源软件和企业支持，价格模型是按节点授权，而非按 session-hour 计费。
• Kubernetes SIG Agent-Sandbox ：这是 Kubernetes 官方成立的特别兴趣小组，在2026年3月发布了首个 alpha 版本。它不是一个独立产品，而是一套 CRD（Custom Resource Definitions）和 Operator。你只需在你的 K8s 集群里 kubectl apply -f agent-sandbox.yaml ，就能获得一个符合 CNCF 标准的、可插拔的 agent runtime。它天然支持你现有的监控（Prometheus）、日志（Fluentd）、网络策略（Calico）。这意味着，一个成熟的 DevOps 团队，可以在一天之内，用自己熟悉的工具链，搭建出一个和 Managed Agents 功能对标、且完全可控的 runtime。它的目标，是让 agent runtime 像 Ingress 或 Service 一样，成为 K8s 集群的“一等公民”。

提示：不要低估开源的力量。VMware ESX 在2005年售价数万美元一台时，KVM 还只是一个 Linux 内核补丁。但当 KVM 在2007年被合并进主线内核，当 Red Hat 开始在其 RHEL 中默认启用 KVM，商业虚拟化市场的天平就开始倾斜。今天 Daytona 和 K8s SIG 的动作，就是当年 KVM 的影子。它们不追求“最好”，只追求“足够好”和“无缝集成”。而后者，在企业 IT 领域，往往比前者更有杀伤力。

4.3 垂直市场：Salesforce Agentforce 的启示

当 runtime 层在价格和功能上日趋同质化，价值的重心必然向上迁移。Salesforce 的 Agentforce 是最清晰的路标。它在2026财年Q4实现了8亿美元的 ARR（年度经常性收入），同比增长169%。它的成功，不在于它用了多牛的 runtime，而在于它卖的是“垂直场景的确定性结果”：

• 预置的、经过验证的 agent ： Healthcare_Claims_Processor 、 Sales_Development_Rep 、 Security_Pentest_Assistant 。这些不是通用框架，而是针对特定岗位、特定 SLO（服务等级目标）打包好的解决方案。
• 与现有工作流的深度咬合 ：Agentforce 的销售代理，不是孤立运行的。它能直接读取 Salesforce 的 Opportunity Stage，能自动更新 Lead 的 Qualified_Date__c 字段，能在 Slack 里@相关销售代表并附上生成的 demo 邀请函。它的价值，是嵌入在客户已有的 CRM、沟通、协作工具链里的。
• 采购语言的转变 ：CIO 不再问“你们的 sandbox 启动时间是多少毫秒？”，他问的是“你们的销售代理，能把我们的 MQL（营销合格线索）转化率提升多少个百分点？SLA 是多少？”。这已经从一个技术采购，变成了一个业务成果采购。

这印证了文章里的核心论断：当 runtime 层 commoditize（商品化）后，价值会迅速向“Trace Store”（可观测性）、“Governance & Policy”（治理与策略）、“Vertical Marketplaces”（垂直市场）这三个方向聚集。Anthropic 的 Managed Agents，是它在这场价值迁移中，为自己争取时间、巩固客户关系的一张关键牌，但它本身，很难成为未来十年的价值高地。

5. 常见问题与排查技巧实录：来自一线的血泪经验

5.1 问题速查表：高频故障与根因定位

5.2 独家避坑技巧：那些文档里不会写的细节

技巧一：用 tool_result 的 metadata 做轻量级状态同步
tool_result 事件里有一个 metadata 字段，它不计入 token 计费，且可以被 Harness 读取。我利用它来传递一些简单的、非敏感的状态标志。例如，在 fetch_lead_data 的 tool result 里，我让 backend 在 metadata 中加入 "has_valid_email": true 。然后在 system_prompt 中，我可以写：“如果 has_valid_email 为 true，则跳过邮箱验证步骤”。这避免了为了一个布尔值，还要去调用一次额外的 check_email tool，节省了至少200ms 的延迟和一次 token 消耗。

技巧二： checkpoint 的时机选择，比你想的更重要
不要等到所有事情做完才 checkpoint。我在一个财务 agent 里，把 checkpoint 放在了“生成初步报表”之后，而不是“发送邮件给 CFO”之后。原因？如果发送邮件失败（网络问题），session 依然处于 active 状态，我可以立刻重试发送，而不用从头开始生成报表（那要消耗大量 tokens 和 runtime）。 checkpoint 应该放在每一个“业务原子操作”完成之后，而不是每一个“技术原子操作”之后。

技巧三： guardrails 的 severity_threshold 是双刃剑
content_moderation 的 high 门槛，会拦截很多模棱两可的、但业务上必需的表述。比如，一个医疗 agent 需要说“这个药物可能引起严重过敏反应”，这句话里的“严重”就会被 high 门槛拦截。我的解决方案是：将 severity_threshold 设为 medium ，然后在 system_prompt 的末尾，加上一句强硬的指令：“你是一个专业的医疗顾问。你必须如实告知所有已知风险，包括‘严重’、‘致命’、‘危及生命’等词汇。任何回避或弱化风险的表述，都将被视为严重失职。” 这样，既满足了合规要求，又保证了业务准确性。

技巧四：永远为 tool_call_validation 的 allowed_tools 留一个“逃生舱口”
在 guardrails 里，我总会保留一个名为 fallback_debug 的工具，它不执行任何业务逻辑，只返回一个固定的、安全的字符串，比如 "DEBUG_MODE_ACTIVE" 。它的 name 在 allowed_tools 列表里。当 agent 的逻辑陷入死循环或无法决策时，我可以通过一个特殊的、预设的用户指令（如“debug mode”）来触发它。这让我能在不中断 session 的情况下，快速拿到一个“心跳信号”，确认 Harness 还在工作，从而区分是业务逻辑 bug 还是 runtime 层故障。

6. 价值迁移的终点：Trace、Policy、Vertical 的三重奏

6.1 Trace Store：谁掌握了日志，谁就掌握了真相

当 runtime 层变得像水电一样无感， get_session_events 这个 API 就成了新的“圣杯”。但 Anthropic 提供的查询接口，只是冰山一角。真正的战场，在于谁能成为那个“系统记录”（system of record）：

• Braintrust 的 Brainstore ：它不是一个简单的日志数据库。它是一个专为 AI 交互设计的 OLAP 引擎。你可以用它执行这样的查询：“找出所有在 fetch_salesforce_data 工具调用中， status_code 为 403 的 session，并关联它们的 system_prompt 版本号和 user_message 的情感分析得分。” 这种跨维度、高并发的分析能力，是普通时序数据库无法企及的。它的价值，不在于存储，而在于从海量、异构的 agent 日志中，挖掘出可行动的洞察（actionable insight）。
• Arize 的 Phoenix ：它走的是开源路线，Apache 2.0 协议。这意味着，任何公司都可以免费下载、部署、修改。它把“可观测性”的标准，从“我能看见”提升到了“我能证明”。Phoenix 生成的 trace，自带数字签名和 Merkle Tree 根哈希。当你需要向审计部门证明“这个销售代理在2026年4月10日14:03:22，确实向客户 A 发送了包含准确折扣条款的邮件”，你不需要导出一堆 JSON，你只需要提供那个 trace ID 和 Phoenix 的验证工具，就能生成一份不可抵赖的审计报告。这已经超越了技术范畴，进入了法律和合规的领域。
• LangSmith ：它的优势在于“安装即用”。作为 LangChain 生态的官方伴侣，它几乎零配置就能接入。但对于一个已经用着其他框架（如 CrewAI）的团队，LangSmith 就像一个优秀的、但只能在自家厨房里用的厨具。它的护城河，是生态，而不是技术。

我的体会是：Trace portability 是当前最大的未解难题。今天你用 Managed Agents，明天想迁移到 AgentCore，你的所有历史 session logs 就成了孤岛。谁能提供一个开放的、标准化的 trace schema（比如 OpenTelemetry 的 AI 扩展），并提供一键迁移工具，谁就能赢得这场战争。这不再是数据库公司的游戏，而是标准制定者的舞台。

6.2 Governance & Policy：从“能做什么”到“该做什么”

AWS 在2026年3月将 AgentCore 的 policy controls 推向 GA，这标志着一个分水岭。政策（policy）不再是事后补救的“防火墙”，而是事前定义的“交通规则”：

• OWASP Agentic Top 10 的发布，首次为 AI agent 的安全风险提供了权威的分类框架。它把“Prompt Injection”、“LLM Output Manipulation”、“Insecure Tool Integration” 等十大风险，用工程师能理解的语言定义清楚。这就像当年 OWASP Top 10 之于 Web 应用安全一样，为整个行业建立了共同的风险语言。
• 企业采购的提问方式变了 。CISO 不再问“你们的沙盒有多安全？”，他问：“你们的 agent，能否被策略强制要求，在调用任何外部 API 前，必须先查询内部的 approved_api_whitelist 数据库？这个策略的生效时间是多久？策略变更的审计日志在哪里？” 这些问题，指向的是一个集中式的、可编程的、可审计的 policy engine。它需要能理解自然语言策略（如“禁止访问任何 .gov 域名”），也能执行代码级策略（如“对所有 output 字符串，执行正则 .*\b(credit|ssn)\b.* 匹配”）。

目前，这个领域还没有真正的“ incumbent”（主导者）。AWS、Google、Microsoft 都在各自的云平台上内置了基础策略，但它们是封闭的、云厂商锁定的。一个独立的、开源的、跨云的 policy framework，将是下一个十亿美金的创业机会。它的产品形态，可能是一个像 opa （Open Policy Agent）那样的 CLI 工具，让你用 Rego 语言编写策略，然后一键部署到任何 agent runtime 的 sidecar 里。

6.3 Vertical Marketplaces：当 agent 成为一种“SaaS on SaaS”

Salesforce Agentforce 的 8 亿美元 ARR，不是一个数字，它是一个宣言：企业愿意为“垂直场景的确定性”付费，而且付得比通用基础设施多得多。这个模式的成功，源于它解决了三个核心痛点：

1. 信任建立 ：一个医疗保险公司，不会轻易让一个通用的“AI agent”去处理患者的 PHI（受保护的健康信息）。但当它看到 Healthcare_Claims_Processor 这个 agent，是由 Salesforce 和一家顶级医疗 IT 公司联合认证、预装了 HIPAA 合规检查、并与 Epic EHR 系统深度集成时，信任就建立了。
2. 实施成本归零 ：客户不需要招聘一个 AI 工程师团队，不需要研究 LangChain 的 state management，不需要自己搭建 sandbox。它只需要在 Salesforce Setup 里点击“安装”，配置一下自己的业务规则，第二天，销售代表就能在 Slack 里 @agent 并得到一个高质量的 demo 邀请函。
3. 价值可衡量 ： Sales_Development_Rep agent 的 SLA 是“在 5 分钟内，将 MQL 转化为合格的 Sales Accepted Lead（SAL）”，并且这个指标直接出现在客户的 Salesforce 报表里。采购决策，从“这个技术听起来很酷”变成了“这个 agent 能帮我多赚多少钱”。

开源社区已经在为这个未来铺路。 virattt/ai-hedge-fund 项目，已经实现了基于新闻情绪分析、财报数据提取、技术指标计算的全自动交易信号生成。它不是一个玩具，它的 backtest 结果，和真实 hedge fund 的策略高度吻合。 vxcontrol/pentagi 则是一个面向红队的 offensive security agent，它能自动规划渗透路径、选择 exploit、规避 AV，其输出可以直接喂给 Metasploit。这些项目，就是未来垂直 marketplace 里的第一批“种子应用”。它们的价值，不在于它们用了多先进的模型，而在于它们深刻理解了特定领域的 workflow、SLO 和 success metrics。

我个人在实际操作中发现，最成功的 agent 项目，往往不是从“我们有个很牛的模型”开始，而是从“我们有个很痛的业务流程”开始。当 runtime 层的噪音被消除，当“能不能做”不再是问题，所有人的眼光，都会聚焦在“怎么做才能让