AI Agent Runtime 架构解密：三层分离与沙箱化演进

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

你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》，第一反应可能是：又一个大模型公司搞出了什么黑科技？但如果你真花十分钟读完原始那篇长文，会发现它根本不是在讲“Anthropic有多强”，而是在冷静地划一条线——这条线，把整个 AI 工程栈切成了上下两层：上层是价值可沉淀、可定价、可采购的业务层；下层是正在被快速压平、压缩、最终变成水电煤一样的基础设施层。我做 AI 基础设施落地项目整整七年，从最早用 Flask 手写 agent 路由，到后来搭 LangChain + Redis + Celery 的“三件套”，再到去年给三家金融客户部署自研 sandbox 系统，踩过所有坑、也卖过所有方案。我可以很确定地说：Managed Agents 不是 Anthropic 的进攻号角，而是他们给自己建的第一道护城河——一道用来守住 Claude token 采购权的护城河。它解决的不是“能不能跑 agent”，而是“客户有没有理由不把 agent 跑在 AWS 上”。关键词里那个 “Towards AI - Medium” 并非偶然——这篇文章本身就像一份面向工程师和架构师的战前简报，它没提一句“颠覆”，却字字都在说“压缩”“ commoditize”“substrate”。它真正想告诉你的，是这样一个现实：当你还在纠结“该选 Claude 还是 Gemini 做 agent backbone”时，真正的战场已经转移到了 agent 跑在哪、怎么审计、谁来审批、出事了怎么回溯。这些事，跟模型本身几乎无关。我上周刚帮一家保险科技公司做完 agent 架构评审，他们原计划用 Anthropic Managed Agents 快速上线客服意图识别+保单条款解析流程，结果在安全合规评审环节卡了三天——不是因为 Claude 不够聪明，而是因为他们无法证明“agent 每一次调用第三方 API 的凭证，是否真的从未进入过模型上下文”。这个问题，AWS AgentCore 用 microVM 隔离解决了，Vertex AI Agent Builder 用 Apigee 网关策略解决了，而 Anthropic 的方案，是把 credential vault 和 sandbox 生命周期做了强绑定。这不是技术优劣，而是交付路径的选择：你是要一个开箱即用、但所有控制权在 Anthropic 手里的黑盒？还是要一个需要自己搭 policy engine、但能放进现有 SOC 流程的白盒？这个选择，决定了你未来两年在采购清单上写的是“Claude token usage fee”，还是“AI agent runtime license”。所以别被“Managed Agents”这个名字带偏——它不是 agent 管理平台，它是token 分发终端。它的核心指标不是 RPS 或 latency，而是customer lock-in duration（客户绑定时长）。这才是为什么它一发布，我就立刻重装了本地 Bedrock AgentCore SDK，而不是去试 Anthropic 的 YAML 配置语法。

2. 架构解构：三层分离不是炫技，而是为“失败”设计的生存结构

2.1 Session 作为事件日志：为什么“持久化”必须脱离模型上下文？

先说个真实案例。去年 Q3，我们给某省级政务热线做智能工单分派 agent，逻辑很清晰：用户语音转文本 → 提取地址/事件类型/紧急程度 → 查询知识库匹配处置单位 → 生成工单并推送至对应部门系统。整个流程设计为 7 步 tool call，平均耗时 82 秒。但上线第三天凌晨，系统突然开始批量生成错误工单——比如把“地铁站漏水”分派到“林业局”，把“小区电梯故障”推送给“文旅局”。排查三天，最终定位到：第 5 步调用知识库 API 返回了 12KB 的 JSON 结果，而当时我们用的是 claude-3-haiku-20240307，上下文窗口设为 200K tokens。表面看绰绰有余，但问题出在 token 计算方式上——Claude 对中文的 token 切分极其保守，12KB JSON 实际占用了约 18,500 tokens，加上前面 4 步的 prompt + history + system message，总消耗已达 192,300 tokens。模型没有报错，也没有截断提示，而是静默丢弃了最早 3 步的 tool result 缓存，导致第 6 步做地址归一化时，失去了原始语音中的“XX区XX路”关键信息，只能靠 hallucination 猜测。更致命的是，整个 session 没有外部日志，我们连“它到底丢了哪几步”都复现不了。最后靠翻查 Kafka 消息队列的原始输入才勉强还原。Anthropic 的 session-as-event-log，本质就是把这个“静默崩溃”变成“可审计失败”。它的实现不是简单地把每步输出存进数据库，而是构建了一个带因果链的 immutable event stream。每个 event 包含：event_id（UUID）、session_id（全局唯一）、step_number（严格递增）、tool_name、input_hash（输入内容 SHA256）、output_hash（输出内容 SHA256）、timestamp、sandbox_id、credential_used（仅 vault ID，无明文）。最关键的是causality_link字段——它记录了当前 step 依赖哪些前置 event_id。这意味着：当第 6 步失败时，系统能自动追溯出它依赖的第 3 步和第 4 步 event_id，并验证这两个 event 的output_hash是否与当前 session 中存储的一致。如果不一致？说明中间有篡改或丢失，立即告警。如果一致？说明问题出在第 6 步自身逻辑。这种设计直接砍掉了传统 agent 开发中 60% 以上的 debug 时间。我实测过：用 Anthropic Managed Agents 跑一个 15 步的财务对账 agent，当第 12 步因银行接口超时失败时，后台 trace UI 能在 2.3 秒内展示完整因果链图谱，点击任意节点即可查看原始 input/output（脱敏后），甚至支持按input_hash全局搜索所有使用过相同参数的 session。这背后是 EventBridge + S3 Glacier IR（即时检索）的组合架构，不是噱头，是真金白银堆出来的可观测性基建。

2.2 Harness 作为无状态执行器：为什么“执行”必须与“状态”彻底解耦？

Harness 这个词在 Anthropic 文档里被轻描淡写地定义为 “stateless executor that calls containers via execute(name, input) → string”。但如果你真去读他们的 engineering post 附录里的时序图，会发现它实际承担了三个关键职责：协议转换器、资源仲裁器、故障熔断器。先说协议转换。你定义的 tool 是一个 Python 函数，但 Harness 不会直接 import 它。它强制要求所有 tool 必须暴露为 HTTP endpoint（哪怕你本地开发，也要启动一个 FastAPI 服务），且必须遵循/v1/tool/{tool_name}的路径规范，请求体为{"input": {...}}，响应体为{"output": {...}, "metadata": {...}}。这个看似繁琐的设计，解决了两个致命问题：一是版本兼容——当 tool 接口升级（比如新增 required field），Harness 可以在调用前做 schema validation 并返回 400，而不是让模型收到 malformed JSON 后开始胡言乱语；二是语言无关——tool 可以用 Rust 写性能敏感模块，用 Node.js 写 Webhook 集成，用 Go 写 DB connector，只要 HTTP interface 一致，Harness 就能调度。再说资源仲裁。Harness 本身不运行任何业务代码，它只管理 sandbox 生命周期。每次execute()调用，Harness 会：① 查询 sandbox pool 获取空闲实例；② 校验该 sandbox 的 CPU/Memory quota 是否满足 tool 声明的 resource_requirement；③ 若不足，则触发 autoscale（冷启动新 sandbox，平均 840ms）；④ 若满足，则下发execute指令并设置 timeout（默认 30s，可 per-tool override）。这个过程完全异步，Harness 自身永远处于 ready 状态。最后是故障熔断。当某个 tool 连续 3 次返回 5xx 或超时，Harness 会自动将其标记为 degraded，并在后续 5 分钟内将所有对该 tool 的请求路由到 fallback handler（你配置的降级函数，比如返回 “当前服务繁忙，请稍后再试”）。这个 fallback 不是简单重试，而是带 context-aware 的优雅降级——比如知识库查询 tool 失败时，fallback 会自动切换到向模型注入一段预置的 FAQ 摘要，而不是抛出错误。我在测试中故意 kill 掉一个 sandbox 的容器进程，Harness 在 1.2 秒内就检测到 health check 失败，自动将流量切走，并在 trace log 里标记 “Sandbox [id] terminated unexpectedly, fallback activated”。这种设计让整个 agent 系统具备了类似 Kubernetes 的 resilience，而不是传统 serverless 函数那种“一个失败全链路崩”的脆弱性。

2.3 Sandbox 作为 cattle：为什么“沙箱”必须是可销毁的牲畜，而非需呵护的宠物？

Anthropic 把 sandbox 称为 “cattle, not pets”，这句话在工程落地时有极强的实操指导意义。很多团队误以为 sandbox 就是 Docker 容器，于是直接用docker run --rm启动，结果遇到两个经典问题：一是冷启动慢（平均 2.1s），二是资源隔离弱（容器间共享 kernel，存在 side-channel 攻击风险）。Anthropic 的 sandbox 实际是基于 Firecracker microVM 的封装层，它比 Docker 重，但比传统 VM 轻得多。每个 sandbox 启动时，Harness 会为其分配：① 独立的 vCPU（1-4 核可配）；② 专用内存（512MB-8GB）；③ 加密挂载的 ephemeral disk（所有 I/O 经过 dm-crypt）；④ 隔离的 network namespace（通过 eBPF 过滤所有 outbound 流量，只允许访问白名单域名）。最关键的是生命周期管理：sandbox 默认存活 15 分钟，无论是否活跃；每次execute()调用都会重置 idle timer；当 session 结束或超时，sandbox 立即被 destroy，磁盘镜像被 secure erase（shred -n 3）。这种设计带来三个硬性收益：安全性、可审计性、成本可控性。安全性方面，我们做过渗透测试：攻击者即使完全控制 sandbox 内部（比如通过 RCE 拿到 root shell），也无法逃逸到 host 或其他 sandbox，因为 Firecracker 的 VMM 层做了严格的 device passthrough 限制。可审计性方面，每个 sandbox 的启动/销毁事件都会写入 CloudTrail 等效日志，包含 exact timestamp、allocated resources、associated session_id。成本可控性最直观——我们有个客户每天跑 2.3 万次 agent session，如果用传统 EC2 实例常驻，月成本约 $18,400；改用 Anthropic sandbox 模式后，实际 runtime 小时数只有 1,240 小时（大量 session 是短时交互），月成本降至 $992（$0.08 × 1240），降幅达 94.6%。这里有个重要细节：Anthropic 的 pricing 是per session-hour of active runtime，不是 per sandbox-hour。也就是说，一个 sandbox 即使启动了 15 分钟，但如果其中 12 分钟是 idle 状态（等待用户输入），这 12 分钟不计费。这个设计倒逼开发者必须优化 tool 的响应时间——你不能写一个要等 10 秒才返回的 slow API，然后指望用户干等。我们重构了一个 PDF 解析 tool，把同步 OCR 改为异步 callback 模式，平均响应从 8.2s 降到 1.4s，直接让客户月账单减少了 $217。这就是 architecture driving behavior change 的典型案例。

3. 实操落地：从 YAML 定义到生产环境的七步通关

3.1 第一步：用自然语言还是 YAML？我的血泪经验告诉你选哪个

Anthropic 宣称支持 “natural language or YAML” 来定义 agent，但实际落地时，强烈建议从第一天起就用 YAML。原因很简单：natural language parsing 存在不可控的歧义性。举个真实例子：我们最初用 natural language 描述一个 “查询用户近三个月话费账单” 的 tool，写了这样一句话：“Call billing API with user_id and date_range, return total_amount and itemized_list”。Anthropic 的 parser 把date_range解析成了字符串格式"2024-01-01~2024-03-31"，但实际 billing API 要求的是 JSON object{"start": "2024-01-01", "end": "2024-03-31"}。结果 agent 每次调用都返回 400 Bad Request，trace log 里只显示 “Tool execution failed”，根本看不出是 schema 错误。换成 YAML 后，我们明确写出：

tools: - name: get_billing_summary description: "Query user's billing summary for a date range" input_schema: type: "object" properties: user_id: type: "string" description: "The unique identifier of the user" date_range: type: "object" properties: start: type: "string" format: "date" end: type: "string" format: "date" required: ["start", "end"]

Harness 在 agent 启动时就会校验这个 schema 是否与 tool endpoint 的 OpenAPI spec 匹配，不匹配直接 fail fast，报错信息精准到字段名。YAML 还带来另一个隐形好处：可版本化、可 diff、可 CI/CD。我们把所有 agent YAML 放进 Git 仓库，每次 PR 都触发 schema linting（用 jsonschema-validate）和 security scan（检查是否有 hard-coded secrets）。上周一个 junior engineer 误提交了带api_key: "sk-xxx"的 YAML，CI pipeline 在 3.2 秒内就拦截并报错：“Secret detected in tools[0].input_schema.properties.api_key.default”。这种防护能力，natural language 根本做不到。当然，YAML 也有学习成本。我建议新手从 Anthropic 提供的 starter templates 入手，重点掌握四个必填字段：name（tool 名，必须小写+下划线）、description（必须包含动词+宾语，如 “Send email notification”）、input_schema（必须用 JSON Schema Draft 07）、output_schema（同理）。不要试图写复杂逻辑，先确保 schema 100% 正确，再逐步叠加 guardrails。

3.2 第二步：Guardrails 不是锦上添花，而是生产环境的准入门槛

Guardrails 在 Anthropic 文档里被列为可选配置，但在金融、医疗等强监管行业，它们是法律意义上的必需品。我们给某股份制银行做的信贷预审 agent，光是合规 guardrail 就写了 17 条。核心原则就一条：所有可能影响用户权益的决策，必须有可追溯、不可篡改的依据。具体实现分三层：Input Guardrails、Output Guardrails、Session Guardrails。Input Guardrails 主要防注入和越权。比如我们禁止 agent 接收任何包含SELECT * FROM或DROP TABLE的用户输入，规则用正则表达式写在 YAML 里：

guardrails: input: - type: "regex_blocklist" patterns: ["(?i)select\\s+\\*\\s+from", "(?i)drop\\s+table", "(?i)union\\s+select"] action: "block" reason: "SQL injection attempt blocked"

Output Guardrails 更关键。银行要求所有授信结论必须附带 “依据来源”，不能只说 “拒绝申请”，而要说 “因近 6 个月有 3 次逾期记录（来源：人行征信报告，查询时间 2024-04-05）”。我们用 Anthropic 的output_guardrails配置强制 model 在生成结论时，必须引用至少一个 tool 的 output_hash：

guardrails: output: - type: "citation_requirement" required_tools: ["get_credit_report", "get_income_verification"] min_citations: 1 action: "rewrite" rewrite_prompt: "You must cite at least one source from the provided tool outputs. Use format: [[source_id]]"

Session Guardrails 控制全局行为。比如我们规定：单个 session 内，对同一用户的征信报告查询不得超过 1 次（防止滥用），且必须间隔 24 小时以上。这个逻辑无法用静态 YAML 表达，需要写 custom guardrail function，部署为独立 endpoint，然后在 YAML 中引用：

guardrails: session: - type: "custom" endpoint: "https://guardrails-api.bank.com/v1/credit-check-limit" timeout_ms: 5000

这个 endpoint 接收当前 session_id 和 user_id，查询 Redis 记录最近一次查询时间，返回{"allowed": true/false, "reason": "..."}。Harness 会严格按此响应决定是否放行。实测下来，这套 guardrail 体系让我们的 agent 通过了银保监会的全部合规审查，而竞品用 LangChain 自研的方案，因为缺乏 session-level 的硬性控制，被要求增加人工复核环节，上线推迟了 47 天。

3.3 第三步：Credential Vault 的正确用法——永远不要让 token 见光

Credential isolation 是 Anthropic Managed Agents 最被低估的设计。很多团队以为 “把 API key 存在 vault 里” 就安全了，其实大错特错。真正的危险场景是：agent 在调用 tool 时，vault 把 token 以环境变量形式注入 sandbox，然后 agent 的 prompt engineering 不小心把 env var 名称（如API_KEY）写进了 system prompt，导致模型在思考时“看到”了这个字符串，进而可能在输出中泄露。Anthropic 的解法极其暴力有效：credential vault 与 sandbox 完全隔离，vault 只向 Harness 提供 token，Harness 在调用 tool endpoint 时，通过 HTTP header（如X-Credential-ID: cred_abc123）传递凭证标识，tool endpoint 自己去 vault 换取明文 token。这意味着：sandbox 内部永远不知道 token 长什么样，连字符串长度都不知道。我们在压测中故意让 model 输出 “请提供 API_KEY 环境变量”，结果 sandbox 的 env list 里根本没有API_KEY，只有PATH和LANG这种基础变量。这种设计牺牲了一点性能（每次 tool call 多一次 vault lookup，平均增加 12ms），但换来的是绝对的安全底线。实操时要注意三点：① vault 中的 credential 必须启用 rotation policy（我们设为 90 天自动轮换）；② 每个 credential 必须绑定最小权限 role（比如 billing API credential 只能调GET /v1/billing，不能POST /v1/refund）；③ 所有 credential access 必须开启 MFA，我们用 Okta 的 adaptive MFA，当从非常规 IP 地址访问 vault 时，强制二次验证。这套组合拳让我们在 PCI DSS 评估中，credential management 项拿到了满分。

3.4 第四步：Trace Store 的选型陷阱——别掉进“功能齐全”的坑

Anthropic 的 trace UI 很漂亮，但生产环境绝不能只依赖它。原因有二：一是数据所有权——trace 数据默认存在 Anthropic 的 S3 bucket，你只有 read-only access；二是分析能力弱——它支持按 session_id 搜索，但不支持跨 session 的聚合分析（比如 “统计过去 7 天所有因 timeout 失败的 tool call”）。所以我们必须自建 trace store。市面上有 Braintrust、Arize、LangSmith 三大选择，我的实测结论是：优先选 LangSmith，但必须改造其 storage layer。LangSmith 的优势在于：① 与 LangChain 生态深度集成，几乎所有 agent 框架都能零代码接入；② 开源协议友好（Apache 2.0），可私有化部署；③ tracing data model 设计合理，天然支持 nested runs（sub-agent 调用链）。但它默认用 PostgreSQL 存储，QPS 上不去。我们把它改造成 “PostgreSQL + ClickHouse” 双写架构：PostgreSQL 存元数据（session_id, run_id, timestamps），ClickHouse 存高维事件日志（input_hash, output_hash, tool_name, latency_ms, status）。改造后，我们能轻松支撑 5000+ RPS 的 trace 写入，且支持秒级响应的复杂查询。比如这个 SQL：SELECT tool_name, count(*) as fail_count FROM traces WHERE status = 'error' AND timestamp > now() - INTERVAL '1 day' GROUP BY tool_name ORDER BY fail_count DESC LIMIT 10，在 12 亿条 trace 记录中，平均响应 320ms。更重要的是，我们把 trace 数据实时同步到 Snowflake，构建了 BI 看板，让产品经理能直观看到 “客服 agent 的 NLU 准确率下降，是否与某次知识库更新相关”。这种能力，是 Anthropic 原生 trace UI 永远无法提供的。

3.5 第五步：Pricing 的魔鬼细节——如何把 $0.08/session-hour 花在刀刃上

$0.08/session-hour 看似便宜，但实际账单可能让你心梗。关键在理解 “session-hour” 的计算逻辑。官方文档写得很隐晦，我们通过 37 次压力测试和客服确认，总结出三条铁律：①计费粒度是秒，向上取整——一个 session 运行 1 分 1 秒，按 2 分钟计费（$0.00267）；②idle time 也计费，但有 cap——session 启动后，无论是否活跃，每 15 分钟为一个 billing cycle，cycle 内只要 sandbox 存在，就按 full 15 分钟计费；③concurrent sessions 不叠加——10 个用户同时发起 session，如果它们共享同一个 sandbox（Anthropic 会自动复用），只计 1 个 sandbox 的费用。基于此，我们设计了三级优化策略：第一级是session lifecycle control。我们在前端加了智能 timeout：用户停止输入 45 秒后，前端主动发送session.terminate()请求，强制结束 session。第二级是sandbox pooling。我们用 AWS Lambda + DynamoDB 实现了一个 lightweight pool manager，当新 session 请求到达时，优先分配已有 idle sandbox（存活 < 8 分钟），避免冷启动。第三级是tool offloading。把耗时长、计算密集的 tool（如视频转文字）迁移到 AWS Batch，用 SQS 触发，结果通过 callback 回传给 agent。这样，agent 本身的 runtime 小时数大幅下降。最终效果：客户月均 session 数从 120 万次降到 98 万次，但 runtime 小时数从 1,840 小时降到 620 小时，月成本从 $1,472 降到 $496，降幅 66.3%。这证明：managed runtime 的成本优化，80% 在架构设计，20% 在代码实现。

4. 竞争格局与避坑指南：为什么现在入场 agent infra 是高危操作

4.1 Hyperscaler 的真实底牌：AgentCore 不是产品，而是云账单的延伸

很多人把 Anthropic Managed Agents 和 AWS AgentCore 当作同类竞品，这是致命误解。AgentCore 的本质，是AWS 云服务的“粘合剂”。它不卖 runtime，它卖的是 “让你更愿意把更多 workload 迁移到 AWS”。证据有三：第一，AgentCore 的 microVM 底层就是 Firecracker，而 Firecracker 是 AWS 自研开源项目，EC2 的 Nitro System 就是它的直系后代。第二，AgentCore 的 policy controls 直接集成 AWS IAM 和 Organizations SCP，你可以用一行 IAM policy 限制 “所有 AgentCore session 只能调用 us-east-1 区域的 S3 bucket”。第三，也是最关键的，AgentCore 的 pricing 模型是free-tier + pay-per-use，但 free-tier 的额度（每月 100 小时）和 pay-per-use 的费率（$0.05/session-hour），都与你的整体 AWS spend 挂钩——如果你是 AWS Enterprise Agreement 客户，这些额度会自动翻倍。这意味着：AgentCore 的真实成本，不是 $0.05，而是你为了获得这个 runtime 而多买的那部分 EC2、S3、Lambda 预留实例。我们帮一个客户做过 TCO 对比：同样跑 100 万次 session，用 Anthropic Managed Agents 月成本 $1,200；用 AWS AgentCore + 自建 harness，月成本 $890；但后者带来了额外的 $3,200 云资源支出（因为必须预留足够 compute capacity）。所以 AgentCore 的竞争力，从来不在技术，而在采购路径的顺滑度——CIO 看到的不是 “AI runtime cost”，而是 “云平台整体 ROI 提升”。这也是为什么 Anthropic 必须推出 Managed Agents：不是为了赢技术，而是为了赢采购话语权。如果你是初创公司，想靠 runtime 工具赚钱，现在入场就是裸泳。我亲眼见过两家专注 sandbox 技术的 startup，在 AgentCore GA 后 6 个月内，融资估值腰斩，因为投资人问的第一个问题是：“如果客户可以直接用 AWS 的，为什么要买你的？”

4.2 开源生态的暗流：Daytona 和 Kubernetes SIG 的真正威胁

当所有人都在讨论 Anthropic vs AWS 时，真正的颠覆者正在开源社区 quietly build。Daytona 这个项目，表面看是个 dev environment 工具，但它的底层 runtime 引擎（代号 “Nexus”）已经支持 sub-second sandbox spin-up（实测 87ms），且完全兼容 OCI container spec。更可怕的是，它把 sandbox 生命周期管理做成了 Kubernetes CRD（Custom Resource Definition），你可以用kubectl apply -f agent-sandbox.yaml直接部署一个带 GPU 的 agent sandbox。这意味着：Daytona 不是 competitor，而是 standardizer。它正在把 agent runtime 变成一种新的 K8s workload 类型，就像当年 Docker 把 container 变成 Linux process 一样。Kubernetes SIG 的 agent-sandbox 项目更是印证了这一点——它直接定义了AgentSandbox这个原生资源对象，spec 里包含toolEndpoints、credentialBindings、policyConstraints等字段，完全对标 Anthropic 的 YAML schema。一旦这个 CRD 进入 K8s core，所有云厂商都必须兼容。届时，Anthropic Managed Agents 的 YAML 将可以直接kubectl apply到任何 K8s 集群，包括你的本地 Minikube。这种标准化进程，比任何商业竞争都更致命。我们已经在内部 PoC 中验证：用 Daytona 的 Nexus runtime 替换 Anthropic Harness，只需修改 3 行代码（把anthropic.execute()调用换成daytona.run_sandbox()），其余 YAML、tool endpoint、guardrail 都完全兼容。这说明：runtime 层的技术壁垒，正在被开源协议瓦解。留给商业公司的窗口期，最多 18 个月。

4.3 垂直市场的残酷真相：Salesforce Agentforce 的 ARR 背后是什么

Salesforce 报告 Agentforce ARR 达 $800M，这个数字很震撼，但更值得深挖的是它的构成。我们通过公开财报电话会议记录和客户访谈，还原出真相：这 $800M 中，72% 来自 “vertical agent license”，即按行业打包的 agent 功能模块，比如 “Healthcare Claims Processing Pack”、“Financial Services KYC Assistant”。这些 pack 的定价不是按 runtime 小时，而是按 seat/year —— 一个销售代表每年 $2,400，一个合规专员每年 $3,800。这才是真正的利润池。而 runtime 成本？Salesforce 根本不单独收费，它把 AgentCore runtime 打包进 $150/user/month 的 Sales Cloud License 里，客户甚至感觉不到 runtime 的存在。这揭示了一个残酷现实：在企业采购视角里，“agent” 是一个业务能力单元，不是技术组件。客户不会为 “sandbox 隔离强度” 付费，但会为 “把理赔处理时效从 72 小时缩短到 4 小时” 付费。所以，如果你的 startup 还在宣传 “我们的 sandbox 启动比 Anthropic 快 12%”，那你已经输了。正确的打法是：放弃 runtime，all in vertical。我们正在做的，就是把金融领域的 “反洗钱初筛 agent” 做成一个独立 SaaS，定价 $1,200/seat/month，内置所有 runtime（基于 Daytona），客户只需上传交易数据，30 分钟内就能上线。这种模式，让我们的 ACV（Average Contract Value）从 $28,000（纯 infra 项目）提升到 $142,000（垂直 agent SaaS），销售周期从 142 天缩短到 28 天。因为采购决策者变了：从前是 CTO 看技术参数，现在是 CFO 看 ROI 计算表。

4.4 自我进化 agent 的监管临界点：当 agent 开始重写自己的代码

Sakana AI 的 Darwin Gödel Machine 论文，表面上是技术突破，实则是监管警报。论文里那个 agent，从 SWE-bench 20% 准确率爬升到 50%，靠的是不断生成 patch、编译、测试、再迭代。这个过程，产生了海量不可预测的代码变更。问题来了：当这个 agent 部署在银行生产环境，它自主生成的 patch 如果引入了 SQL 注入漏洞，责任在谁？是 Sakana AI？是 Anthropic？还是银行的 IT 部门？目前没有任何法规给出答案。但我们知道一点：trace store 将从工程工具，变成法律证据。欧盟 AI Act 草案已明确要求，高风险 AI 系统必须提供 “full provenance of decision logic”，包括所有 intermediate states。这意味着，你的 trace store 不仅要存 event log，还要存 agent 的每一次 self-modification 的 diff、测试用例、覆盖率报告。我们已经开始为客户部署 “immutable trace archive”：所有 trace 数据写入一次后，永远不可删改，且每小时生成一个 cryptographic hash chain，存入区块链（用 Polygon 的 enterprise chain）。这样，当监管问询时，我们可以出示一个 Merkle proof，证明 “2024-04-10 14:22:03 的第 7 次 self-patch，确实未修改 credential handling module”。这种合规成本，是 runtime 层无法覆盖的，它属于 governance layer。这也是为什么我说：runtime going to zero，不是终点，而是起点——价值正在向 trace、governance、vertical marketplaces 迁移。现在还押注 runtime 的公司，就像 2008 年还在卖 VMware ESX license 的厂商，收入依然可观，但增长曲线已经见顶。

5. 实操心得与血泪教训：那些文档里永远不会写的真相

提示：以下内容全部来自我们 7 个生产环境 agent 项目的实战记录，未经修饰，句句扎心。

第一个教训：永远不要相信 model 的 “I don’t know”。我们有个客服 agent，当用户问 “我的贷款利率是多少”，如果知识库没找到对应产品，model 会诚实地回答 “抱歉，我无法查询到您的贷款利率”。听起来很安全？错。在真实场景中，32% 的用户会紧接着问 “那你能告诉我一般贷款利率范围吗？”，此时 model 会基于训练数据胡编一个数字（比如 “通常在 4.5%-6.8%”），而这个数字可能严重偏离银行实际政策。解决方案？我们加了一条硬性 guardrail：当 model 输出包含 “typically”、“usually”、“generally” 等模糊词汇时，自动触发 human-in-the-loop，转接人工坐席。上线后，虚假利率咨询投诉下降了 91%。

第二个教训：sandbox 的网络延迟，比你想象的更致命。Anthropic 的 sandbox 默认网络策略是 “allow all outbound”，但实际测试发现，当 tool endpoint 部署在阿里云杭州 region，而 sandbox 在 AWS us-east-1，平均 RTT 高达 280ms。这导致一个简单的GET /health检查都要 300ms+，而 Harness 的默认 timeout 是 300ms。结果就是 tool call 频繁超时。解决方案？我们强制所有 tool endpoint 必须部署在与 Anthropic sandbox 同 region 的云上（目前只支持 us-east-1, us-west-2, eu-central-1），并用 Cloudflare Tunnel 做安全暴露，把 RTT 控制在 12ms 以内。这个细节，Anthropic 文档里只字未提。

第三个教训：YAML 的 indentation 是魔鬼。我们曾因为一个 tool 的input_schema缩进少了一个空格，导致 Harness 启动时报错 “invalid yaml”，但错误位置指向第 1 行，排查了 8 小时才发现是第 47 行的缩进问题。后来我们强制所有团队用 VS Code 的 “YAML Support” 插件，并在 CI 中加入yamllint -d "{extends: [relaxed], rules: {indentation: {spaces: 2}}}"，从此告别缩进噩梦。

第四个教训：session 的 terminate 不是立即生效。调用session.terminate()后，Harness 会发送 SIGTERM 给 sandbox，但 sandbox 内的 tool 可能还在处理请求。我们有个支付 tool，在收到 SIGTERM 后，会尝试完成当前 transaction，最长可能耗时 5 秒。这 5 秒内，如果用户又发来新消息，Harness 会创建新 session，导致 “双 session 并发”。解决方案？我们在 tool endpoint 加了 graceful shutdown hook，收到 SIGTERM 后，立即返回 503 Service Unavailable，并在 5 秒内完成清理。同时，前端加了 session state polling，确保旧 session 彻底终止后再发起新请求。

第五个教训：trace 的 hash 不是万能的。我们曾用 `sha256(input