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

你点开这篇文字时，大概率刚刷完 Anthropic 宣布 Managed Agents 公测的新闻——标题里那个“Layer That’s Already Going to Zero”，听着像玄学预言，其实是个非常具体的工程判断。它不讲模型多强、推理多快、多模态多惊艳，而是直指一个被多数人忽略的底层事实： 所有能跑起来的 AI agent，最终都得落进一个沙盒里执行；而这个沙盒本身，正以肉眼可见的速度变成水电煤一样的基础设施 。关键词里反复出现的 “Towards AI - Medium”，恰恰说明这件事已从技术圈内讨论，正式进入主流开发者认知带宽——不是“要不要用 agent”，而是“用谁家的 runtime 来跑”。

我去年在一家做合规文档自动审核的 startup 带队落地过三套生产级 agent 系统，全部踩过同一个坑：把 session state（会话状态）硬塞进 LLM 的 context window 里。当时觉得省事——不用额外存数据库，模型自己记着。结果呢？一个跨 7 步、调用 4 类工具、涉及 12 份 PDF 解析的客户尽调流程，跑到第 5 步时 context 溢出，模型没报错，只是开始“温柔地编造”前两步的工具返回结果。我们花了 3 天时间回溯日志、比对原始文件、手动重跑中间步骤，最后发现根本没法复现——因为那段被覆盖掉的上下文，连个影子都没留下。这不是故障，是静默失效。它不炸服务器，只悄悄吃掉你的交付周期、客户信任和季度 OKR。Anthropic 今天说的“session as durable event log”，翻译成人话就是： 别再让大模型当你的记事本了，让它专心当裁判，而把记分板交给专门的、可查询、可回放、可审计的存储层 。这背后不是炫技，是血泪教训换来的架构共识。它解决的不是“能不能做”，而是“敢不敢在生产环境里长期跑”。如果你正在评估是否要自建 agent 平台、选型框架、或者给老板写技术方案，这篇文章里每一个结论，我都亲手在 AWS、Azure 和自建 K8s 集群上验证过三次以上。它不教你怎么写 prompt，但能帮你避开让整个项目延期两个月的底层陷阱。

2. 核心设计逻辑：为什么“解耦”是唯一活路

2.1 三层分离：Harness、Session、Sandbox 的真实分工

Anthropic 的工程博客里提到的“harness as stateless executor”、“session as durable event log”、“sandboxes as cattle”，听起来像术语堆砌。但拆开看，每一层都在解决一个具体到令人窒息的工程痛点。我们来逐层还原它们在真实生产环境中的角色：

• Harness（执行器） ：它真的只是一个函数调用入口， execute(name, input) → string 。它的唯一职责是接收一个工具名（比如 search_confluence ）和输入参数（比如 {query: "Q4 compliance checklist"} ），然后把请求转发给对应的 sandbox 容器，并等待返回字符串结果。它不保存任何状态，不解析返回内容，不决定下一步调用什么——这些决策全由外部 orchestrator（比如 LangGraph 或自研的状态机）完成。我见过太多团队把 orchestration 逻辑硬塞进 harness 里，结果一升级模型版本，整个执行链就崩。Harness 必须轻，轻到可以随时重启、水平扩缩、甚至用不同语言重写而不影响上层。我们线上系统目前用 Go 写的 harness，二进制只有 4.2MB，启动耗时 <120ms，就是为了这个“无感替换”的底气。

• Session（会话） ：这才是真正的“大脑皮层”。它是一条结构化的、带时间戳的事件流（event stream），每一条记录包含： {timestamp, step_id, tool_name, input, output, duration_ms, error?} 。它不存于模型 context 中，而是写入专用的 OLAP 数据库（我们用 ClickHouse，单表写入吞吐 > 200K EPS）。关键在于， session ID 是全局唯一且持久的 。当用户中断后重新接入，orchestrator 只需 awake(sessionId) ，就能从数据库里拉出完整历史，跳过已成功执行的步骤，直接从失败点继续。这解决了最痛的“断点续跑”问题。更关键的是，这条日志是审计的黄金标准——法务要查某次合同生成依据，直接按 sessionId 查，所有工具调用、参数、返回值、耗时一目了然，无需翻 N 个服务日志拼凑。

• Sandbox（沙盒） ：它不是 Docker 容器那么简单。Anthropic 的实现是基于 Firecracker microVM，每个 sandbox 拥有独立的 CPU 核心配额、内存隔离、网络 namespace 和只读 rootfs。工具代码（比如 Python 脚本调用 Confluence API）被打包成 OCI 镜像，启动时注入最小化凭证（通过 IAM Role 绑定，而非环境变量），且 sandbox 生命周期与单次工具调用严格绑定：调用结束，microVM 立即销毁。这意味着：1）一个工具漏洞不会污染其他工具；2）凭证泄露面被压缩到毫秒级；3）资源占用可精确计量（AWS AgentCore 的 microVM 计费粒度是 100ms）。我们曾用一个故意写死无限循环的 list_s3_buckets 工具测试，sandbox 在 15 秒超时后强制终止，宿主机 CPU 无任何抖动——这才是生产级隔离该有的样子。

提示：不要被“sandbox”字面意思迷惑。它不是为了防模型“越狱”，而是为了防工具代码失控、防凭证泄露、防资源争抢。一个没做 microVM 隔离的 Docker 沙盒，在生产环境里约等于裸奔。

2.2 为什么必须解耦？一次真实的“context 溢出”事故复盘

去年 Q3，我们上线了一个面向金融客户的“监管问询响应 agent”。流程是：1）解析监管邮件 PDF；2）检索内部知识库匹配条款；3）调用 Wind/同花顺 API 获取最新市场数据；4）生成合规回复草稿；5）提交法务系统审批。整个流程设计为 12 分钟内完成。上线首周，成功率 98%。第二周，成功率断崖跌至 63%。监控显示 token usage 持续攀升，但错误日志里全是 LLM returned malformed JSON 这类模糊报错。

我们花了 48 小时做根因分析，最终定位到：当第 3 步调用 Wind API 返回的数据量较大（比如某次返回了 150 行股票行情），加上前两步的 PDF 文本和知识库片段，总 token 数轻松突破 Claude 3.5 Sonnet 的 200K 上下文窗口。模型没有报错，而是开始“创造性压缩”——它把第一步解析的 PDF 关键页码信息，替换成第二步知识库中某个相似条款的页码。结果是：生成的回复引用了错误的监管条款，且所有中间步骤日志里都找不到这个篡改痕迹，因为原始 PDF 解析结果早已被挤出 context。

解决方案？不是升级到更大 context 的模型（成本翻倍，延迟增加），而是立刻重构：将每一步的输出（PDF 结构化数据、知识库匹配结果、API 返回 JSON）全部写入 session event log，并在后续步骤的 prompt 中，只传入一个 step_id 引用。模型 context 里永远只保留当前步骤的指令和必要参数，体积稳定在 8K token 以内。重构后，成功率回升至 99.2%，平均延迟下降 37%。这个案例印证了 Anthropic 架构的核心价值： 把不可靠的、易溢出的、难审计的模型 context，替换成可靠的、可扩展的、可审计的外部存储 。这不是架构师的浪漫想象，是运维半夜被报警电话叫醒后，用咖啡和黑眼圈换来的生存法则。

2.3 与 AWS AgentCore 的对比：不是谁先谁后，而是谁更“云原生”

文中提到“Anthropic 的 launch 是 defensive，not pioneering”，这话很准，但需要更深一层解读。AWS Bedrock AgentCore 在 2025 年底 GA，确实早于 Anthropic 5 个月。但二者的设计哲学差异巨大，直接决定了它们在不同场景下的适用性：

维度	Anthropic Managed Agents	AWS Bedrock AgentCore
模型锁定	强绑定 Claude 系列（Claude 3.5 Sonnet / Haiku / Opus）	完全开放：支持 Claude、Llama 3、Cohere Command R+、Titan Text 等所有 Bedrock 托管模型
沙盒技术	Firecracker microVM（轻量、快速、强隔离）	Firecracker microVM（同源，但 AWS 对启动优化更激进，实测冷启动 <80ms）
会话持久化	自动托管，最长 7 天，事件日志默认可查	需用户自行集成 Amazon DynamoDB 或 S3 存储 session state，AWS 提供 SDK 封装
凭证管理	Anthropic Vault 托管，sandbox 启动时动态注入短期凭证	完全依赖 AWS IAM Roles for Tasks，凭证生命周期由 ECS/EKS 控制
计费模式	$0.08/session-hour + Claude token 费用	$0.05/microVM-hour + 模型 token 费用（无 session 概念，按实际运行时长计）
框架兼容性	原生适配 Anthropic 自研工具调用协议，LangChain 需 adapter	明确声明“framework-agnostic”，提供标准 HTTP 接口，LangGraph/CrewAI 开箱即用

关键洞察在于： AgentCore 不是一个“产品”，而是一个“能力组合” 。它把 microVM、IAM、DynamoDB、CloudWatch 这些 AWS 已有的成熟服务，用一套统一的 agent 抽象层粘合起来。你用它，本质上是在用 AWS 的云原生能力栈。而 Anthropic Managed Agents，则是一个垂直整合的“Claude 专属运行时”，它牺牲了模型灵活性，换取了端到端体验的丝滑——从 YAML 定义 agent 到 session 日志可查，全程无需碰 AWS 控制台。选择哪个，取决于你的技术栈重心：如果团队已深度绑定 AWS，且未来可能混合使用多个模型（比如用 Llama 3 做初筛，Claude 做精修），AgentCore 是更经济的选择；如果团队核心资产是 Claude 的推理能力，且追求最快上线、最少运维，Managed Agents 的“开箱即用”价值巨大。这不是技术优劣之争，而是云厂商生态位与模型厂商护城河的必然碰撞。

3. 实操落地：从零搭建一个生产级 agent runtime 的关键步骤

3.1 最小可行架构（MVP）：用 3 个服务撑起第一版

别被“runtime”这个词吓住。一个真正能跑通、能 debug、能上生产的 MVP，只需要三个核心服务，且全部可用开源组件快速搭建。我用这套架构在两周内交付了客户第一个 PoC，至今仍在生产环境运行。以下是经过千次压测验证的组件选型与配置逻辑：

1. Orchestrator（编排器） ：选用 LangGraph v0.2.12 。
   为什么不是 CrewAI 或 AutoGen？ CrewAI 的状态管理过于抽象，debug 时难以追踪具体哪一步卡住；AutoGen 的 group chat 模式在复杂流程中容易陷入死循环。LangGraph 的 StateGraph 显式定义节点（nodes）和边（edges），每个节点就是一个纯函数（如 call_search_tool ），状态（state）作为 dict 透传，debug 时打印 state 即可看到全貌。关键配置：启用 checkpointer ，后端用 Redis（我们用 AWS ElastiCache，TTL 设为 7 天），这样每次 graph.invoke() 都会自动保存 checkpoint，断点续跑成为默认行为。

2. Sandbox Manager（沙盒管理器） ：自研轻量级服务（Go 编写，<2000 行），核心功能是：接收 tool_name 和 input → 拉起 Firecracker microVM → 注入工具镜像和短期凭证 → 执行工具 → 捕获 stdout/stderr → 销毁 microVM → 返回结果。
   为什么不直接用 AWS Lambda？ Lambda 的 15 分钟超时和 10GB 内存上限，在处理大型 PDF 解析或批量 API 调用时捉襟见肘；microVM 可控性更强，且能完美复现生产环境隔离性。我们用 Firecracker Go SDK 封装，启动一个 microVM 的 P95 耗时稳定在 110ms。工具镜像采用 distroless 基础镜像（如 gcr.io/distroless/python3-debian12 ），仅包含 Python 解释器和必要依赖，镜像大小 <80MB，拉取速度极快。

3. Trace Store（追踪存储） ：选用 ClickHouse Cloud（Serverless Tier） 。
   为什么不是 Elasticsearch 或 PostgreSQL？ ES 的写入延迟波动大（P95 > 500ms），在高并发 agent 场景下易丢日志；PostgreSQL 的 JOIN 性能在亿级 event 表上急剧下降。ClickHouse 的列式存储和向量化引擎，对 SELECT * FROM events WHERE session_id = 'xxx' ORDER BY timestamp 这类查询，P99 延迟 <20ms，且成本仅为同等规模 ES 的 1/3。我们建表结构极度精简：

   CREATE TABLE agent_events (
       session_id String,
       step_id UInt32,
       tool_name String,
       input String CODEC(ZSTD(1)),
       output String CODEC(ZSTD(1)),
       error String,
       duration_ms UInt32,
       timestamp DateTime64(3, 'UTC')
   ) ENGINE = ReplacingMergeTree
   ORDER BY (session_id, step_id, timestamp);
   

   input 和 output 字段用 ZSTD 压缩，实测压缩率 4.2:1，单日 500 万 event 仅占 12GB 存储。

注意：这三个服务之间 绝不共享内存或数据库连接池 。Orchestrator 通过 HTTP POST 调用 Sandbox Manager；Sandbox Manager 执行完毕后，通过异步 HTTP POST 将 event 发送给 Trace Store。这种松耦合保证了任一服务崩溃都不会拖垮全局，符合“cattle not pets”的设计哲学。

3.2 Session Event Log 的设计细节：如何让日志真正“可审计”

一个漂亮的 dashboard 不能代替一份可审计的日志。我们在线上系统中强制推行以下三条日志规范，效果立竿见影：

1. Event 必须包含可验证的“因果链” ：每个 event 记录中，除了基础字段，必须添加 parent_step_id （上一步的 step_id）和 correlation_id （贯穿整个 session 的唯一 UUID）。例如，当 search_confluence 工具返回结果后，触发 generate_draft 步骤，其 event 的 parent_step_id 必须等于 search_confluence 的 step_id 。这样，通过 correlation_id 查询，就能得到一条严格有序的因果链，杜绝“时间戳相近但逻辑无关”的日志混淆。

2. Output 必须结构化，禁止自由文本 ：所有工具的返回值，必须是 JSON Schema 严格定义的对象。例如 list_s3_buckets 工具，返回格式固定为：

   {
     "buckets": [
       {"name": "prod-data-2025", "region": "us-east-1", "creation_date": "2025-03-12T08:22:15Z"},
       {"name": "backup-logs", "region": "us-west-2", "creation_date": "2025-04-01T14:05:33Z"}
     ],
     "truncated": false
   }
   

   这样，Trace Store 的 ClickHouse 表可以直接用 JSONExtractString(output, 'buckets') 提取数组，无需在应用层做 JSON 解析——既提速，又避免解析错误导致日志丢失。

3. Error 必须分级，且附带可操作建议 ：日志中的 error 字段不是 dump traceback。我们定义三级错误：

   • ERROR_TYPE_TOOL_FAILED ：工具进程非零退出， error 字段为 "Tool 'search_confluence' failed with exit code 1. Check Confluence API quota."
   • ERROR_TYPE_SANDBOX_CRASHED ：microVM 启动失败或超时， error 字段为 "Sandbox crashed during init. Possible cause: invalid tool image. Retry with --debug flag."
   • ERROR_TYPE_MODEL_MALFORMED ：LLM 返回非预期 JSON， error 字段为 "Model output invalid JSON. Expected field 'action', got 'response'. Increase temperature or add JSON schema to system prompt." 每个错误类型都对应一个标准处理 SOP，一线运维看到 error 字段，就能立刻知道该查哪个服务、该执行哪条命令，而不是打开 5 个 Grafana 面板盲猜。

3.3 Credential Isolation 的实战：如何让密钥“看不见、摸不着”

文中提到“credentials bundled into the sandbox at provision time, never injected as environment variables”，这绝非一句空话。我们在生产环境实施了四层凭证防护，缺一不可：

1. 凭证绝不落地 ：所有 API Key、Secret Access Key、OAuth tokens，均存储于 AWS Secrets Manager 。Sandbox Manager 在启动 microVM 前，调用 Secrets Manager 的 GetSecretValue API 获取凭证，并通过 Firecracker 的 initrd 机制，将凭证以加密形式注入 microVM 的内存（而非磁盘或文件系统）。microVM 启动后，工具进程通过 /dev/shm/credential （POSIX shared memory）读取，进程结束后内存自动清零。

2. 最小权限原则（PoLP） ：为每个工具创建独立的 IAM Role。例如 confluence-reader-role 只有 confluence:SearchContent 权限， s3-list-role 只有 s3:ListBucket 权限。Role 绑定到 microVM 的 instance profile，工具代码中无需硬编码任何凭证，直接调用 boto3.client('s3') 即可获得临时凭证。我们用 Terraform 管理这些 Role，每次新增工具，必须同步 PR 一个 iam_role.tf 文件，否则 CI/CD 拒绝合并。

3. 凭证有效期强制缩短 ：Secrets Manager 中的凭证，设置自动轮转（auto-rotation）周期为 24 小时。更重要的是，microVM 启动时获取的临时凭证，其 Expiration 字段被硬编码为 15 分钟（远短于默认的 1 小时）。这意味着，即使 microVM 被攻破，攻击者最多只能拿到 15 分钟有效的凭证。

4. 网络层隔离 ：所有 microVM 的网络 namespace，均配置为只允许访问白名单域名（如 api.confluence.com , s3.us-east-1.amazonaws.com ），且强制走 VPC Endpoint（而非 Internet Gateway）。任何尝试访问 169.254.169.254 （EC2 metadata endpoint）的请求，都会被 iptables DROP。我们用 eBPF 程序在宿主机上实时监控，一旦发现异常 DNS 请求，立即告警并终止对应 microVM。

实操心得：很多团队卡在 credential isolation 这一步，不是技术做不到，而是流程没跟上。我们强制要求：所有工具代码的 PR，必须附带一份 SECURITY.md ，明确列出所需权限、访问的域名、凭证有效期。安全团队每周抽检 5 个 PR，未达标者打回。这套流程跑顺后，渗透测试报告里的“高危凭证泄露”项，从 12 个降为 0。

4. 生产环境避坑指南：那些没人告诉你的“静默杀手”

4.1 “Session Hour” 计费陷阱：你以为的闲置，其实是真金白银

Anthropic 的 $0.08/session-hour 看似便宜，但这是个典型的“温水煮青蛙”陷阱。我们上线首月账单震惊了整个财务部——$0.08/hour × 24h × 30d = $57.6/月/session，而我们有 127 个活跃 session（每个客户一个），月账单近 $7300。问题出在哪？ session hour 是按“session 创建到销毁”的总时长计费，而非“active execution time” 。

我们的 agent 设计是：用户发起请求 → 创建 session → orchestrator 开始执行 → 所有步骤完成后，session 并不自动销毁，而是保持“待命”状态，等待用户下一次消息（比如“再补充一点风险提示”）。这个“待命”状态，只要 session 对象还存在于 Redis checkpointer 中，就算作 active session hour。我们最初设的 TTL 是 7 天，结果大量 session 在用户离开后静静燃烧了 168 小时。

解决方案是引入 session lifecycle manager ：一个独立的后台服务，监听 Redis 的 keyspace notification（ __keyevent@0__:expired ），当 session 因 TTL 过期被删除时，它会检查该 session 的最后一条 event 时间戳。如果距离现在 > 5 分钟，则认为 session 已“死亡”，无需干预；如果 < 5 分钟，则判定为“用户可能还在”，自动延长 TTL 1 小时，并记录日志。同时，在 orchestrator 的 invoke() 调用末尾，显式调用 session.end() 方法，主动销毁 session。这两招结合，session hour 成本下降 68%。

提示：AWS AgentCore 没有 session 概念，按 microVM 实际运行时长计费，反而更透明。但代价是你得自己实现 session 状态管理，工作量不小。

4.2 Sandbox 启动风暴：当 100 个用户同时点击“开始”

高并发场景下，microVM 启动的毛刺是最大敌人。我们经历过一次真实事故：营销活动上线，1000 名用户同时触发 agent，Sandbox Manager 在 2 秒内收到 1000 个启动请求。Firecracker 的冷启动（cold start）需要加载 kernel、initrd、rootfs，单个耗时 110ms，1000 个串行启动要 110 秒——这显然不可接受。

根本解法是 warm pool（热池） ：预先启动一批空闲的 microVM，放入内存池，等待任务分配。我们用一个简单的策略：维持一个大小为 max_concurrent_requests × 1.5 的 warm pool（ max_concurrent_requests 从历史流量峰值推算）。Sandbox Manager 收到请求后，优先从 pool 中取一个空闲 microVM，注入工具镜像和凭证，执行任务；任务结束后，microVM 不销毁，而是清空内存、重置网络，放回 pool。实测表明，warm pool 下的 P95 启动延迟从 110ms 降至 18ms。

但 warm pool 有副作用：内存占用恒定。我们用 cgroups v2 严格限制每个 microVM 的内存上限（ memory.max=512M ），并配置 memory.high=450M 触发内核 OOM killer。当 pool 中 microVM 数量过多时，内核会自动 kill 掉最久未使用的实例，保证宿主机稳定性。这套机制上线后，我们扛住了 3200 TPS 的瞬时洪峰，无一例超时。

4.3 Trace Store 的“雪崩”：当 ClickHouse 成为瓶颈

日志写入看似简单，但在高并发下极易成为单点瓶颈。我们曾遇到：当单日 event 量突破 800 万，ClickHouse 的 INSERT 请求开始排队，P95 延迟飙升至 2.3 秒，导致 Sandbox Manager 的 HTTP 响应超时，进而引发上游 orchestrator 重试风暴，形成恶性循环。

根因是 ClickHouse 的 ReplacingMergeTree 引擎在高写入时，后台 merge 线程会抢占大量 CPU，阻塞写入。解决方案是 双写 + 异步落库 ：

• Sandbox Manager 不直接写 ClickHouse，而是将 event 发送到 Amazon Kinesis Data Streams （吞吐无上限，P99 延迟 <100ms）。
• 启动一个 Flink 作业，消费 Kinesis 流，进行必要的数据清洗（如截断超长 input 字段），然后批量写入 ClickHouse（batch size=1000，interval=1s）。
• 同时，Flink 作业将原始 event 写入 S3 （按 year=2025/month=04/day=15/ 分区），作为永久归档和离线分析源。

这套架构将写入延迟稳定在 80ms 以内，且 S3 归档让我们能用 Athena 做任意维度的离线分析（比如“过去一周，哪些工具的 error rate > 5%？”），而 ClickHouse 专注实时查询。成本上，Kinesis + Flink + S3 的组合，比单纯扩容 ClickHouse 集群便宜 40%。

5. 未来半年必须关注的三大价值高地

5.1 Trace Store：谁掌握“agent 行为的唯一真相”，谁就掌握定价权

当 runtime 层 commoditize，trace store 就成了新的“操作系统内核”。目前市场上三家领跑者，路径截然不同：

• LangSmith ：赢在生态。它随 LangChain 自动安装，全球已有超过 200 万开发者在本地调试时默认开启 LangSmith。它的优势是“无感采集”，劣势是“深度绑定”。一旦你迁移到非 LangChain 框架（比如自研 StateGraph），LangSmith 的采集能力就大幅缩水。我们做过测试：在 LangGraph 中开启 LangSmith，采集率 99.8%；切换到自研 orchestrator 后，采集率跌至 62%，因为很多内部事件（如状态机跳转）LangSmith 无法感知。

• Arize Phoenix ：赢在开源。Apache 2.0 协议让它能被深度集成到任何 infra 中。我们将其嵌入 Sandbox Manager 的 Go 代码中，用 phoenix.Trace() 直接上报 event，绕过所有中间件。它的短板是商业版功能（如智能异常检测、根因分析）仍需付费，且 UI 对非 Python 用户不够友好。

• Brainstore ：赢在专一。它不做通用可观测平台，只做一件事：为 AI interaction logs 做极致优化的 OLAP。它的 ClickHouse 表结构针对 session_id , tool_name , error_type 做了物化视图预聚合， SELECT count(*) FROM events WHERE error_type = 'TOOL_FAILED' GROUP BY tool_name 这类查询，P99 延迟 <5ms。它的风险是太垂直，如果 trace 格式未来大变（比如加入 embedding 向量），Brainstore 的架构可能需要重写。

我的判断：未来 12 个月，胜出者将是能提供 trace portability 的那家。即：无论你用 Anthropic、AWS、还是自建 runtime，都能用同一套 SDK 采集、同一套 Schema 存储、同一套 API 查询。目前 Brainstore 和 Arize 都在推进 OpenTelemetry for AI 的 SIG，这是真正的胜负手。

5.2 Governance & Policy：从“能跑”到“敢用”的最后一道门

企业采购 agent，不再问“快不快”，而是问“安不安全”。AWS 在 March 2026 GA 的 AgentCore Policy Controls，已经给出了清晰信号。我们梳理出企业最常问的 5 个 policy 问题，以及对应的落地技术：

企业问题	技术实现方案	我们的实践
Q1：这个 agent 能不能调用生产数据库？	在 orchestrator 层插入 policy gateway，所有 tool_call 请求先过 gateway。gateway 根据 session_id 关联用户身份、 tool_name 查询预设 policy（存于 DynamoDB），若 policy 为 DENY ，则拦截并返回 PolicyViolationError 。	我们用 Open Policy Agent (OPA) 实现，policy 规则用 Rego 编写，支持 user.role == "analyst" && tool.name == "query_redshift" 这类细粒度控制。
Q2：谁批准了这个 agent 的部署？	将 agent YAML 定义存入 Git，CI/CD 流程中强制要求 PR 有至少 2 个 approver（来自 Security + Compliance 团队），approval 记录自动写入 trace store 的 policy_approval 表。	我们用 GitHub Actions + AWS CodeCommit，approval 事件触发 Lambda，将 approver , timestamp , commit_hash 写入 DynamoDB。
Q3：agent 修改了哪些文件？有没有备份？	Sandbox Manager 在执行 write_file 类工具前，自动对目标文件做 snapshot（用 rsync --checksum ），snapshot 存 S3，metadata（hash, path, timestamp）写入 trace store。	我们用 borgbackup 做增量 snapshot，单次 snapshot 耗时 <200ms，存储成本降低 70%。
Q4：这个 agent 的输出符合 GDPR 吗？	在 LLM 输出后、返回给用户前，插入 PII scrubber（用 Presidio），自动识别并脱敏 EMAIL , PHONE_NUMBER , PERSON 等实体，脱敏日志写入 trace store。	我们定制 Presidio 的 NER 模型，加入金融行业特有实体（如 ISIN_CODE , LEI_NUMBER ），准确率提升至 98.3%。
Q5：如果 agent 出错了，怎么证明我们尽到了审慎义务？	trace store 必须留存完整的 audit trail：policy decision log、PII scrubbing log、file snapshot log、以及所有人工 approval log。这些 log 必须 WORM（Write Once Read Many）存储，不可篡改。	我们用 AWS S3 Object Lock + Glacier Vault Lock，所有关键 log 写入后，立即设置 RetentionPeriod=365 days ，满足金融行业合规要求。

注意：Policy 不是加在 runtime 上的“补丁”，而是必须从 agent 设计之初就融入的 DNA。我们要求所有新工具开发，必须先定义 policy rule（存于 policy_rules/ 目录），否则 CI 拒绝构建。这确保了 policy 不是事后补救，而是设计约束。

5.3 Vertical Agent Marketplaces：当“销售线索 agent”成为标准品

Salesforce 的 Agentforce ARR 达到 $800M，这个数字背后是深刻的范式转移： 企业不再为“AI 能力”付费，而是为“解决具体业务问题的 agent”付费 。我们观察到，垂直 marketplaces 正在形成三个清晰层级：

• L1：基础能力层（Commoditized） ：PDF 解析、网页爬取、Confluence 搜索、S3 列表——这些工具已完全标准化，任何 runtime 都能跑，价格战惨烈。我们已将这类工具全部开源（GitHub: ai-agents-core ），社区贡献的 PR 比我们内部开发还快。

• L2：领域逻辑层（Differentiated） ：将基础工具组合成领域工作流。例如“医疗理赔 agent” = parse_claim_pdf + validate_icd10_codes + check_provider_network + generate_denial_letter 。这一层需要深厚的行业知识，是初创公司建立壁垒的关键。我们投资了两家医疗 AI 公司，他们的核心资产不是模型，而是这组经过 200 家医院验证的 workflow YAML。

• L3：客户集成层（Lock-in） ：将 agent 深度嵌入客户现有系统。例如，Salesforce Agentforce 不是独立 App，而是直接出现在 Sales Cloud 的 Lead 页面右侧，点击“Generate Next Steps”即可触发。这一层的壁垒最高，因为它绑定了客户的 CRM、ERP、甚至 HRIS 系统。我们为客户做的所有 agent，都强制要求提供 Salesforce Connectors、ServiceNow Integrations、Workday APIs 的标准封装，确保能一键嵌入。

我的实操体会：2026 年，最赚钱的 AI 公司，不会再是“最好的模型提供商”，而是“最懂某个垂直场景的 agent 工作坊”。他们不卖 token，卖的是经过 1000 次真实业务验证的 sales-dev-agent-v3.2.yaml 。而 runtime？不过是他们租用的 AWS EC2 实例，成本计入服务费，客户毫不知情。

6. 最后分享一个小技巧：用“自我验证”对抗 hallucination

所有 agent 系统最大的敌人，不是性能，而是 hallucination。模型编造事实、捏造工具返回、伪造引用来源——这些错误往往在 QA 环节无法发现，直到客户投诉。我们上线了一套轻量级“自我验证”机制，成本几乎为零，却将生产环境 hallucination 率从 3.2% 降至 0.17%。

原理很简单：在每个工具调用后，强制模型生成一个 verification plan 。例如，当 search_confluence 返回 3 个匹配页面时，orchestrator 不直接进入下一步，而是向模型发送：

You called search_confluence with query "Q4 compliance checklist". It returned:
- Page A: "Compliance Checklist v4.1" (URL: /wiki/compliance/q4)
- Page B: "Audit Preparation Guide" (URL: /wiki/audit/prep)
- Page C: "Regulatory Update Q4 2025" (URL: /wiki/regulatory/q4)

Verification Plan: For each page, list ONE specific fact that can be verified by visiting the URL and reading the first 200 words. Do NOT invent facts. If you cannot list a verifiable fact, output "UNVERIFIABLE".

模型必须返回类似：

Page A: "The checklist