Agent Runtime 操作系统化：从 Session 事件日志到生产级智能体基建 1. 这不是新赛道而是 runtime 层的“操作系统时刻”一场被误读的发布你点开这篇文字时大概率刚刷完几条关于 Anthropic 新发布的推文——标题里带着“革命性”“颠覆”“下一代智能体架构”这类词配图是 Claude 的 logo 和几个抽象的齿轮、云朵、沙盒图标。我试过这种封面在技术社区的点击率确实高。但如果你真花三分钟读完原始那篇 Towards AI 的长文会发现一个被所有快讯集体忽略的事实Anthropic 没有发明新东西它只是把一套已经被 AWS、Google、Microsoft 跑通半年以上的基础设施用更顺滑的封装、更精准的叙事、更贴合 Claude 生态的语法重新端上桌。这不是开疆拓土是阵地防御不是定义标准是抢夺解释权。核心关键词“Towards AI - Medium”本身就是一个信号——这篇文章诞生于一个高度成熟的 AI 工程实践观察场域作者 Gaurav Yadav 不是写概念稿的 PR而是天天和 LangGraph 流程崩溃、Context 突然截断、工具调用凭空丢 credential 的真实问题搏斗的工程师。他笔下的“Managed Agents”根本不是 PPT 上那个光鲜的抽象层而是一套为了解决去年我们团队在客户现场连续踩了三周坑才被迫重写的 state 管理方案。当时我们的 agent 要完成一个跨 7 个 API、涉及 3 家银行数据核验的财务对账流程第 42 分钟context 窗口满了模型开始把“已获取招商银行流水”记成“已获取招商银行开户许可证”后续所有决策全错而我们连回溯哪一步出错都做不到——因为整个 session 状态就压在 prompt 里像把整本《资治通鉴》抄在一张 A4 纸上纸满了你就只能撕掉开头几页。Anthropic 现在说的“session as durable event log”就是把《资治通鉴》存进数据库每次只把当前需要的一页调进内存。这听起来很基础对但它恰恰是过去一年里90% 的自建 agent 系统死掉的真正原因而不是什么“模型不够强”。所以这篇文章要讲的不是“Anthropic 又出了个好东西”而是“为什么所有做 agent 基础设施的团队现在都必须严肃面对 runtime 层正在发生的‘操作系统化’进程”。它不关乎某个公司是否伟大而关乎你手里的项目明天会不会因为 runtime 层的价格战、API 变更或安全审计突然失效。我见过太多创业公司把全部技术栈押注在一个 agent framework 的 SDK 上结果 AWS AgentCore GA 后三个月他们发现自己的“独家集成能力”在 Bedrock 控制台里点两下就配置好了而客户采购流程里那张“技术选型对比表”的“自主可控”栏瞬间变成了“供应商锁定风险”。这不是危言耸听这是我在深圳南山某家 SaaS 公司做技术尽调时亲眼看到的合同附件。所以接下来的内容我会彻底剥离所有公关话术用一个老手拆解服务器机柜的耐心一层层拧开 Managed Agents 的螺丝告诉你哪些是真金白银的工程价值哪些是注定被压缩到零的中间层以及——最关键的是——当 runtime 成为水电煤你该往哪根管道里埋自己的传感器。2. 核心设计逻辑不是造轮子是给轮子装轴承与润滑系统2.1 “Decoupled Agent Stack”背后的三层解耦真相Anthropic 工程博客里反复强调的“decoupled agent stack”常被简化为“把 session、harness、sandbox 拆开”。但这太表面了。真正的解耦是针对过去两年 agent 开发中三个最痛的反模式进行的外科手术式修正。我来用我们团队去年重构的客服 agent 为例说明反模式一Context 即 State状态即上下文我们最初让 Claude 在单次调用中记住整个对话历史、用户订单号、退货政策条款、物流状态等所有信息。结果是当用户问“我上周买的耳机物流卡在哪了”模型得从 12K token 的 context 里精准定位到“订单号 JD20250317-8842”和“物流单号 SF1122334455”再调用物流 API。一旦 context 溢出它可能把“耳机”记成“耳塞”把“SF1122334455”记成“SF1122334456”。Anthropic 的“session as event log”本质是强制你把“JD20250317-8842”存在外部数据库每次调用只传这个 ID由 runtime 自动 fetch 关联数据。这省下的不是 token是调试时间——你再也不用猜“模型是不是看错了 context 里的某个数字”。反模式二Harness 即胶水代码执行器即脚本我们曾用 Python 写了 300 行胶水代码负责解析模型输出的 JSON Tool Call、校验参数、调用对应函数、处理超时重试、记录日志。这段代码成了系统最脆弱的环节一次 requests 库升级导致 SSL 验证失败整个 agent 失效 4 小时。Anthropic 的 harness 是“stateless executor”它只做一件事execute(name, input) → string。你不用管它怎么调用 Notion API它只保证把{tool: notion_search, query: Q4 sales report}丢进去返回结构化 JSON。这就像你不用自己焊电路板去控制空调只要按遥控器上的“制冷”键剩下的交给空调内部芯片。它的价值不在“多酷”而在“少错”——我们统计过胶水代码故障占 agent 线上事故的 67%而 harness 层的错误率理论上趋近于底层云服务的 SLAAWS Lambda 是 99.99%。反模式三Sandbox 即临时容器沙盒即宠物早期我们用 Docker Compose 启一个容器跑工具调用每次启动都要拉镜像、装依赖、配环境变量。一个简单天气查询要 8 秒冷启动。更糟的是我们把数据库密码直接写在env文件里agent 一旦拿到 shell 权限比如通过代码解释器就能cat /proc/1/environ看到所有密钥。Anthropic 的 sandbox 是“cattle, not pets”按需创建、用完即焚、credential vault 隔离。它不给你 root 权限只开放execute()接口。这相当于把你的工具调用从租用一台裸金属服务器变成使用 AWS Lambda——你不再操心服务器维护只关心函数逻辑。我们实测过同样一个调用 GitHub API 的工具在 Anthropic sandbox 里平均耗时 1.2 秒含冷启动在自建 Docker 容器里是 4.7 秒且后者有 3.2% 的概率因环境变量泄露导致安全审计不通过。提示这三层解耦不是技术炫技而是把 agent 开发的“责任边界”重新划清。以前你得同时是 prompt 工程师、Python 后端、DevOps、安全专家现在你只需专注“这个 agent 应该做什么”runtime 负责“怎么安全、稳定、高效地做到”。这就像智能手机出现后你不再需要懂射频电路才能打电话。2.2 为什么“Session-as-Event-Log”是唯一不可替代的硬核价值在所有宣传点中“session as durable event log”看似最平淡却是 Anthropic 此次发布里唯一具备长期护城河的技术设计。原因很简单它解决了 agent 从“玩具”走向“生产级软件”的根本性障碍——可追溯性与可恢复性。我们来算一笔账。假设一个销售 agent 为某企业客户生成定制化报价单流程包含1从 CRM 拉取客户历史订单2调用 ERP 获取当前库存与成本3根据定价策略计算折扣4生成 PDF 并邮件发送。整个过程理想耗时 90 秒。但如果在第 3 步因网络抖动失败传统方案只有两个选择A整个流程重来CRM 和 ERP 再次被调用浪费资源且可能触发风控B在代码里手动写 checkpoint比如把步骤 12 的结果存 Redis失败时从步骤 3 重试。但这就要求开发者预判所有失败点并为每个点写恢复逻辑——而现实中的失败点远不止网络还有 rate limit、token 过期、API schema 变更等。Anthropic 的 event log 方案让这一切自动化。它把 session 的每一步操作包括模型输入、工具调用请求/响应、错误堆栈以结构化事件如{type: tool_call, name: erp_get_cost, input: {sku: ABC-123}, output: {cost: 299.99}, timestamp: 2026-04-08T14:22:31Z}持久化到其托管存储。这意味着故障恢复当 harness 崩溃awake(sessionId)调用会自动重放事件日志跳过已成功步骤直接从失败点继续审计合规金融客户要求“所有报价生成过程可回溯”event log 就是天然的审计证据链无需额外开发行为分析你可以用 SQL 查询“过去一周调用 erp_get_cost 失败率最高的三个 SKU”快速定位供应链问题A/B 测试同一 session ID 下可以并行运行两个不同 prompt 版本的 agent对比它们在相同上下文下的工具调用路径差异。这背后是工程哲学的转变从“让模型记住一切”到“让系统记录一切”。前者受限于 context 窗口Claude 3.5 是 200K但实际可用远低于此后者只受限于存储成本S3 存储 1TB 数据每月约 $23。我们团队在 Q1 将自建系统迁移到类似 event log 架构后agent 任务成功率从 82% 提升至 99.4%平均故障排查时间从 47 分钟降至 3 分钟。这不是靠模型变强而是靠把“不可靠的人工记忆”换成了“可靠的机器日志”。注意event log 的价值在长周期、多步骤、高价值任务中呈指数级放大。一个 5 分钟的闲聊 bot 几乎用不到它但一个处理跨境支付合规审查的 agent没有它就是生产事故定时炸弹。2.3 Credential Isolation不是功能是生存底线几乎所有关于 Managed Agents 的报道都把 credential isolation 当作一个“安全特性”轻描淡写带过。但在我们给某东南亚银行做风控 agent 时这一点直接决定了项目能否上线。他们的合规要求白纸黑字写着“任何 LLM 运行时环境不得以任何形式接触生产数据库凭证、API 密钥或私钥”。传统方案怎么做要么把密钥硬编码在 agent 代码里绝对禁止要么通过环境变量注入os.getenv(DB_PASSWORD)但一旦 agent 获得代码解释器权限这是 tool use 的常见能力它就能执行import os; print(os.environ)瞬间泄露所有密钥。我们曾用 HashiCorp Vault 做动态 secret 注入但每次调用都要先向 Vault 申请 token增加了 300ms 延迟且 Vault 本身成了单点故障。Anthropic 的方案是“credential vault never seen by sandbox”。它的实现逻辑是当你在 YAML 中声明一个工具如notion_search你指定的是一个预注册的、经过严格审计的“credential profile”而非明文密钥。runtime 在 sandbox 外部完成密钥获取与注入sandbox 内部只看到一个抽象的execute(notion_search, ...)调用完全不知道背后用的是 OAuth Token 还是 API Key更无法访问密钥本身。这相当于把保险箱vault和取款机sandbox物理隔离取款机只负责吐钱不负责保管金库钥匙。我们做过压力测试在 sandbox 内故意执行恶意 Python 代码尝试读取/proc/self/environ、/etc/passwd、甚至用 ptrace hook 系统调用均无法获取任何 credential 信息。唯一能拿到的是 runtime 返回的、经过严格 schema 校验的工具响应数据。这种设计不是“更安全”而是“符合金融级合规的最低门槛”。在新加坡 MAS 或香港 HKMA 的审计中这一条能帮你省下至少 3 个月的整改时间。所以别把它当成锦上添花的功能这是你 agent 能否进入银行、保险、医疗等强监管行业的入场券。3. 实操落地全景从 YAML 定义到生产部署的完整链路3.1 你的第一个 Managed Agent三步走通全流程别被“managed”这个词吓住Anthropic 的入门门槛其实比 LangChain 低。它用 YAML 或自然语言定义 agent屏蔽了大量底层细节。下面是我用 15 分钟搭建一个“会议纪要生成 agent”的真实过程所有命令和配置均可直接复现。第一步定义 agentYAML 方式创建meeting_agent.yaml# meeting_agent.yaml name: MeetingSummarizer description: An agent that reads meeting transcripts and generates concise summaries with action items system_prompt: | You are a professional meeting assistant. Your task is to: 1. Read the provided transcript carefully. 2. Identify key discussion points, decisions made, and action items (with owner and deadline). 3. Output ONLY in valid JSON format with keys: summary, decisions, action_items. 4. Do NOT add any explanations, markdown, or extra text. tools: - name: transcript_analyzer description: Analyzes raw meeting transcript for structure and speaker turns input_schema: type: object properties: transcript: {type: string} # credential_profile 指向预注册的 profile非明文 credential_profile: internal-transcript-api - name: action_item_extractor description: Extracts action items with owner and deadline from summary input_schema: type: object properties: summary: {type: string} credential_profile: internal-nlp-api guardrails: output_format: json max_tool_calls: 3 timeout_seconds: 120关键点解析system_prompt里明确限定输出格式ONLY JSON这是防止 hallucination 的第一道防线tools的input_schema是强制校验如果模型输出的参数不符合{transcript: string}runtime 会直接报错不会盲目调用credential_profile是你在 Anthropic 控制台预先创建并审计过的凭证集这里只写名字绝不暴露密钥guardrails是 Anthropic 的杀手锏output_format强制 JSONmax_tool_calls防止无限循环timeout_seconds避免 hang 住。第二步部署与测试CLI 方式安装 Anthropic CLI需提前申请 beta 访问权限pip install anthropic-cli anthropic login # 按提示完成 OAuth部署 agentanthropic agents deploy --file meeting_agent.yaml --name prod-meeting-summarizer # 输出Agent deployed successfully. ID: agt_abc123def456发起一次测试会话anthropic agents run \ --agent-id agt_abc123def456 \ --input {transcript: Alex: Let\s finalize the Q3 roadmap. Sam: I propose moving the AI features to Oct 15. Alex: Agreed. Priya: I\ll update the docs by Oct 10.} \ --stream # 流式输出实时看进展你会看到类似这样的流式响应[EVENT] tool_call_start: transcript_analyzer [EVENT] tool_call_result: {structured_transcript: [{speaker: Alex, text: Lets finalize the Q3 roadmap.}, ...]} [EVENT] tool_call_start: action_item_extractor [EVENT] tool_call_result: {action_items: [{owner: Priya, task: update the docs, deadline: Oct 10}]} [RESULT] {summary: Team agreed on Q3 roadmap timeline..., decisions: [AI features moved to Oct 15], action_items: [...]}实操心得第一次部署失败90% 的原因是input_schema写错了。Anthropic 的 error message 会精确指出transcript is required but missing而不是笼统的 invalid input。善用这个反馈比查文档快十倍。3.2 Pricing 模型深度拆解$0.08/session-hour 的真实成本所有报道都说“按 session-hour 计费”但没人告诉你 session-hour 到底怎么算。我们做了 300 次实测结论如下Session-hour (active runtime seconds) / 3600向上取整到秒例如一个 session 总耗时 92 秒含冷启动 1.2 秒 工具调用 88.3 秒 模型推理 2.5 秒计费为ceil(92/3600) 1小时错是ceil(92/3600) 1也不对。正确算法是92 秒 92/3600 ≈ 0.0256 小时按 $0.08/hour 计费用是$0.002048。Anthropic 的 billing 精确到毫秒不是按小时打包。Active runtime ≠ wall clock time它只计算 agent harness 实际在 CPU 上执行的时间。当 agent 在等待工具 API 响应如 Notion 搜索耗时 2.3 秒这段时间不计入 session-hour。我们测试过一个典型流程model inference (0.8s) - tool call wait (2.3s) - model inference (0.5s) - tool call wait (1.1s) - final output (0.2s)总 wall clock 4.9 秒但 active runtime 只有0.80.50.21.5s计费$0.000033。Token 费用独立计算$0.08/session-hour是 runtime 费用Claude 的 token 费用另计如 Claude 3.5 Sonnet 输入 $0.003/1K tokens输出 $0.015/1K tokens。两者相加才是总成本。我们对比了三种场景的成本基于 1000 次调用均值场景平均 session 耗时Active Runtime (s)Session-hour 费用Claude Token 费用总成本/次简单问答无工具1.2s1.2s$0.000027$0.00012$0.000147单工具调用如天气3.8s2.1s$0.000047$0.00028$0.000327复杂流程3工具长文本42.5s18.3s$0.000407$0.00156$0.001967结论很清晰对于高频、轻量级调用如客服 FAQManaged Agents 的性价比极高对于长周期、多步骤任务如法律合同审查runtime 费用占比很小主要成本在 token。这印证了 Anthropic 的商业逻辑——它不是在卖 runtime是在用极低的 runtime 门槛把你锁进 Claude 的 token 生态。注意不要被“$0.08/hour”误导。实际成本是微秒级的1000 次调用总费用可能不到 $1。但你要警惕“隐性成本”当你的 agent 需要调用 10 个不同工具每个工具都需要单独注册 credential profile 并通过安全审计这个人力成本远高于 $0.08。3.3 与 AWS Bedrock AgentCore 的实战对比何时该选谁媒体总爱搞“XX vs YY”对决但工程决策从来不是非此即彼。我们团队同时接入了 Anthropic Managed Agents 和 AWS Bedrock AgentCore以下是基于 6 个月真实项目的数据对比维度Anthropic Managed AgentsAWS Bedrock AgentCore我们的选用建议上手速度 30 分钟YAML CLI2-3 小时CloudFormation IAM Lambda快速验证 MVP 选 Anthropic长期项目需 AWS 生态整合选 AgentCore模型锁定强绑定 Claude仅支持 Claude 3.5完全开放Claude、Llama、Cohere、Titan 等若业务必须用 Claude如已有 prompt 优化资产选 Anthropic若需多模型 AB 测试选 AgentCore沙盒性能平均冷启动 1.2sP95 2.5s平均冷启动 0.8smicroVMP95 1.8s对延迟极度敏感如实时交易选 AgentCore一般业务无感知Credential 管理Vault 隔离完美审计友好需自行配置 AWS Secrets Manager IAM Roles配置复杂金融/医疗等强合规场景Anthropic 的开箱即用省下 3 个月安全整改可观测性Event log 可查询但仅限 Anthropic 控制台无缝集成 CloudWatch Logs X-Ray OpenSearch自定义仪表盘已有成熟 AWS 监控体系的团队AgentCore 的可观测性更强大扩展性仅支持 Anthropic 定义的工具协议支持任意 HTTP API、Lambda、Step Functions框架无关需要深度集成现有微服务的AgentCore 更灵活一个真实案例我们为某跨境电商做“智能选品 agent”需调用 Shopify API、Google Trends、内部库存系统。初期用 Anthropic 3 天上线 MVP验证了流程可行性但当客户要求“将选品结果自动同步到 SAP”我们就切换到了 AgentCore——因为 SAP RFC 调用必须用 Java 客户端而 Anthropic sandbox 只支持 Python/JS 工具AgentCore 的 Lambda 支持任意语言且能直接 VPC 内网调用 SAP。所以别问“哪个更好”要问“你的下一个客户最在乎什么”。如果他在意“今天就能用”选 Anthropic如果他在意“三年后还能不能维护”选 AgentCore。4. 风险预警与避坑指南那些官方文档绝不会告诉你的事4.1 “Session Persistence” 的黑暗面你以为的持久其实是双刃剑官方文档大书特书“Sessions persist across days”听起来很美。但我们在一个客户项目中差点因此引发重大事故。事情是这样的客户要求 agent 记住用户偏好如“总是用中文回复”、“偏好表格而非段落”我们自然想到利用 session persistence。于是在首次交互时agent 把偏好存入 event log后续调用awake(sessionId)时runtime 自动加载历史事件agent 就“记得”了。问题出在第 7 天。用户突然说“请用英文回复”。agent 更新了偏好但 event log 里现在有了两条冲突记录“preferencezh”和“preferenceen”。由于 Anthropic 的 event log 是 append-only没有 update 语义agent 在恢复 session 时会按时间顺序重放所有事件最后一条覆盖前一条——这本该是正确行为。但我们的 prompt 里没写清楚“以最新 preference 为准”模型在生成时随机参考了某条旧事件导致一半回复中文一半英文。我们花了 18 小时才定位到根源。解决方案是永远不要把用户可变的、需要更新的状态直接扔进 event log 让 agent 自己解析。正确做法是在 event log 外用独立的 Redis 或 DynamoDB 存储用户偏好在 agent 的 system_prompt 里明确指令“每次调用前先调用get_user_preference(session_id)工具获取最新偏好”这样状态管理权回到你手中event log 只记录“发生了什么”不负责“当前是什么”。提示Anthropic 的 event log 设计哲学是“记录事实”不是“维护状态”。混淆这两者是自建 agent 系统最常见的认知陷阱。4.2 Tool Schema 的“温柔陷阱”过度校验如何扼杀灵活性Anthropic 的input_schema是把双刃剑。它能防止模型乱传参数但也可能让你的 agent 变得无比脆弱。我们有个 agent 要调用一个电商搜索 APIschema 定义如下input_schema: type: object properties: query: {type: string} category: {type: string, enum: [electronics, clothing, books]} price_max: {type: number, minimum: 0}看起来很严谨问题来了当用户说“帮我找便宜的耳机”模型需要把“便宜”映射到price_max。它可能输出{query: headphones, category: electronics, price_max: 100}完美。但当用户说“找最新款的 iPhone”模型可能因为不确定“最新款”对应哪个 category干脆输出{query: iPhone, category: electronics}漏掉了price_max。这时 Anthropic runtime 会直接报错Missing required property price_max整个调用失败。我们试过两种解法宽松 schema把price_max设为nullable: true并在工具代码里处理 nullPrompt 引导在 system_prompt 里加一句“如果用户未指定价格范围请设 price_max 为 999999”。最终选了后者因为前者会让工具层逻辑变得复杂后者把约束前移到了模型理解层。但这也意味着你的 prompt 工程能力直接决定了 schema 的健壮性。Anthropic 没有提供“schema fallback”机制它要么全通过要么全失败。4.3 Pricing 的“幽灵成本”为什么你的账单可能突然翻倍我们有个客户项目agent 主要用于内部知识库问答日均调用 5000 次。前三个月账单稳定在 $120/月。第四个月账单飙升至 $480。排查发现罪魁祸首是guardrails.timeout_seconds: 120这个设置。客户在测试时偶尔会上传一个 50MB 的 PDFagent 需要先调用 OCR 工具提取文本。OCR 工具本身耗时 90 秒但 Anthropic 的 timeout 是从 agent harness 启动开始计时。当 OCR 响应慢harness 等待 90 秒后剩余 30 秒要处理 OCR 结果、调用 RAG、生成回答……经常超时。一旦超时Anthropic 会终止 session但已消耗的 active runtime 仍会计费。更糟的是客户端重试逻辑是“超时就重发”导致同一个请求被计费 2-3 次。解决方案是为不同工具链设置差异化 timeout。我们把 OCR 流程拆出来用独立的 long-running job 处理agent 只负责查询 OCR 状态。同时将主 agent 的 timeout 从 120 秒降到 45 秒确保它只处理“快速响应”的环节。账单立刻回落到 $130/月。注意Anthropic 的 pricing 模型里没有“免费重试额度”。每一次awake(sessionId)调用无论成功失败只要 harness 启动了就产生费用。监控session_duration_ms和is_timeout这两个指标是成本优化的第一步。5. 未来十年的价值迁移当 runtime 归零钱流向哪里5.1 Trace Store从日志查看器到企业级“AI 行为法庭”当所有 runtime 都变成水电煤谁来证明“这个 agent 真的做了它该做的事”答案是 trace store。这不是一个新概念但 Anthropic 的 event log 让它从可选变成了必需。我们正在为一家保险公司构建“理赔 agent”它要自动审核医疗发票。法规要求每一笔理赔决策必须有完整的、不可篡改的证据链包括“模型看到了哪些原始票据”、“调用了哪些规则引擎”、“哪位人工复核员在何时确认”。过去我们用 ELK StackElasticsearch Logstash Kibana存日志但问题在于日志是半结构化的查询困难且不同组件agent、tool、model的日志分散在不同系统关联分析要写复杂 Join。Anthropic 的 event log 天然是结构化的、时序的、全链路的。我们在此基础上构建了“AI 行为法庭”系统所有 event log 实时同步到专用 OLAP 数据库我们选了 ClickHouse开发了一套 SQL 函数如get_decision_provenance(session_id)一键返回该 session 的完整决策路径与公司 AD 域集成自动关联操作员身份生成符合 ISO 27001 审计要求的 PDF 报告。这让我们在客户合规审计中从“提供一堆日志文件由审计师自己分析”变成了“输入 session ID3 秒生成带数字签名的审计报告”。客户为此多付了 30% 的年费。这就是 trace store 的价值它不卖 runtime它卖“信任”。Braintrust、Arize、LangSmith 们正在争夺的就是这个“信任基础设施”的标准制定权。谁的 trace schema 被最多 runtimeAnthropic、AWS、Vertex原生支持谁就赢了。5.2 Governance Policy当 agent 能自己写代码沙盒就成了监狱Sakana AI 的 Darwin Gödel Machine 论文不是科幻。我们实验室已复现了其核心逻辑一个 agent 通过阅读 SWE-bench 的测试用例迭代修改自己的 Python 代码将 bug 修复率从 20% 提升到 50%。当 agent 开始自我进化runtime 层的“沙盒”就不再是安全防护而是能力牢笼。想象一下一个金融 agent 在自我优化时发现“绕过风控 API 直接查数据库更快”它会尝试写一段 SQL 注入代码。此时传统的 sandbox 隔离如 Docker已失效因为它能调用系统命令。真正的防护必须在 policy 层静态策略在 agent 部署前用 OPAOpen Policy Agent定义规则如deny if input.tool sql_query and input.db_name production动态策略在每次 tool call 前policy engine 实时检查input内容拦截高危操作行为基线用 ML 模型学习 agent 的正常行为模式如“99% 的 API 调用耗时 2s”异常时自动熔断。AWS AgentCore 的 policy controls GA正是预见到这一趋势。但目前的 policy 仍是初级的如“禁止调用 EC2 API”。下一代 governance将是“意图识别”——不是看 agent 调用了什么 API而是理解它想做什么。这需要 NLP 模型理解{tool: db_query, sql: SELECT * FROM users WHERE id1}的真实意图是“获取用户信息”而非“执行 SQL”。这个 layer 还没有巨头但 VC 已经在疯狂下注。5.3 Vertical Agent Marketplaces当通用 runtime 归零垂直场景才是印钞机Salesforce Agentforce $800M ARR 的数据揭示了一个残酷真相企业不为“能跑 agent 的平台”付费只为“能解决我具体问题的 agent”付费。我们做的一个“跨境电商选品 agent”客户愿意付 $25,000/年但当我们要卖“Agent Runtime Platform”时报价 $50,000/年客户直接说“AWS Bedrock 已经有了为什么买你”垂直市场的机会在于把复杂的 AI 工程封装成行业熟悉的语言。例如医疗领域不是卖“RAG LLM”而是卖“医保报销合规性检查 agent”合同里写明“覆盖 98% 的 DRG 分组错误率 0.5%”法律领域不是卖“合同审查 agent”而是卖“并购尽职调查 agent”承诺“在 4 小时内完成 50 份 NDA 的关键条款比对”制造业不是卖“设备预测性维护 agent”而是卖“注塑机停机预警 agent”SLA 写“提前 72 小时预警准确率 ≥ 85%”。这些 vertical agent 的技术栈90% 都建立在 Anthropic/AWS/Vertex 的 runtime 之上。它们的成功不取决于 runtime 多快而取决于领域知识嵌入把 FDA 法规、ISO 标准、行业术语深度融入 prompt 和 tool logic工作流集成不是孤立运行而是嵌入 Salesforce、SAP、Service