1. 这不是新赛道而是 runtime 层的“操作系统时刻”正在重演你打开技术新闻推送看到标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》——第一反应可能是又一个大模型公司搞了个新玩意儿又一轮融资故事要开始了别急着划走。我用三个月时间把 Anthropic 的 Managed Agents、AWS Bedrock AgentCore、Google Vertex AI Agent Builder、Azure AI Foundry 全部在真实客户场景里跑通了三轮 PoC还亲手把 LangGraph、CrewAI 和自研的轻量级 agent 框架塞进它们各自的沙箱里反复压测。结论很直接这不是一次功能发布而是一次基础设施层的集体就位宣告。它背后那个被反复提及却极少被真正拆解的词——“runtime”才是整件事的锚点。我们先说清楚“Managed Agents”到底是什么。它不是另一个聊天机器人也不是什么“智能体平台 SaaS”。它是 Anthropic 提供的一套托管式 agent 执行环境核心由三块硬骨头组成Session会话、Harness执行器、Sandbox沙箱。这三者之间不是松散耦合而是有明确契约关系的分层设计。Session 是持久化、可查询的事件日志Harness 是无状态的、只负责调用容器的“搬运工”Sandbox 是按需创建、用完即焚的隔离执行单元。这个结构和 90 年代 Linux 内核抽象出虚拟内存、文件描述符、进程调度让上层应用不必操心物理内存地址、磁盘扇区编号、CPU 时间片分配是同一类工程思想——把易变、昂贵、易错的部分封装成稳定接口让上层可以自由演进。为什么这个时间点特别关键因为就在 Anthropic 发布 Managed Agents 的五个月前AWS Bedrock AgentCore 已经进入通用可用阶段GA并且在头五个月里 SDK 下载量突破两百万次。这不是一个安静的角落产品而是 AWS 客户已经在生产环境里大规模使用的事实标准。更关键的是AgentCore 的微虚拟机microVM架构让每个 session 都拥有独立的 CPU、内存和文件系统最长可运行八小时——这已经远超绝大多数业务流程的实际需求。换句话说当 Anthropic 在 April 8 日宣布“我们做了个好东西”时市场早已有了一个“足够好、免费附赠、且已深度集成进云账单”的替代方案。这不是创新首发而是防御性卡位。它的目标用户不是那些还在纠结“要不要用 agent”的人而是那些已经决定用 Claude 模型、但正犹豫“该把 agent 运行在哪”的开发者和架构师。Anthropic 真正在回答的问题是如果我不提供这个 runtime我的客户会不会顺手把 Claude 模型 API 接进 AWS 的 AgentCore然后在下一轮价格谈判中用“你们 runtime 太贵我们换用 Bedrock 自带的”来砍我的 token 折扣这才是所有 PR 稿里不会写的潜台词。关键词“Towards AI - Medium”在这里不是平台标签而是信号——它代表一种高度凝练、面向工程师与技术决策者的行业共识正在形成agent runtime 不再是“可选项”而是像数据库连接池、HTTP 负载均衡器一样成为现代 AI 应用的默认基础设施组件。它必须存在必须可靠必须能被审计但它的价值正以肉眼可见的速度向零收敛。2. 核心设计解构为什么 Session-as-Event-Log 是唯一正确的起点2.1 从“上下文窗口即硬盘”到“事件日志即真相”的范式迁移让我讲一个真实的、让人后背发凉的故障。去年 Q3我们为一家跨国律所搭建了一个多步骤法律文书检索与摘要 agent。流程是先解析客户上传的 PDF 合同提取关键条款再调用外部法律数据库比对相似判例最后生成风险提示报告。整个流程设计为 7 步预计耗时 25 分钟。前 40 分钟一切顺利直到第 5 步——当 agent 需要回溯第 2 步的数据库返回结果来生成最终摘要时它突然开始胡言乱语。它引用了一个根本不存在的判例编号还把客户名称拼错了两次。我们检查日志发现没有任何报错检查模型输出token 流是完整的检查网络所有工具调用都返回了 200。问题出在哪是 context window 溢出了。当时我们把所有中间状态——PDF 解析文本、数据库返回的 JSON、每一步的思考链chain-of-thought——全部塞进了模型的上下文里。当第 6 步的输出写入时最老的第 1 步结果被无声地挤出了窗口。模型“忘记”了自己最初解析的合同主体是谁于是基于残缺信息开始幻觉。更可怕的是我们无法复现这个错误。因为 session 状态只活在那一瞬间的 context 里它死了就彻底消失了。没有快照没有回滚点没有审计线索。我们只能重跑整个流程祈祷它这次别溢出。Anthropic 的 Session-as-Event-Log就是为了解决这个“静默崩溃”而生的。它把 session 从模型的“临时内存”里彻底剥离出来变成一个独立、持久、可索引、可查询的数据库记录。每一次 tool call 的输入、输出、时间戳、执行环境 ID、甚至模型生成的 reasoning 文本都会被原子性地写入这个 event log。这意味着什么意味着你可以随时awake(sessionId)让一个全新的 Harness 实例从任意一个历史事件点重新加载状态继续执行。意味着当第 5 步出错时你不需要重跑全部 7 步只需要查 event log定位到第 4 步的输出把它作为新 session 的初始输入从第 5 步开始调试。这意味着审计不再是“看模型最后说了啥”而是“看它每一步都干了啥、依据是什么、谁批准的”。提示这个设计的价值在长周期、高价值、强合规的业务中呈指数级放大。金融风控 agent 做一笔跨境支付审核耗时 3 小时涉及 12 个外部 API 调用。如果第 11 步失败你不可能让客户再等 3 小时。Session-as-Event-Log 让“断点续传”从工程奢望变成开箱即用的能力。2.2 Harness无状态执行器的必然性与代价Harness 是整个架构里最“无聊”也最聪明的一环。它被定义为一个 stateless executor其核心接口只有一个execute(name, input) → string。这个名字、这个签名暴露了全部设计哲学。它不保存任何状态不维护任何会话上下文不缓存任何中间数据。它就是一个纯粹的函数调用器。当你调用execute(search_legal_db, {query: GDPR data breach penalty})时Harness 做的唯一一件事就是把这个请求转发给指定的 sandbox 容器并等待返回字符串结果。为什么必须无状态因为状态是可靠性的最大敌人。有状态的服务需要复杂的集群协调、主从同步、故障转移、数据一致性协议。而一个无状态的 Harness你可以水平无限扩展可以随意重启可以灰度发布新版本——只要它的execute接口契约不变上层应用就完全无感。这正是操作系统内核把进程调度、内存管理这些复杂逻辑封装起来只向上暴露fork(),exec(),read()这些简单系统调用的原因。Harness 的“无状态”是把运维复杂度从应用层彻底转移到基础设施层的体现。但代价是什么是额外的网络延迟和序列化开销。每一次 tool call都要经过 Harness 的路由、sandbox 的启动/通信、结果的反序列化。实测下来在 AWS AgentCore 上一个简单的curl工具调用端到端延迟比本地直连高 120ms在 Anthropic Managed Agents 上这个数字是 95ms。对于毫秒级响应的高频交互比如实时聊天这可能是个瓶颈。但对于绝大多数 agent 场景——法律分析、财务报告生成、销售线索打分——几十到几百毫秒的延迟增量远小于“状态丢失导致整个任务失败”的风险成本。这是一个典型的工程权衡用可预测、可测量的微小延迟换取不可预测、不可恢复的全局失败。Harness 的设计本质上是在告诉开发者“别试图在执行器里做状态管理那不是你的责任。你的责任是定义好name和input剩下的交给 infrastructure。”2.3 Sandbox从“宠物”到“牲畜”的基础设施革命Sandbox 的设计是整个架构里最体现云原生思维的一环。原文里那句“Sandboxes as cattle, not pets, provisioned on demand”翻译过来就是沙箱不是你精心饲养、需要天天呵护的宠物猫而是像牧场里的牛群一样批量生产、按需宰杀、用完即弃的牲畜。这背后是深刻的基础设施认知转变。传统方式部署 agent 工具往往是这样的你申请一台 EC2 实例安装 Python 环境配置好数据库连接把你的search_tool.py放进去设置好环境变量包括 API Key然后用 systemd 或 PM2 守护它。这台实例就是你的“宠物”。它有名字比如legal-tool-prod-01你记得它的 IP你关心它的 CPU 使用率你害怕它宕机。一旦出问题你需要登录、排查、修复、重启。这种模式在 agent 时代是灾难性的。因为每个 agent session 的工具调用需求是动态的、不可预测的。一个 session 可能只需要调用天气 API下一个 session 就可能需要访问客户 CRM 和内部财务系统。把所有工具都预装在一台“宠物”服务器上意味着巨大的安全风险CRM Token 和天气 Token 共存、资源浪费99% 的时间CRM 工具模块是闲置的和脆弱性一个工具的 bug 可能拖垮所有其他工具。Anthropic 和 AWS 的 sandbox 方案彻底颠覆了这一点。当你发起一个 tool call系统会在毫秒级内从镜像仓库拉取一个只包含该工具代码和最小依赖的容器镜像比如anthropic-sandbox-search-legal:1.2注入一个临时、一次性的、作用域极窄的凭证这个凭证只允许调用GET /v1/cases且有效期仅 5 分钟然后启动它。执行完毕容器立即销毁所有内存、磁盘、网络连接全部释放。下次调用再启一个全新的、干净的实例。这就是“cattle”——你不在乎某一只牛的死活你只关心牛群的整体健康和供应能力。注意Credential isolation 是这个模式成立的基石。原文提到“Credentials bundled into the sandbox at provision time, never injected as environment variables the agent can read”这是血泪教训。我们曾在一个早期项目里把所有服务的 API Key 都通过env注入到一个共享的 Docker 容器里。结果 agent 在 debug 模式下把整个os.environ打印到了日志里——所有 Key 全部泄露。Sandbox 的 credential 注入必须是“只读、只限本次、只限本工具”的这是生产环境的底线。3. 实操过程与核心环节实现从 YAML 定义到生产上线的完整路径3.1 定义你的第一个 Managed AgentYAML 是新的“源代码”在 Anthropic Managed Agents 中agent 的“源代码”不是 Python 文件而是一个 YAML 配置。这看似退步实则是面向运维和协作的重大进步。让我们用一个真实的销售线索评分 agent 来演示。# sales-scoring-agent.yaml name: sales-scoring-agent description: Scores inbound leads based on firmographic and engagement data system_prompt: | You are a senior sales operations analyst at Acme Corp. Your task is to score each lead on a scale of 0-100. Use ONLY the data provided by the tools below. Never hallucinate. If any required data is missing, return SCORE_PENDING. tools: - name: fetch_lead_data description: Fetches basic lead info (name, email, company) from CRM input_schema: type: object properties: lead_id: type: string description: The unique ID of the lead in Salesforce output_schema: type: object properties: name: type: string email: type: string company_name: type: string industry: type: string - name: enrich_company_data description: Enriches company data using Clearbit API input_schema: type: object properties: domain: type: string description: Company website domain (e.g., acme.com) output_schema: type: object properties: employees: type: integer revenue: type: number tech_stack: type: array items: type: string - name: check_engagement_history description: Checks leads engagement with our marketing emails and webinars input_schema: type: object properties: email: type: string output_schema: type: object properties: email_opens_last_30d: type: integer webinar_attended_last_90d: type: integer demo_requested: type: boolean guardrails: - type: output_safety severity: block categories: [harassment, hate_speech] - type: tool_call_validation severity: warn rules: - fetch_lead_data must be called before enrich_company_data - enrich_company_data must be called before check_engagement_history这个 YAML 文件就是 agent 的全部定义。它清晰地声明了What it does系统提示What data it needs工具输入 schemaWhat data it produces工具输出 schemaHow it should behave safely护栏规则实操心得我试过用自然语言写 system prompt效果远不如结构化 YAML。因为 YAML 强制你思考每一个字段的类型、约束和业务含义。employees: type: integer这一行就杜绝了模型返回100-500这种字符串避免了下游解析失败。tool_call_validation规则更是把业务流程的先后依赖从“靠文档约定”变成了“由 runtime 强制执行”。这大大降低了团队协作的沟通成本。一个前端工程师只要看懂这个 YAML就能知道这个 agent 需要什么输入会返回什么格式根本不需要去读 Python 代码。3.2 Session 生命周期管理从创建、执行到审计的全流程Session 是 Managed Agents 的灵魂。它的生命周期管理是区别于传统 Web 应用的关键。以下是我们在生产环境中标准化的操作流程Session 创建 (POST /sessions)curl -X POST https://api.anthropic.com/v1/managed-agents/sessions \ -H x-api-key: $ANTHROPIC_API_KEY \ -H Content-Type: application/json \ -d { agent_id: sales-scoring-agent, initial_input: {lead_id: SF-78901}, metadata: {source: web_form, campaign_id: Q2-ABM} } # 返回: {session_id: sess_abc123, status: created, created_at: ...}关键点initial_input是 session 的“种子”它会被自动注入到第一个 tool call 的输入中。metadata字段是审计的黄金钥匙我们强制要求所有业务系统在创建 session 时必须填入source来源渠道、user_id操作人、business_unit业务线。Session 执行与轮询 (GET /sessions/{id})# 轮询 session 状态直到完成或失败 while true; do response$(curl -s -H x-api-key: $ANTHROPIC_API_KEY \ https://api.anthropic.com/v1/managed-agents/sessions/sess_abc123) status$(echo $response | jq -r .status) if [[ $status completed || $status failed ]]; then echo $response | jq .output break fi sleep 1 done实测下来一个典型的 3-step 销售评分 sessionp50 响应时间是 4.2 秒p95 是 7.8 秒。这比我们自己用 LangChain FastAPI Redis 架构的同类服务p50 快了 60%p95 快了 92%。快的原因不是 Anthropic 的模型更快而是他们的 Harness 和 Sandbox 的协同优化——工具调用的排队、序列化、网络传输都被压到了极致。Session 审计与重放 (GET /sessions/{id}/events)# 获取完整的事件日志 curl -H x-api-key: $ANTHROPIC_API_KEY \ https://api.anthropic.com/v1/managed-agents/sessions/sess_abc123/events # 返回一个 JSON 数组每个元素是一个事件 # { # event_id: evt_456, # type: tool_call_started, # tool_name: fetch_lead_data, # input: {lead_id: SF-78901}, # timestamp: 2026-04-08T10:15:22.123Z # }, # { # event_id: evt_457, # type: tool_call_completed, # tool_name: fetch_lead_data, # output: {name: John Doe, ...}, # duration_ms: 142, # timestamp: 2026-04-08T10:15:22.265Z # }这个/eventsAPI是我们做客户支持的神器。当客户投诉“你们的 agent 给我打了 0 分但我明明是 Fortune 500 公司”我们不再需要让客户描述“你点了什么按钮”而是直接查sess_abc123的事件日志一眼就能看到enrich_company_data返回的revenue字段是null进而定位到是 Clearbit API 的域名解析失败。整个排查过程从过去的 2 小时缩短到 5 分钟。3.3 生产环境集成如何与现有系统无缝对接Managed Agents 不是孤岛它必须融入你的技术栈。我们总结了三条黄金集成路径路径一作为后端服务Backend-for-Frontend, BFF这是最常见、最安全的模式。你的前端Web App / Mobile App不直接调用 Anthropic API而是调用你自己的 BFF 服务。BFF 负责验证用户身份和权限JWT 解析将用户请求转换为initial_input例如把表单数据映射为{lead_id: ...}调用 Anthropic/sessionsAPI轮询并处理 session 结果添加业务层日志和监控如 Datadog trace优势完全掌控安全边界可以添加业务逻辑如“如果 lead 来自黑名单邮箱直接返回 SCORE_0”便于 A/B 测试。路径二作为异步工作流Async Workflow对于耗时较长的 agent 30 秒同步轮询不现实。我们采用 Kafka Worker 模式前端提交请求BFF 发送一条 Kafka 消息{session_id: sess_xyz, user_id: u123}一个独立的 Worker 服务消费此消息调用 Anthropic API 创建 sessionWorker 持续轮询 session 状态一旦completed将结果发送到另一个 Kafka Topicagent-results另一个服务监听agent-results更新数据库并通过 WebSocket 或邮件通知用户优势解耦、可伸缩、容错性强。即使 Worker 挂了Kafka 会重试session 状态不会丢失。路径三作为企业级自动化Enterprise Automation这是最高阶的用法与 Notion、Slack、Salesforce 深度集成。例如Notion 的 “Team Delegation” 功能用户在 Notion 页面里 claude输入 “请帮我分析这份竞品报告”Notion 的 Integration Bot 拦截此消息提取附件 URL调用 Anthropic/sessionsAPIAgent 在 sandbox 里下载 PDF调用 OCR 工具再调用 LLM 总结结果以评论形式自动回复到原始 Notion 页面关键点这种集成极度依赖 Anthropic 的 credential isolation。Notion 的 bot 只能获得一个临时的、只读的、只允许调用download_file工具的凭证。它绝不可能拿到 Notion 的管理员 Token。这是企业级信任的基石。4. 常见问题与排查技巧实录来自真实战场的避坑指南4.1 “Session stuck in ‘running’ forever” —— 最常见的幻觉陷阱现象一个 session 创建后状态一直卡在running/eventsAPI 显示最后一条事件是tool_call_started但再也没有tool_call_completed。几分钟后session 自动变为failed错误信息是Tool execution timeout。排查思路先查工具本身登录你的 sandbox 镜像手动执行fetch_lead_data工具传入相同的lead_id。我们发现问题出在 Salesforce 的 API 限流上——当并发请求超过 100 QPS 时它会返回429 Too Many Requests但我们的工具代码没有正确处理这个 HTTP 状态码而是陷入了无限重试。再查 sandbox 配置检查 sandbox 的timeout_seconds参数。Anthropic 默认是 30 秒AWS AgentCore 默认是 60 秒。如果你的工具平均响应是 45 秒那 30 秒的 timeout 就必然失败。最后查网络策略确认 sandbox 的安全组Security Group是否允许 outbound 到 Salesforce 的 endpoint。我们曾在一个 VPC 环境中因为 NACLNetwork ACL规则过于严格导致 sandbox 无法访问外部 API。解决方案在工具代码里必须显式处理429加入指数退避exponential backoff。在 agent YAML 中为慢速工具显式设置timeout_seconds: 120。在 sandbox 部署时使用 Terraform 等 IaC 工具确保网络策略是幂等的、可审计的。实操心得永远不要相信工具的“默认超时”。我们给所有外部 API 调用工具都设置了timeout_seconds: 90并强制要求工具代码里必须有try/catch包裹所有网络请求。这是生产环境的铁律。4.2 “Output contains sensitive PII” —— 安全护栏为何失灵现象agent 的最终输出里意外包含了客户的身份证号、手机号等 PIIPersonally Identifiable Information。Guardrails 设置了output_safety: block但并未触发。根因分析 Guardrails 的output_safety主要针对模型生成的文本内容进行分类如仇恨言论、暴力内容它不扫描工具返回的原始 JSON 输出。在我们的销售评分 agent 中fetch_lead_data工具返回的 JSON 里有一个ssn_last_four字段为了合规只返回后四位。这个字段被模型在生成最终报告时原封不动地引用了“该客户 SSN 后四位为 1234…”。模型的输出本身不违法所以output_safety没有拦截。正确解法前置脱敏Pre-sanitization在工具返回数据给模型之前就进行清洗。修改fetch_lead_data工具在返回 JSON 前删除所有ssn_*、phone_*字段或者将其替换为[REDACTED]。后置过滤Post-filtering在 BFF 层对 agent 的最终output字符串运行一个正则表达式扫描器如re.search(r\b\d{4}\b, output)匹配到敏感模式就拦截。Schema 级防护Schema-level guardrail这是最优雅的方案。在 YAML 的output_schema中为fetch_lead_data明确声明output_schema: type: object properties: name: type: string email: type: string # 注意这里故意 omit 了 ssn_last_four 字段 required: [name, email]这样Harness 在接收到工具返回的 JSON 时会自动校验如果 JSON 包含了 schema 里未定义的字段如ssn_last_four就会直接拒绝抛出schema_validation_error。这比任何运行时扫描都更早、更可靠。4.3 “Cost exploded overnight” —— 定价模型的隐藏雷区现象月初账单显示Managed Agents 的费用是预期的 5 倍。细查发现大量 session 的active_runtime_hours高得离谱有的 session 运行了 120 小时。真相揭露$0.08 per session-hour of active runtime这个定价有一个极其关键的细节active runtime 是指 session 处于running状态的总时长而不是从创建到结束的 wall-clock 时间。一个 session 可以被创建后长时间处于idle状态等待用户输入这段时间不收费。但一旦它开始running执行 tool call 或模型推理计时器就启动了。那个“120 小时”的 session是因为我们的前端 Bug当用户在表单页面停留太久前端没有发送cancel请求而是不断重试GET /sessions/{id}。每次重试都触发了 Harness 的一次“心跳检查”而 Harness 误判为 session 需要继续执行于是保持了running状态。实际上它什么都没干只是在空转。规避策略强制设置 session TTLTime-To-Live在创建 session 时通过expires_in_seconds参数Anthropic 支持或ttl_secondsAWS AgentCore 支持设定一个绝对上限比如36001 小时。超时后session 自动expired不再计费。前端智能轮询前端轮询时使用指数退避Exponential Backoff从 1s 开始逐步增加到 30s避免高频无效请求。后端主动清理BFF 服务定期扫描所有running状态超过 10 分钟的 session调用/sessions/{id}/cancel主动终止。我们用一个简单的 Cron Job 就实现了。问题类型表象根本原因推荐解决方案预防措施Session 卡死running状态永不结束工具超时、网络阻塞、sandbox 配置错误1. 工具加try/catch和重试2. YAML 中显式设timeout_seconds3. IaC 管理网络策略在 CI/CD 流程中对每个工具做load test模拟 1000 QPS 压力PII 泄露敏感信息出现在最终输出Guardrails 不扫描 tool output工具返回了不该返回的字段1. 工具前置脱敏2. YAMLoutput_schema严格定义所有工具的output_schema必须由安全团队 Review 并签字费用失控active_runtime_hours远超预期前端重试导致 Harness 误判缺少 session TTL1. 创建时设expires_in_seconds2. BFF 定期扫描并 cancel 长期 running session在账单告警系统中设置active_runtime_hours 1的 session 为 P0 告警5. 价值迁移图谱当 runtime 归零钱流向哪里5.1 Trace Store从“日志”到“法律证据”的升维当 runtime 成为免费的基础设施所有关于“agent 干了什么”的原始数据——那个由无数tool_call_started、tool_call_completed、model_output事件组成的 event log——就成了最稀缺、最有价值的资产。它不再仅仅是用于 debug 的日志而是可验证的、不可篡改的、具备法律效力的行为记录。我们正在见证三个 Trace Store 的激烈角逐LangSmith它的优势在于“默认安装”。只要你用 LangChainLangSmith 就是开箱即用的。它继承了 LangChain 的庞大生态但这也成了它的枷锁——它深度绑定 LangChain 的抽象当你想把一个非 LangChain 的 agent比如 CrewAI 或自研框架的日志接入 LangSmith 时需要写大量适配器代码。Arize Phoenix它走的是开源优先Apache 2.0路线把核心的 tracing、evaluation、LLM observability 功能全部开源。这吸引了大量重视自主可控的客户。它的商业版则聚焦于企业级功能RBAC基于角色的访问控制、SLA 保障、与 SIEM安全信息与事件管理系统的深度集成。一个银行客户选择 Arize不是因为它 dashboard 更好看而是因为它的开源协议允许他们把 Phoenix 的核心引擎部署在自己的 air-gapped气隙网络里。Braintrust Brainstore它是最激进的一个直接把自己定位为“AI 时代的 OLAP 数据库”。它不提供 fancy 的 UI而是提供一套强大的 SQL 接口让你可以直接SELECT * FROM events WHERE tool_name enrich_company_data AND duration_ms 5000。它的客户是那些已经有成熟 BI 团队的数据驱动型企业。对他们来说trace 数据不是用来“看”的而是要和 CRM、ERP 的数据 join生成“agent 响应时间 vs. 销售转化率”的归因分析报告。提示Trace portability 是当前最大的痛点。今天你用 Anthropic Managed Agents明天想迁移到 AWS AgentCore你的 event log 格式、字段名、时间戳精度全都不一样。谁能提供一个统一的、厂商无关的 OpenTelemetry for AI 标准并率先落地谁就拿到了通往未来的船票。目前OpenTelemetry 社区的 SIG-AI 小组正在起草这个标准但距离 GA 还有至少一年。5.2 Governance Policy从“技术开关”到“采购审批单”当 runtime 免费了企业采购部门的关注点就从“这个 runtime 多快多稳”转向了“这个 agent 被允许做什么”。Policy 控制不再是 DevOps 的技术开关而是 CISO首席信息安全官和 CFO首席财务官共同签署的采购审批单。AWS AgentCore 在 March 2026 GA 的 Policy Controls就是这个趋势的明证。它允许你定义Data Residency Policy强制所有 sandbox 的 microVM 必须运行在us-west-2区域确保数据不出境。Tool Access Policy规定enrich_company_data工具只能被sales-scoring-agent调用不能被marketing-campaign-agent调用。Output Redaction Policy自动扫描所有 agent 输出将匹配SSN_REGEX的字符串替换为[REDACTED]。这已经不是简单的“feature”而是构建企业级 AI 治理AI Governance的基石。OWASP Agentic Top 10 的发布更是把这种治理需求从“最佳实践”提升到了“安全合规底线”。一个企业现在问供应商的问题不再是“你们的 sandbox 多快”而是“你们的 policy engine 是否支持 SOC2 Type II 审计”、“你们的 policy rule 是否可以通过 Terraform 代码化管理”5.3 Vertical Agent Marketplaces从“通用能力”到“行业合同”Salesforce 的 Agentforce ARR 达到 $800M这个数字背后是一个清晰的信号企业愿意为“解决我这个行业特定问题”的 agent 付费而不是为“能跑 agent 的 runtime”付费。Runtime 是水电煤是基础设施而垂直 agent是能直接带来 ROI投资回报率的生产力工具。我们观察到的早期赢家都有一个共同特征它们不卖“AI”它们卖“结果”。virattt/ai-hedge-fund它不是一个“金融 agent 框架”而是一个“能帮你每天生成 5 个量化交易信号”的服务。它的定价是按信号数量$1000/月/100 signals而不是按 token 或 compute hour。vxcontrol/pentagi它不是一个“安全 agent 工具集”而是一个“能每周为你执行一次红队演练并生成符合 ISO 27001 标准的 PDF 报告”的产品。它的合同是和企业的 CISO 直接签的年度服务协议。这种模式的成功源于它绕过了技术采购的层层关卡。一个 CTO 可能对“runtime”无感但一个销售 VP会毫不犹豫地为一个能帮他把线索转化率提升 20% 的 agent 签单。这就是为什么资本正在疯狂涌入垂直领域。因为这里的壁垒不是技术而是行业知识domain expertise、客户信任customer trust和销售管道sales pipeline