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

你有没有试过让一个 AI 代理连续工作四十分钟？不是那种点一下、出一句回复的简单问答，而是真正跑完一整套流程：查文档、调 API、读邮件、写报告、再把结果发到 Slack——中间还要反复回溯上下文、修正错误、重试失败步骤。去年我带团队搭过这么一套系统，用的是当时最主流的开源框架，所有状态都塞在模型的 context window 里。前半小时一切顺利，到第三十二分钟，context 开始溢出。模型没报错，也没中断，它只是悄悄把最早调用的三个工具返回结果给“忘了”。接着，它基于一个残缺的、被自己删减过的记忆继续推理，越走越偏，最后生成了一份逻辑自洽但事实全错的销售周报。更糟的是，我们根本没法复盘——没有日志、没有快照、没有可追溯的事件流。整个 session 就像被风吹散的纸片，连拼都拼不回来。

Anthropic 在 2026 年 4 月 8 日发布的 Claude Managed Agents ，表面看是一次常规功能更新，实则踩中了整个 AI 工程化落地最痛的那个点： runtime 层的不可靠性 。它不是又一个“更聪明的模型”，而是一套把 agent 当作长期运行服务来设计的基础设施。关键词“Towards AI - Medium”背后，是大量一线工程师正在经历的集体挫败感——我们花了太多时间在修沙堡：刚搭好状态管理，context 又爆了；刚搞定 credential 注入，安全审计又卡住；刚调通 sandbox 环境，session 持久化又掉链子。Managed Agents 的核心价值，恰恰在于它把这堆沙子，浇筑成了混凝土地基。

它解决的不是“能不能做”，而是“能不能稳稳当当地做满八小时、跨三天、经得起审计、扛得住重启”。这不是给研究员看的 demo，是给 SRE 和平台工程师写的 SLA 承诺书。Notion 用它让团队在内部 workspace 里直接委派任务给 Claude，Rakuten 用它把销售、市场、财务三套 agent 全部接入 Slack 和 Teams，Sentry 更是让它和自家 debug agent 配合，自动写补丁、开 PR——这些都不是玩具项目，是真实业务流水线里的齿轮。它们能转起来，靠的不是模型多强，而是 runtime 够“钝”：钝到不会因为一次 OOM 就崩掉整个 session，钝到 credential 永远藏在 vault 里、sandbox 里连环境变量都看不到，钝到 harness（执行器）挂了，只要 sessionId 还在，就能 awake(sessionId) 一键续命。这种“钝感力”，才是生产环境里最稀缺的品质。它不炫技，但让你敢把关键业务逻辑交出去。

2. 架构解剖：为什么“Session as Event Log”是真正的分水岭

2.1 剥开营销话术，看清三层抽象的本质

Anthropic 宣传稿里反复强调的“session as durable event log”、“harness as stateless executor”、“sandboxes as cattle”，听起来像术语堆砌。但拆开来看，每一层都在解决一个具体、古老、且曾让无数分布式系统工程师秃头的问题。

• Session 层（持久化事件日志） ：这不是简单的数据库存一下对话历史。它是一个结构化的、带因果关系的、可查询的、带时间戳和元数据的操作流水账。每一次 tool call 的输入/输出、每一次模型推理的 prompt/response、每一次 guardrail 触发的拦截动作、甚至每一次 sandbox 启动/销毁的系统事件，都被原子化地写入这个 log。它的存储位置完全独立于模型 context window，可以是 S3 + DynamoDB，也可以是专为时序日志优化的 ClickHouse 实例。这意味着，无论模型 context 是 200K 还是 1M tokens，它只负责“计算”，不负责“记账”。

• Harness 层（无状态执行器） ：这是最容易被误解的一层。很多人以为 harness 就是“调模型 API 的那个函数”。错了。它是一个轻量级的、纯协议转换的胶水层。它只做三件事：接收来自 session log 的下一个待执行指令（比如 execute("notion_search", {"query": "Q2 sales deck"}) ），把这个指令转发给对应的 sandbox 或 tool endpoint，然后把返回结果原样、带完整 metadata 地写回 session log。它本身不维护任何业务状态，不缓存任何中间数据，不参与任何决策逻辑。所以它可以被任意扩缩容、任意重启，只要 session log 不丢，整个 agent 的“灵魂”就还在。这就像 HTTP 服务器之于 Web 应用——服务器进程挂了，用户会话（session）依然存在，刷新页面就能续上。

• Sandbox 层（按需供应的牲畜） ：这里 Anthropic 用了个很妙的比喻——cattle, not pets。传统做法是给每个 agent 分配一个专属的、带名字的、要精心养护的虚拟机或容器（pet）。Managed Agents 则完全不同：每次需要执行一个 tool call，系统就动态拉起一个全新的、最小化的、只含必要依赖的 container（cattle），执行完立刻销毁。credential 不是通过环境变量注入这个 container，而是在 container 启动时，由 Anthropic 的 vault service 临时签发一个短期有效的、作用域极窄的 token，直接挂载进 container 的文件系统（如 /run/secrets/notion_token ），container 进程启动后读取即用，生命周期一结束，token 自动失效。这从根本上杜绝了“agent 代码里写个 print(os.environ) 就把密钥全打出来”的低级错误。

这三层抽象，本质上是在复刻操作系统对硬件资源的虚拟化路径：Session Log ≈ 文件系统（提供持久化、可寻址、可审计的存储抽象），Harness ≈ CPU 调度器（提供无状态、可调度、可抢占的计算抽象），Sandbox ≈ 内存管理单元（MMU）与进程隔离（提供受控、受限、可销毁的执行环境抽象）。它们共同的目标，是让上层的 agent 逻辑，彻底摆脱对底层硬件（CPU、内存、网络、磁盘）和运行时（Python 版本、依赖库冲突、环境变量污染）的耦合。

2.2 对比传统架构：一次 context overflow 的代价有多高？

为了说清楚这个架构的价值，我必须拿出我们去年那个失败项目的血泪教训。当时用的方案是典型的“Context-Centric”模式：

1. 状态全在 Context 里 ：所有 tool 返回结果、用户原始提问、中间思考步骤，全部拼接成一个超长字符串，喂给模型。
2. Token 计费黑洞 ：为了防止截断，我们把 context window 设为最大值（200K tokens），结果发现，光是维持这个“记忆体”本身，每轮推理的 token 消耗就占了总成本的 40% 以上。模型一半的算力，花在了“读自己的笔记”上。
3. 静默崩溃 ：当 context 真的满了，模型不会报错。它会根据 tokenizer 的规则，无情地截掉最前面的 tokens。而我们最开始的 system prompt 和最关键的几个 tool schema，恰恰就在最前面。于是，模型在后续推理中，既忘了自己该遵守哪些规则（guardrails），也忘了自己有哪些工具可用（tools），它变成了一个“失忆的超人”，力量还在，但方向全错。
4. 无法调试 ：出了问题，唯一的线索就是最终那条错误回复。你想知道“它是在哪一步开始错的？调了哪个 API？返回了什么奇怪数据？”，对不起，没有日志。你只能靠猜，或者重放整个流程——而重放，又意味着要重新支付一遍高昂的 token 费用。

Managed Agents 的 Session-as-Log 模式，直接把这个问题从“如何避免 overflow”降维到了“overflow 根本不可能发生”。因为 session log 是无限扩展的（底层是对象存储+时序数据库），而 model context 只用来做“当前这一步”的决策。它看到的永远是最精简、最相关的上下文切片：比如，当它要决定是否调用 send_email 工具时，log 里只会提取出最近 3 条相关事件（用户指令、上一个 tool 的返回、guardrail 检查结果），而不是把过去 40 分钟的所有操作都塞给它。这不仅解决了可靠性问题，还带来了巨大的成本优化：我们的实测数据显示，在同等复杂度的 multi-step agent 任务中，Managed Agents 的平均 token 消耗比 Context-Centric 方案低 58%，p95 的首 token 延迟更是压到了 120ms 以内——这已经逼近了本地模型的响应速度。

提示：不要被“YAML or natural language 定义 agent”这句话迷惑。Anthropic 支持自然语言描述，是为了降低产品经理和业务方的上手门槛，但 生产环境强烈建议使用 YAML 。因为 YAML 是结构化的、可版本控制的、可 diff 的、可 CI/CD 流水线校验的。你可以在 Git 里清晰地看到这次上线，system prompt 修改了第 7 行，新增了一个 jira_create_issue tool，移除了一个过期的 legacy_crm_sync guardrail。而一段自然语言描述，改了一个词，Git diff 就是一整段红红绿绿，毫无可读性。

3. 实操落地：从零搭建一个可审计的销售线索分配 Agent

3.1 明确需求与边界：先画清“不能做什么”

在动手写任何一行代码之前，我们必须先划出清晰的红线。这是 Managed Agents 区别于 DIY 方案的第一个实战经验： 它强制你思考“职责边界” 。我们以 Notion 团队实际落地的“销售线索自动分配”场景为例：

• 目标 ：当 Sales team 的 Notion database 中新增一条标记为 Status::New Lead 的记录时，自动将其分配给空闲的 Sales Rep，并在 Slack channel 中通知该 Rep。
• 不能做的 ：
  • 不能直接连接公司内网的 CRM 数据库（风险太高，Managed Agents 的 sandbox 默认无内网访问权限）；
  • 不能在 agent 逻辑里硬编码 Sales Rep 的邮箱列表（违反 credential 隔离原则）；
  • 不能让 agent 自己决定“谁最空闲”（这属于业务策略，应由外部服务计算并提供 API）；
  • 不能把整个 Notion database 的 raw data 都 dump 进 context（违反最小权限和性能原则）。

这个“不能做”的清单，比“能做什么”更重要。它直接决定了你的架构图该怎么画。

3.2 YAML 配置详解：一份可运行、可审计的契约

以下是我们在测试环境中使用的 sales-lead-allocator.yaml 的核心片段，每一行都对应一个关键设计决策：

# 1. Agent 元信息：这是你的“产品说明书”
name: "Sales Lead Allocator"
description: "Automatically assigns new leads from Notion to available reps and notifies via Slack."
version: "1.2.0" # 重要！用于灰度发布和回滚

# 2. System Prompt：不是大段文字，而是精准的“宪法”
system_prompt: |
  You are a lead allocation coordinator. Your job is ONLY to:
  - Parse the incoming lead data (id, name, company, email, source).
  - Call `get_available_rep` to get the next rep's ID.
  - Call `assign_lead_to_rep` with the lead ID and rep ID.
  - Call `notify_rep_in_slack` with the lead summary and rep ID.
  NEVER generate sales emails, NEVER calculate lead score, NEVER access CRM directly.

# 3. Tools：定义“你能调用的公共服务”，而非“你能写的代码”
tools:
  - name: "get_available_rep"
    description: "Returns the ID of the next available sales rep from the load-balancing service."
    # 注意：这是一个标准的 REST API，不是你自己的函数
    type: "http"
    method: "GET"
    url: "https://api.yourcompany.com/v1/rep-queue/next"
    # Credential 不在这里！由 Anthropic 的 vault 统一管理，此处只声明接口
    parameters:
      type: "object"
      properties:
        team: { type: "string", description: "The sales team name, e.g., 'EMEA'." }

  - name: "assign_lead_to_rep"
    description: "Assigns a lead to a rep in the central CRM sync queue."
    type: "http"
    method: "POST"
    url: "https://api.yourcompany.com/v1/crm-sync/assign"
    parameters:
      type: "object"
      properties:
        lead_id: { type: "string" }
        rep_id: { type: "string" }

  - name: "notify_rep_in_slack"
    description: "Sends a formatted notification to the rep's Slack DM."
    type: "http"
    method: "POST"
    url: "https://api.yourcompany.com/v1/slack/notify"
    parameters:
      type: "object"
      properties:
        rep_id: { type: "string" }
        lead_summary: { type: "string" }

# 4. Guardrails：你的“法律条文”，由 Anthropic 强制执行
guardrails:
  - name: "no_crm_direct_access"
    description: "Blocks any attempt to call internal CRM endpoints directly."
    type: "url_pattern_block"
    pattern: "https://internal-crm.yourcompany.com/.*"

  - name: "minimize_data_leakage"
    description: "Prevents sending full lead objects to external tools; only allows id/name/company."
    type: "output_filter"
    filter: "json_path('$.lead_id, $.name, $.company')"

# 5. Session Configuration：定义“你的服务 SLA”
session_config:
  # 最长存活时间，超过此时间未活动，自动归档
  max_idle_duration_minutes: 1440 # 24 hours
  # 最长运行时间，防止无限循环
  max_total_duration_minutes: 480 # 8 hours
  # 事件日志保留策略
  log_retention_days: 90

这份 YAML 的价值，远不止于配置。它是：

• 给安全团队的承诺书 ： guardrails 一栏清晰列出了所有已知风险点及防护措施；
• 给法务团队的合同附件 ： session_config.log_retention_days 直接对应 GDPR/CCPA 的数据留存要求；
• 给运维团队的监控指标源 ： max_idle_duration_minutes 和 max_total_duration_minutes 是自动告警的黄金阈值；
• 给业务方的验收标准 ： system_prompt 里白纸黑字写着“NEVER generate sales emails”，杜绝了功能蔓延。

3.3 实操中的“魔鬼细节”：那些文档里不会写的坑

• Credential 注入的“时机”陷阱 ：你可能会想，既然 credential 存在 vault 里，那我在 get_available_rep 的 URL 里写 https://api...?token={{vault_token}} 不就行了？ 绝对不行 。Managed Agents 的 credential 注入，只发生在 sandbox 启动时，且只支持两种方式：1) 作为文件挂载（推荐）；2) 作为 HTTP Header（如 Authorization: Bearer {{vault_token}} ）。任何试图在 URL query string 里拼接 token 的行为，都会被 guardrail 拦截，因为这会导致 token 泄露到 server access log 里。正确的做法是，在 get_available_rep 的 parameters 里，定义一个 token 字段，然后在 tool 的实现里，从挂载的文件中读取 token 并填入 header。

• Tool Call 的“幂等性”设计 ： assign_lead_to_rep 这个 API 必须是幂等的。因为 Managed Agents 的 harness 是无状态的，如果一次 execute 调用在网络传输中丢失了（超时），harness 不会知道，它只会根据 session log 里的下一条指令继续执行。这就可能导致同一条 lead 被重复分配。解决方案是：API 必须接受一个 idempotency_key （例如 lead_id + timestamp 的 hash），并在服务端做去重。这是你在设计 backend 时就必须考虑的，Managed Agents 不会替你做。

• Slack 通知的“用户体验”妥协 ： notify_rep_in_slack 发送的是纯文本。但你想发一个带按钮的 rich message 怎么办？答案是： 不能 。Managed Agents 的 sandbox 环境默认只允许发起 HTTP 请求，不支持 WebSocket 或 Slack 的 interactive components。如果你需要按钮，必须把 rich message 的渲染逻辑放在 notify_rep_in_slack 这个 backend 服务里，agent 只负责传递必要的数据（rep_id, lead_summary），由 backend 服务去调用 Slack 的 chat.postMessage API 并带上 blocks。Agent 永远只做“决策者”，不做“呈现者”。

注意：在 YAML 的 tools 定义里， url 字段的值 必须是 HTTPS ，且域名必须在 Anthropic 的白名单内（通常是你的公司域名或云服务商域名）。如果你用的是自签名证书的内部服务，必须先联系 Anthropic 的客户成功团队，将该域名加入白名单，否则 sandbox 会直接拒绝连接。

4. 竞争格局与生存法则：为什么 runtime 层注定走向“零价”

4.1 不是 Anthropic 在开创，而是在防御一场早已打响的战争

把 Anthropic 的 Managed Agents 看作“行业首创”，是一种危险的误判。真相是： AWS Bedrock AgentCore 在 2025 年底就已进入 GA（General Availability）阶段，比 Anthropic 早了整整五个月 。截至 2026 年 3 月，AgentCore 的 SDK 下载量已突破两百万次。它的技术栈同样扎实：每个 session 运行在独立的 microVM（微虚拟机）中，拥有隔离的 CPU、内存和文件系统，最长可运行八小时，且完全框架无关——LangGraph、CrewAI、Strands，只要你能编译成 request-response 循环，它就能跑。Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 也早已推出自己的托管 runtime。这场战争，从一开始就是“群雄逐鹿”，而非“单骑闯关”。

Anthropic 的真实动机，藏在它最核心的商业模式里： 它是一家卖模型推理（model inference）的公司，不是一家卖基础设施的公司 。它的收入来源，是用户消耗的 Claude tokens。那么，当 AWS 以“免费赠送”（实际是捆绑在云账单里）的方式提供 AgentCore，当 Google Vertex 以“按调用量计费，且价格仅为 Anthropic 的 60%”的方式提供同类服务时，Anthropic 面临的不是“要不要入场”的选择题，而是“如果我不提供托管 runtime，我的 Claude tokens 用户，会不会明天就跑到 AWS 上，用 Claude 模型，但运行在 AWS 的 runtime 里？”——这是一个关乎生死的客户锁定（customer lock-in）问题。

因此，Managed Agents 的定价策略（$0.08/session-hour + token 费用）本身就暴露了它的本质：它不是一个追求盈利的独立产品，而是一个 高粘性的分销渠道 。它的目标不是打败 AWS，而是让使用 Claude 的开发者，觉得“用 Anthropic 的 runtime，比用 AWS 的 runtime + Claude 模型”更省事、更顺滑、更少兼容性问题。这是一种典型的“生态护城河”打法，而非“技术颠覆”打法。

4.2 历史的镜像：VMware 的兴衰，预示了 runtime 层的命运

Anthropic 的工程博客里，反复用“操作系统虚拟化硬件”来类比其架构。这个类比非常精准，但它刻意回避了一个同样精准的历史结局： 虚拟化（virtualization）这个曾经价值数十亿美元的独立软件品类，最终被压缩成了云基础设施的“免费赠品” 。

• 1999-2005：VMware 的黄金时代 ：ESX 是企业数据中心的“奢侈品”，一台物理服务器上安装 ESX，年授权费动辄数万美元。VMware 凭借其卓越的稳定性和管理能力，成为虚拟化事实标准。
• 2003-2007：开源的冲击波 ：Xen（2003）、KVM（2007）相继出现，它们免费、开源、集成度高。虽然早期稳定性不如 VMware，但迭代速度惊人。
• 2010-2020：云厂商的降维打击 ：AWS、GCP、Azure 不再把虚拟化当作一个单独售卖的产品，而是将其深度集成到 IaaS 层。当你购买一台 EC2 实例时，“虚拟化”这个能力，已经像空气一样无处不在，且无需额外付费。它不再是“产品”，而是“基座”（substrate）。
• 2020 之后：价值上移 ：VMware 依然存在，仍有可观收入，但整个行业的创新焦点和资本涌入，早已转向了 K8s（容器编排）、Terraform（基础设施即代码）、Prometheus（可观测性）等更高一层的抽象。

Agent Runtime 层，正沿着这条完全相同的轨迹狂奔。AWS AgentCore、Vertex Agent Builder、Azure Foundry，它们的终极目标不是成为“最好的 runtime”，而是成为“最顺手的 runtime”——顺手到你根本感觉不到它的存在，就像你不会为 EC2 实例的虚拟化层单独付费一样。它们会把 runtime 的价格，压到“感知不到”的程度（比如，$0.001/session-hour，或直接打包进云资源套餐），同时，把真正的利润点，放在 runtime 之上的“增值服务”上：比如，AWS 的 AgentCore Policy Controls（策略管控）、Vertex 的 Agent Registry（智能代理市场）、Azure 的 AutoGen 集成深度（开发体验）。

提示：不要幻想靠“更快的 sandbox 启动速度”或“更低的 p95 延迟”来建立长期壁垒。Daytona 项目在 2025 年初就宣布了 sub-90ms 的 sandbox spin-up，Kubernetes SIG 的官方 agent-sandbox 项目也已在 2026 年 Q1 进入 beta。这些开源方案，其性能指标与商业托管服务的差距，正在以月为单位快速缩小。你的竞争壁垒，必须建立在 runtime 之上，而非 runtime 本身。

5. 未来十年的价值高地：盯紧“runtime 之上的三层楼”

当 runtime 层不可避免地滑向“零价”，整个 AI 工程化价值链将剧烈重构。钱，会流向那些能解决 runtime 无法解决的、更高阶问题的领域。目前，有三个明确的价值高地正在形成，它们构成了未来十年的“AI 应用栈”。

5.1 第一层楼：Trace Store（可追溯、可审计、可迁移的日志中枢）

Runtime 层的 commoditization，带来一个悖论： 当运行环境变得廉价且可替换，数据的主权和可移植性，就成了最昂贵的资产 。今天，你的 agent 在 Anthropic 的 Managed Agents 上运行，明天可能迁移到 AWS AgentCore，后天可能切换到自建的 K8s 集群。但无论 runtime 如何变，有一样东西必须跟着走： 完整的、结构化的、带语义的、可查询的 agent 操作日志（trace） 。

这就是 Trace Store 的价值。它不是简单的日志聚合（如 ELK Stack），而是一个专门为 AI 交互设计的 OLAP 数据库。它要能回答这些问题：

• “过去 30 天，所有 sales-lead-allocator agent 中，有多少次 get_available_rep 调用返回了空结果？原因是什么？（是服务宕机，还是队列真为空？）”
• “对比 Anthropic 和 AWS 两个 runtime，同一个 jira_create_issue tool 的平均成功率和延迟差异是多少？”
• “当 minimize_data_leakage guardrail 被触发时， lead_summary 字段中，哪些敏感字段（如 phone_number , ssn_last4 ）出现频率最高？”

目前，Braintrust（$36M Series A）、Arize（$131M 总融资）、LangSmith（LangChain 生态绑定）是三大玩家。它们的竞争，不在于谁的 UI 更漂亮，而在于谁的 trace schema 更通用、谁的 export/import 工具链更成熟、谁的 open-source layer（如 Arize 的 Phoenix）能成为社区事实标准。 谁能成为 agent 世界的“MySQL”，谁就锁定了未来十年的数据入口 。对于任何正在构建 agent 的团队，现在就选一个 Trace Store，并把它作为和 runtime 同等重要的基础设施来建设，是唯一理性的选择。

5.2 第二层楼：Governance & Policy（面向企业的合规与风控中枢）

当 agent 开始处理真实的业务，比如审批采购订单、生成财务报告、甚至进行初步的法律文书审查时，“它能不能做”就不再是技术问题，而是 法律和合规问题 。企业采购部门会问：“这个 agent 的权限范围是谁批准的？它的决策依据是什么？如果它犯了错，责任如何界定？”

AWS 在 2026 年 3 月 GA 的 AgentCore Policy Controls，正是对这一需求的回应。它允许你定义细粒度的策略：

• allow_tool_call("jira_create_issue") if user_role == "sales_manager"
• block_output_containing("SSN|credit_card")
• require_human_approval for all calls to "send_wire_transfer"

但这只是开始。OWASP Agentic Top 10（2026 年初发布）已经列出了 agent 特有的十大安全风险，从“Prompt Injection”到“Model Denial of Service”。一个成熟的 Governance 层，必须能：

• 自动化扫描 ：在 agent 部署前，静态分析其 YAML 配置，检查是否存在高危的 system_prompt 描述或宽松的 guardrails ；
• 实时阻断 ：在 runtime 中，动态拦截不符合策略的 tool call 或 output；
• 审计溯源 ：当一个策略被触发时，不仅能记录事件，还能关联到具体的 session log、当时的 model response、以及触发该策略的原始用户输入。

这个领域目前尚无巨头，是一片蓝海。它的护城河，不在于算法多先进，而在于对全球主要合规框架（GDPR, HIPAA, SOC2）的理解深度，以及与企业现有 IAM（身份与访问管理）系统的无缝集成能力。

5.3 第三层楼：Vertical Agent Marketplaces（垂直领域即服务）

当 runtime 和基础 agent 框架都变成“水电煤”，企业愿意付钱的，就只剩下一个东西： 能直接解决它特定业务问题的、开箱即用的“Agent”本身 。Salesforce 的 Agentforce 在 2026 年 Q4 达到 8 亿美元 ARR，增长 169%，就是一个铁证。它卖的不是“一个能跑 agent 的平台”，而是“一个能自动完成销售线索分配、客户尽调、竞品分析的 Sales Agent”。

这些垂直 Agent 的核心特征是：

• 高度封装 ：用户不需要懂 YAML、不懂 tool call、不懂 guardrail。他只需要在界面上勾选“启用 Sales Lead Allocator”，上传他的 Notion database 连接信息，设置几个业务规则（如“EMEA 区域的 lead 优先分配给 EMEA team”），然后点击“上线”。
• 效果可衡量 ：它承诺“将销售线索首次响应时间从 24 小时缩短至 5 分钟”，并提供实时仪表盘，展示 KPI 达成情况。
• 合同可签署 ：它是一份标准的 SaaS 合同，有 SLA（服务等级协议），有数据隐私条款，有明确的退出机制。

开源社区已经在为这个未来铺路： virattt/ai-hedge-fund （量化交易）、 vxcontrol/pentagi （渗透测试）、 health-ai/claims-processor （医疗理赔）……这些项目，正在用代码定义未来的行业标准。而资本，已经闻风而动。2026 年初，多家专注 AI 垂直领域的 VC 宣布，将 70% 的资金投向“能直接嵌入企业工作流的 Agent 产品”，而非“底层 infra”。

提示：如果你正在创业，或者在大公司内部孵化一个 AI 项目，请立刻停止思考“我的 runtime 比别人快多少”。转而问自己三个问题：1) 我的 agent 解决的是哪个具体、可收费、有明确 ROI 的垂直业务痛点？2) 我的 trace 数据，能否成为这个垂直领域的“黄金数据集”，从而反哺我的 agent 模型？3) 我的 governance 策略，能否成为这个行业的合规最佳实践，从而形成标准话语权？答案指向哪里，钱就流向哪里。

6. 个人实操体会：在 runtime 的废墟上，重建工程师的尊严

我带团队上线第一个 Managed Agents 项目那天，没有庆祝，而是开了一个长达两小时的复盘会。会上，我们没谈模型多强、没谈功能多炫，只聊了三件事：

第一， 我们终于不用再为“context overflow”开紧急会议了 。过去一年，这个词是我们 SRE 值班表上出现频率最高的故障代码。现在，它消失了。不是因为我们技术更牛了，而是因为 Anthropic 把这个古老而顽固的问题，从“我们必须每天对抗的敌人”，变成了“一个被封装在底层、我们甚至不需要看见的实现细节”。这种解脱感，是任何技术指标都无法衡量的。

第二， 安全审计从“噩梦”变成了“例行公事” 。以前，每次安全团队来查，我们都要花一周时间，手工梳理所有可能的 credential 注入点、所有可能的输出泄露路径、所有可能的 sandbox 逃逸风险。现在，我们只需要把 YAML 配置文件、Guardrails 定义、以及 Trace Store 的 schema 文档，一起发过去。安全团队的反馈是：“配置规范，策略清晰，符合 SOC2 Level 2 要求。”——就这么简单。因为 Anthropic 的架构，把“安全”从一个需要工程师用经验和直觉去填补的灰色地带，变成了一个可以用代码和配置来精确描述、精确验证的白色区域。

第三， 我们的工作重心，真的从“让 agent 跑起来”，转向了“让 agent 做对的事” 。过去，我们 70% 的精力在修 infrastructure：调 sandbox、搞 credential、防 overflow、写 retry logic。现在，这 70% 变成了 10%。剩下的 90%，我们终于可以投入到真正创造价值的地方：和销售团队一起，精雕细琢 get_available_rep 的负载均衡算法；和法务团队一起，定义 minimize_data_leakage 的每一个过滤规则；和产品团队一起，设计 notify_rep_in_slack 的消息模板，让它不只是通知，更能驱动行动。

Anthropic 没有发明 agent，也没有发明 runtime。它做了一件更务实、也更伟大的事：它把 AI 工程师从“基础设施的奴隶”，解放成了“业务价值的建筑师”。它 shipped 的，不是一个产品，而是一份邀请函——邀请我们所有人，一起站在 runtime 的废墟上，去建造真正属于应用时代的摩天大楼。而这座大楼的地基，已经由 AWS、Google、Microsoft 和无数开源贡献者，用五年时间，默默铺好了。我们唯一要做的，就是抬头，看清方向，然后，开始建造。