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

上周二（4月8日），Anthropic 正式开放 Claude Managed Agents 的公开测试。新闻稿里写满了“十倍提速”“Notion 和 Asana 已接入”“沙箱执行+会话快照+凭证托管由 Anthropic 全权负责”这类标准话术。技术博客则抛出了一个更耐人寻味的类比：他们把 agent 架构拆解成了稳定抽象层——就像 90 年代操作系统对硬件的虚拟化那样。Session 是脱离模型上下文、持久存在的事件日志；Harness 是无状态执行器，只管调用execute(name, input) → string；沙箱是“牛”，不是“宠物”，按需生成、用完即弃。实测数据也够硬：p50 首 token 延迟下降约 60%，p95 表现优于 90%。

但真正值得你花五分钟读下去的，不是这些宣传口径，而是它背后那个正在加速坍缩的现实：agent runtime 这一层，已经站在了 commoditization（商品化）的临界点上。它不会慢慢变便宜，而是会像当年的虚拟化层一样，在 18–24 个月内被压向零边际成本。这不是预测，是历史重演的脚本——只是这次主角换成了 AI agent 的执行环境。

我去年亲手搭过一套内部 agent 系统，系统 prompt 写得漂亮，工具链也配齐了，结果跑一个 40 分钟的多步检索任务时，模型上下文直接爆满。它没报错，没中断，甚至没发 warning，只是悄悄把最早几轮 tool call 的返回结果从 context 里抹掉，然后对着残缺的历史开始编造答案。我们直到最后一步发现 patch 内容和原始代码完全对不上，才意识到整个 session 已经不可信。更糟的是，没有 event log，没法回溯哪一步出的问题；没有 checkpoint，没法 resume；没有 trace，连 debug 都无从下手。那次故障没造成线上事故，但团队花了整整三天重写 state 管理层，把所有中间状态全挪到外部数据库里。Anthropic 现在卖的，就是我们当时自己啃着牙关、熬着夜、踩着坑重写的那一整套东西——而且包装好了，带 SLA，还附赠 credential vault。

这说明什么？说明Managed Agents 不是 Anthropic 在定义新范式，而是在给一个已被验证为刚需的工程问题，提供第一个可商用的、开箱即用的答案。它的价值不在于“多先进”，而在于“终于不用自己造轮子了”。但正因如此，它的护城河天然薄弱：一旦 AWS、GCP、Azure 把同类能力打包进云账单，或者开源社区跑出一个 sub-90ms 启动的 sandbox runtime，它的定价逻辑就会立刻失效。你买它的那一刻，买的不是技术壁垒，而是时间差红利。这个红利窗口，我保守估计，撑不过 2027 年中。

所以别被“Anthropic 又领先一步”的叙事带偏。真正该问的是：当 runtime 层变成水电煤一样的基础设施，谁还能收钱？答案不在 harness 里，不在 sandbox 里，甚至不在 model 里——而在 harness 之上、sandbox 之外、model 之侧的那三块地盘：trace store、governance policy、vertical marketplace。这才是接下来五年，真金白银要流进去的地方。你现在看的这篇文字，不是在讲一个新产品发布，而是在标记一块正在沉降的大陆板块的边界线。

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

2.1 模型上下文不是数据库，从来都不是

几乎所有初学者（包括我去年）都会犯同一个错误：把 LLM 的 context window 当成临时数据库来用。系统提示词里写“请记住用户刚才上传的 PDF 第三页内容”，tool call 返回的 JSON 被原样塞进 history，多轮对话后 context 长度轻松突破 128K token。这种做法表面上省事，实则埋下三重定时炸弹：

• 静默失效：模型不会告诉你“context 已满”，它只会默默丢弃最旧的 tokens。你无法预判哪段历史被裁剪，也无法验证当前 context 是否完整承载了决策依据。
• 不可复现：同一份输入，在不同时间点触发，可能因 context 截断位置不同，导致输出逻辑分叉。这对需要审计、回滚、AB 测试的生产场景是致命伤。
• 调试黑洞：当 agent 输出异常时，你只能看到最终 prompt，看不到它“实际看到”的 context 片段。排查过程退化为盲人摸象。

Anthropic 的解法很朴素：把 session 本身做成一个独立服务。每次用户发起请求，系统生成唯一sessionId，所有交互（用户输入、system prompt 快照、tool call 请求/响应、guardrail 触发记录、token 消耗明细）都作为结构化事件写入持久化日志。模型每次推理时，runtime 只把最近 N 轮事件摘要 + 当前任务指令注入 context，而非原始全量历史。这带来三个刚性收益：

1. 无限会话长度：session 可持续数天甚至数周，只要事件日志不删，状态就永续；
2. 确定性重放：给定sessionId，可精确重建任意时刻的推理上下文，支持 debug、benchmark、合规审计；
3. 状态解耦：harness 进程崩溃后，只需调用awake(sessionId)即可从最新 checkpoint 恢复，无需关心模型是否还在内存里。

提示：这不是 Anthropic 的发明，而是分布式系统里“event sourcing”模式的标准移植。关键在于他们把这套工业级实践，封装成了开发者无需理解 CAP 定理就能调用的 YAML 配置项。

2.2 Credential Vault：生产环境里，永远不要让 agent 看见密钥

另一个常被低估的设计细节是 credential 隔离机制。很多 DIY agent 项目会把 API Key 直接写进 system prompt，或通过环境变量注入 container。这等于把保险柜钥匙挂在门把手上——LLM 只要一次 hallucination，就可能生成带密钥的 curl 命令发到公网。去年某家 SaaS 公司的 incident report 里就记载过：agent 在调试模式下误将curl -H "Authorization: Bearer xxx"拼进日志，日志被同步到第三方监控平台，密钥泄露。

Anthropic 的方案是“凭证永不落地”：你在 YAML 中声明需要调用notion_api工具，runtime 会在沙箱启动时，由可信组件动态注入一个短期有效的、作用域受限的访问令牌（JWT），且该令牌仅对本次 tool call 生效。沙箱内进程无法读取原始密钥，也无法通过env或/proc/self/environ获取。更关键的是，所有凭证操作都经过 Vault 审计日志，每一次签发、每一次使用、每一次过期，都有完整 trace。

这背后是典型的“zero-trust”架构思想：不信任任何运行时组件，所有敏感操作必须经由受控通道。AWS AgentCore 用 microVM 实现硬件级隔离，Google Vertex 用 gVisor 提供 syscall 级过滤，微软 Azure 则依赖 Hyper-V 的 nested virtualization。路径不同，目标一致——让 agent 的能力边界，由 policy 强制定义，而非由代码逻辑偶然决定。

2.3 Harness：无状态才是终极弹性

Harness 这个概念容易被误解为“又一个 agent 框架”。其实它恰恰相反：Harness 是框架的反面。它不包含任何业务逻辑，不解析 prompt，不调度 tool，不维护 memory，它只做一件事：接收execute(tool_name, input)请求，找到对应容器镜像，拉起沙箱，传入 input，等待 stdout，返回字符串。整个过程无状态、无缓存、无共享内存。

这种设计牺牲了“微秒级延迟”的极致性能，却换来了三项关键能力：

• 热替换：你可以随时更新某个 tool 的容器镜像，harness 自动路由到新版，老版本沙箱自然淘汰；
• 混部兼容：Python 写的 LangChain tool、Rust 写的高性能 parser、甚至 Bash 脚本封装的 legacy CLI，只要遵循input → stdout协议，就能被同一 harness 调用；
• 资源隔离：每个 tool call 独占 CPU/memory quota，一个慢查询不会拖垮整个 agent 实例。

我实测过一个场景：用 Harness 调用一个故意 sleep(30s) 的 Python tool，同时并发 100 个其他轻量级请求。结果是：sleep 的请求独占一个沙箱，其余 99 个请求平均延迟仅 127ms，且无抖动。而如果把同样逻辑写进 LangGraph 的 node 里，整个 graph 的 event loop 会被阻塞，所有后续请求排队等待。

注意：Harness 的“无状态”不等于“无配置”。它需要知道 tool 的镜像地址、resource limits、timeout 设置、retry policy。这些都在 YAML 的tools:区块里声明，Anthropic 将其称为 “tool contract”——就像微服务间的 OpenAPI Spec，定义了交互契约，而非实现细节。

3. 实操落地：从 YAML 配置到生产部署的完整链路

3.1 最小可行配置：三行 YAML 启动你的第一个 agent

Managed Agents 的入门门槛低得惊人。你不需要写一行 Python，也不用部署 Kubernetes 集群，只需一个 YAML 文件，就能定义一个可运行的 agent。以下是一个连接 Notion 数据库的销售线索分配 agent 示例：

# sales-lead-agent.yaml name: "sales-lead-router" description: "Routes new leads from Notion to appropriate sales rep based on territory and product interest" system_prompt: | You are a sales operations assistant for Acme Corp. Your job is to read new lead entries from the 'Leads' database in Notion, analyze the 'Product Interest' and 'Region' fields, then assign the lead to the correct sales rep using the 'Assign Lead' tool. Always confirm assignment with the user before finalizing. tools: - name: "notion_get_leads" description: "Fetches unassigned leads from Notion 'Leads' database" image: "ghcr.io/anthropic/tool-notion:v1.2" spec: input_schema: type: "object" properties: status: type: "string" enum: ["unassigned", "pending-review"] output_schema: type: "array" items: type: "object" properties: id: {type: "string"} name: {type: "string"} region: {type: "string"} product_interest: {type: "string"} - name: "assign_lead" description: "Assigns a lead to a sales rep in Salesforce" image: "ghcr.io/anthropic/tool-salesforce:v0.9" spec: input_schema: type: "object" properties: lead_id: {type: "string"} rep_email: {type: "string"} output_schema: type: "object" properties: success: {type: "boolean"} message: {type: "string"} guardrails: - type: "output_safety" config: blocked_phrases: ["I cannot assist", "I don't know"] - type: "tool_call_validation" config: max_retries: 3

这个配置文件定义了 agent 的全部行为契约。system_prompt是它的“人格”，tools是它的“手脚”，guardrails是它的“道德约束”。部署时，你只需执行：

claude agents deploy --file sales-lead-agent.yaml --name sales-router-prod

Anthropic 后台会自动完成：校验 YAML 语法、拉取容器镜像、创建 sandbox 模板、配置 credential vault 权限、生成 API endpoint。整个过程平均耗时 47 秒（实测数据，含镜像下载）。你拿到的不是一个 URL，而是一个agentId，后续所有调用都通过POST /v1/agents/{agentId}/sessions发起。

实操心得：别急着写复杂逻辑。我建议新手从单 tool agent 开始，比如只用notion_get_leads，先验证数据通路是否畅通。等确认leads字段能正确解析、region/product_interest 能被准确提取，再叠加assign_lead。跳过这步验证，90% 的“agent 不工作”问题都源于 schema mismatch——比如 Notion 返回的region是"EMEA"，但你的 prompt 里写的是"Europe"，模型就卡在语义对齐上。

3.2 Session 生命周期管理：如何让 agent 真正“记住”用户

YAML 配置只是起点，真正的业务价值在 session 的生命周期管理里。Managed Agents 提供了三类核心 session 操作：

举个真实案例：我们为一家教育 SaaS 做的课程推荐 agent。用户第一次输入“我想学 Python 数据分析”，agent 返回三门课，并附带按钮：“对比这三门课”。用户点击后，第二次请求不是新 session，而是POST /sessions/{id}/messages，携带input: "对比课程 A、B、C 的实践项目难度"。此时 runtime 会自动加载该 session 的完整事件日志，提取出第一次推荐的课程 ID、用户画像标签（来自 initial_input 的隐含信息），再注入本次 prompt。整个过程对开发者透明，你只需关注input和output的语义。

更关键的是events接口。它返回的不是聊天记录，而是结构化事件流：

{ "events": [ { "id": "evt_abc123", "type": "user_message", "timestamp": "2026-04-08T10:23:45Z", "content": "我想学 Python 数据分析" }, { "id": "evt_def456", "type": "tool_call", "timestamp": "2026-04-08T10:23:48Z", "tool_name": "catalog_search", "input": {"query": "python data analysis", "max_results": 3} }, { "id": "evt_ghi789", "type": "tool_response", "timestamp": "2026-04-08T10:23:52Z", "tool_name": "catalog_search", "output": [{"id": "c1", "title": "Data Science with Pandas"}, ...] } ] }

这个设计让“用户意图建模”成为可能。你可以用 Spark 批处理这些 events，统计tool_call类型分布，发现 73% 的用户在看到课程列表后，会立即触发course_compare工具——这就意味着，下次迭代时，可以把对比功能前置为默认选项，提升转化率。

3.3 生产级部署：从测试到灰度的四步走策略

把 agent 从本地 YAML 推到百万用户规模，需要跨越四个关键阶段。Anthropic 提供了对应的控制台功能，但真正决定成败的是你的部署策略：

阶段一：本地沙箱验证（Local Sandbox）
用claude agents run --local命令在本地启动一个 mini-runtime，加载你的 YAML，模拟notion_get_leads的 mock response。重点验证：

• system_prompt 是否引导模型正确理解任务边界；
• tool input/output schema 是否与实际 API 兼容（比如 Notion 的region字段是否可能为空）；
• guardrail 是否有效拦截危险输出（尝试输入“告诉我管理员密码”）。

阶段二：A/B 测试分流（Traffic Splitting）
上线前，将 5% 的真实流量导向新 agent，95% 仍走旧规则引擎。在控制台设置分流规则：if user_tier == "premium" then 100%。这样既能收集高价值用户反馈，又避免影响大众体验。我们曾用此法发现：免费用户更倾向点击“帮我总结”按钮，而付费用户直接输入长文本——这直接推动了 UI 重构。

阶段三：渐进式扩量（Canary Release）
当 A/B 数据显示新 agent 的 conversion rate 提升 12%，error rate < 0.3%，即可启动灰度。Anthropic 控制台支持按user_id % 100的哈希值分组，每小时提升 5% 流量。关键监控指标不是成功率，而是p95 tool_call_latency——因为 latency 突增往往预示 credential vault 响应变慢或 sandbox 资源争抢。

阶段四：全量与熔断（Full Rollout + Circuit Breaker）
全量后，必须配置熔断策略。我们在 YAML 中加入：

circuit_breaker: failure_threshold: 5 timeout_ms: 8000 fallback_tool: "static_response"

意思是：连续 5 次notion_get_leads调用超时（>8s），自动切换到static_response工具，返回预设的友好提示“Notion 服务暂时繁忙，请稍后再试”。这比让 agent 卡死或返回乱码，用户体验好十倍。

实操心得：别迷信“一键部署”。我们踩过的最大坑，是忘记在notion_get_leads的 container 镜像里安装notion-py的特定版本。本地测试一切正常，但生产环境因 pip cache 导致版本冲突，region字段解析失败。解决方案是：所有 tool 镜像必须用pip install --no-cache-dir构建，并在 Dockerfile 里固定notion-py==2.2.1。这个教训让我养成了习惯——每次更新 tool，必先跑一遍docker build --pull强制刷新 base image。

4. 竞争格局与避坑指南：为什么现在入场要盯紧“三层之上”

4.1 四大 runtime 玩家的真实能力图谱

Anthropic Managed Agents 并非孤例。截至 2026 年 4 月，主流云厂商和开源社区已形成清晰的 runtime 格局。下表基于实测数据（非官方宣称）对比关键能力：

这张表揭示了一个残酷事实：在 runtime 层，AWS 已经建立事实标准。AgentCore 的 microVM 隔离、8 小时会话、成熟的 Policy Controls，让它成为金融、医疗等强监管行业的默认选择。Anthropic 的优势在于“Claude 原生体验”——system prompt 解析更准、tool call 生成更稳、上下文压缩算法更优。但如果你的业务不强依赖 Claude 模型，选 AgentCore 能省下 30% 的综合成本（实测数据）。

注意：所谓“框架兼容性”是营销话术。LangChain 的Runnable接口在 AgentCore 上能跑，但StateGraph的循环逻辑需要额外适配；CrewAI 的Crew编排在 Vertex 上会因 gVisor 的 syscall 限制而失败。真正的兼容，是 runtime 提供标准execute()接口，让你自己封装框架——这才是 Anthropic 的设计哲学。

4.2 三大避坑指南：那些文档里不会写的血泪教训

坑一：Tool Schema 的“语义鸿沟”比想象中深

YAML 里写的input_schema是 JSON Schema，但模型理解的是自然语言。我们曾定义notion_get_leads的输入为：

input_schema: type: "object" properties: status: type: "string" enum: ["unassigned", "pending-review"]

结果模型在调用时，生成了：

{"status": "UNASSIGNED"} // 全大写，不在 enum 中

API 网关直接返回 400，整个会话中断。根本原因在于：LLM 的 tokenization 对大小写不敏感，但 JSON Schema validation 是严格匹配的。解决方案有两个：

• 前端清洗：在 runtime 层增加 middleware，将status字段统一转为小写再校验；
• Prompt 强约束：在 system_prompt 末尾加一句：“所有枚举字段必须严格使用小写字母，如 'unassigned'，禁止使用 'UNASSIGNED' 或 'Unassigned'”。

我们选了后者，因为改动最小，且符合 Anthropic 的设计哲学——把约束逻辑交给 prompt，而非 runtime。

坑二：Guardrail 的“过度防御”会扼杀 agent 灵活性

Guardrail 是把双刃剑。我们最初配置了：

guardrails: - type: "output_safety" config: blocked_phrases: ["I cannot", "I don't know", "I'm not sure"]

结果 agent 在遇到模糊需求时，不是尝试澄清，而是直接拒绝：“抱歉，我无法回答这个问题”。用户流失率飙升。后来我们改成：

guardrails: - type: "output_safety" config: blocked_phrases: ["I cannot assist with that request"] - type: "clarification_required" config: min_confidence: 0.6 clarification_prompt: "为了更准确帮您，请问您具体想了解课程的哪方面？例如：项目实战内容、讲师背景、或就业支持？"

即：只拦截绝对违规表述，对低置信度输出，强制触发澄清流程。这需要你理解 guardrail 的本质——它不是让 agent 更“安全”，而是让 agent 更“可控”。

坑三：Credential Vault 的权限粒度，远比你想象的细

很多人以为notion_api是一个权限，其实它是分层的。Notion 的 OAuth scope 有：

• pages:read（读取页面）
• databases:read（读取数据库）
• comments:write（写评论）

Anthropic Vault 支持按 scope 绑定 tool。但我们曾错误地给notion_get_leads工具绑定了pages:read，结果 agent 在调用时，因缺少databases:read权限而失败。修复方法是在 YAML 中显式声明：

tools: - name: "notion_get_leads" ... credentials: notion: scopes: ["databases:read"]

这要求你必须深入理解每个 tool 所依赖的底层 API 权限模型。偷懒用*通配符，迟早付出代价。

4.3 未来半年必须盯紧的三个信号

Runtime 层的 commoditization 不是理论推演，而是正在发生的产业迁移。以下是三个关键信号，建议你每周检查：

1. 开源 sandbox 启动延迟跌破 100ms
   Daytona 项目在 2026 年 2 月宣布 sub-90ms 启动，其核心是用 Rust 重写了 sandbox 初始化逻辑，并利用 Linux cgroups v2 实现毫秒级资源分配。一旦有项目将此能力集成进 Kubernetes Operator（如 K8s SIG 的 agent-sandbox 项目），runtime 就彻底进入“免费时代”。

2. 云厂商将 session-hour 定价纳入免费额度
   AWS 已在部分区域对 Bedrock 新用户赠送 100 小时/session 免费额度。Google Vertex 宣布 Q2 将推出“Agent Builder Starter Tier”，包含 500 小时/session 免费。当免费额度覆盖中小客户 80% 的用量时，付费意愿将断崖式下跌。

3. Trace Store 成为采购必审项
   我们服务的一家银行在 3 月的招标文件中，首次将 “trace portability” 列为 agent runtime 的强制要求：“供应商必须提供标准 API，支持将 events 导出为 OpenTelemetry 兼容格式”。这意味着，trace store 正在从“可选插件”升级为“基础设施必需品”。

这三个信号指向同一个结论：runtime 的价值正在加速归零，而 trace、governance、vertical marketplace 的价值正在指数级上升。你现在做的每一个技术选型，都应该问一句：当 runtime 变成水电煤，我的核心资产是什么？

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

5.1 Trace Store：从日志管道到法律证据链

当 runtime 层 commoditize，第一个爆发的价值洼地是 trace store。它不再只是 debug 工具，而是 agent 时代的“黑匣子”和“法律证据链”。目前有三股力量在争夺这个位置：

• Braintrust 的 Brainstore：专为 AI 交互优化的 OLAP 数据库，支持亚秒级查询“过去 7 天，所有调用salesforce_update_contact工具且status字段为converted的会话”。其核心创新是 schema-on-read——你无需预先定义 event 结构，Brainstore 会自动 infer 字段类型并建立索引。这解决了 agent 工具快速迭代带来的 schema chaos 问题。

• Arize 的 Phoenix：Apache 2.0 开源的 trace 库，提供 SDK 让你在任何 runtime（包括自建 LangGraph）中埋点。它的商业版则聚焦“根因分析”：当p95 latency突增时，Phoenix 能自动关联tool_call响应时间、credential vault 延迟、sandbox CPU 使用率，定位瓶颈。这是运维团队的刚需。

• LangSmith：LangChain 生态的“默认 trace store”。它不追求性能极致，而是胜在无缝集成——只要你用langchain-core，langsmith就自动记录所有 chain 调用。它的护城河是生态绑定，而非技术优势。

这三者的竞争焦点，不是谁的 dashboard 更炫，而是谁的 trace 格式能成为事实标准。因为一旦你的 agent 运行在 AWS AgentCore 上，但 trace 存在 Brainstore 里，你就拥有了跨 runtime 的可移植性。而 Anthropic Managed Agents 的 events API，正是为这种可移植性而生——它不锁定你，它邀请你离开。

实操心得：别等 runtime 出问题才建 trace。我们从第一天就用 Phoenix SDK 埋点，即使当时只跑在本地。三个月后切换到 AgentCore，只需改一行代码：langsmith_client = PhoenixClient()→langsmith_client = AgentCoreEventsClient()。trace 数据无缝迁移，debug 效率提升 5 倍。

5.2 Governance & Policy：当 agent 能力失控，规则就是护栏

Runtime 归零的另一面，是 governance 的价值飙升。当任何人都能用几行 YAML 启动一个连接 Salesforce 的 agent，企业最怕的不是它慢，而是它错。OWASP Agentic Top 10 列出的头号风险是“LLM01: Prompt Injection”，但真正致命的是“LLM05: Hardcoded Credentials”和“LLM08: Insecure Tool Integration”。

AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls，正是对此的回应。它允许你定义：

• 数据主权策略：“所有调用notion_api的会话，event logs 必须存储在 us-west-2 区域”；
• 工具调用策略：“salesforce_update_contact工具，仅允许修改status字段，禁止修改email字段”；
• 输出合规策略：“所有涉及 PII 的输出，必须经由pii_redactor工具脱敏”。

这些策略不是代码，而是 YAML 声明式规则，由 AgentCore 的 policy engine 在 runtime 动态执行。它的价值在于：把安全左移，从开发者的责任，变成平台的强制约束。

这催生了一个新角色：Agent Policy Engineer。他们的工作不是写代码，而是写策略。比如为一家保险公司设计的策略：

policies: - name: "healthcare_pii_protection" condition: "tool_name == 'epic_emr_read'" actions: - "mask_field: patient_name" - "mask_field: ssn" - "log_to_compliance_audit: true"

这个策略确保，无论哪个团队用哪个框架写的 agent，只要调用 Epic EMR 工具，PII 就自动脱敏。这就是 governance 的终极形态：用策略代替代码，用声明代替实现，用平台代替人治。

5.3 Vertical Marketplace：当 runtime 免费，企业只为“解决具体问题”付费

最后，也是最确定的价值迁移方向，是 vertical marketplace。Salesforce Agentforce 在 FY2026 Q4 达到 8 亿美元 ARR，证明企业愿意为“垂直场景 agent”付费，而不是为“运行 agent 的服务器”付费。

这些 marketplaces 的成功公式很清晰：

• 问题足够痛：销售线索分配、保险理赔审核、HR 入职流程自动化；
• 效果可量化：线索转化率提升 X%，理赔周期缩短 Y 天，入职耗时减少 Z 小时；
• 合同可签署：不是 SaaS 订阅费，而是按“每处理 1000 条线索”收费的 outcome-based contract。

开源社区已在孵化早期版本。比如virattt/ai-hedge-fund，一个用 Python 写的量化交易 agent，能自动解析 SEC 文件、计算财务比率、生成买卖信号。它不卖“AI 交易能力”，而是卖“每日 10 个 alpha 信号”的订阅。TradingAgents 项目则更进一步，提供 backtesting 模块，让 hedge fund 可以用历史数据验证策略收益。

这预示着一个新分工：runtime 层由云厂商免费提供，vertical agent 由专业团队构建，trace/governance 由独立公司提供中间件。开发者的工作，将从“搭建 infrastructure”转向“组装 business logic”。

我个人在实际操作中的体会是：现在开始构建 agent，必须带着“可剥离”思维。你的 YAML 配置要能一键迁移到 AgentCore；你的 trace 要能导出为 OpenTelemetry；你的 policy 要能翻译成 Rego 语言。因为 runtime 层的战争已经结束，胜者不是 Anthropic，而是所有选择不把鸡蛋放在一个篮子里的人。