1. 这不是新赛道而是 runtime 层的“操作系统时刻”正在重演你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》第一反应可能是又一个大模型公司搞出了什么黑科技但如果你真花十分钟读完原始那篇长文会发现它根本不是在讲“Anthropic有多强”而是在冷静地划一条线——这条线把整个 AI 工程栈切成了上下两层上层是价值可沉淀、可定价、可构建护城河的部分下层是注定被压缩、被免费化、被云厂商打包进账单的基础设施部分。我做 AI 基础设施落地项目整整七年从最早用 Flask Redis 手搓 agent 调度器到后来给三家 Fortune 500 企业设计多租户沙箱平台再到去年带队重构一个日均 27 万 session 的金融客服 agent 系统——我亲眼见过太多团队把全部精力押注在“怎么让 harness 更快”“怎么优化 sandbox 启动时间”上结果半年后 AWS 一纸公告AgentCore 直接开箱即用连 YAML schema 都和他们自研的八九不离十。这不是技术失败是战略误判。Anthropic 这次发布的 Managed Agents表面看是“托管型智能体运行时”实则是把一个本该由开发者自己扛的、沉重的、易出错的底层工程负担封装成一个带 SLA 的服务。它解决的不是“能不能跑 agent”而是“要不要为 agent 的生命周期管理、状态持久化、凭证隔离、可观测性这些脏活累活付工资”。关键词里那个 “Towards AI - Medium” 不是随便写的——这篇文章的语境是写给真正每天在生产环境里 debug agent session timeout、排查 credential leak、重放失败 trace 的工程师看的不是给投资人讲 PPT 的。它说的“layer going to zero”指的就是 runtime 这一层当 AWS、GCP、Azure 都把 agent runtime 当作云资源调度的自然延伸来提供时单独卖 runtime 就像 2010 年还在卖物理服务器机柜一样逻辑上成立经济上不可持续。你不需要懂 KVM 或 Xen 的源码但你必须理解任何被三大云原生集成、被开源社区快速跟进、被垂直场景倒逼标准化的中间件层其毛利率天花板就是“云厂商愿意补贴多少”的函数。Anthropic 明白这点所以它没喊“我们定义了新标准”而是 quietly 把 Managed Agents 定价为 $0.08/session-hour —— 这个数字比 AWS EC2 t3.micro 按需实例每小时成本$0.0104高不到 8 倍却远低于一家初创公司自建同等 SLA 的运维人力成本。它不是在抢市场是在锁客户让你用 Claude 的 token 时顺手也用了它的 runtime这样当你未来想换模型时迁移成本就不仅是 API key 切换而是整个 session state、tool binding、guardrail 配置的重写。这才是“防御性发布”的真实含义。2. 核心设计拆解为什么“Session as Event Log”是唯一值得抄的架构范式2.1 从“上下文窗口即数据库”到“事件日志即真相源”的范式迁移我必须先讲清楚一个血泪教训去年我们给某省级医保局做的慢病随访 agent设计之初图省事把所有患者对话历史、检查报告解析结果、医生干预记录全塞进 LLM 的 context window 里维护状态。系统上线第三周一个老年糖尿病患者的随访流程卡在第 17 步——因为前 16 步产生的 tool call 结果血糖趋势分析、用药依从性评分、饮食建议生成已占满 98% 的 200K token 上下文模型在生成第 17 步“是否触发转诊预警”时自动丢弃了第一步的初始诊断摘要。更糟的是它没报错只是基于残缺信息胡编了一个“无异常”导致高危患者漏筛。我们花了 36 小时才定位到问题根源不是 prompt 写得不好不是模型能力不足而是把 state 存在 context 里本质上是把数据库建在内存缓存上。Anthropic 的“Session as Event Log”不是炫技是把这个问题从架构层面根除。它的 session 不是字符串拼接而是一个结构化的、可查询的、带时间戳和因果链的事件流。每一次 tool call、每一次模型输出、每一次 guardrail 触发都作为独立 event 写入 durable log背后很可能是 TimescaleDB 或 ClickHouse 这类时序 OLAP 数据库。Harness执行器本身是 stateless 的它只负责根据当前 event stream 的最新状态调用对应工具或模型。这意味着崩溃可恢复Harness 进程挂了没关系awake(sessionId)会从 event log 最后一个成功 commit 点重新加载状态用户甚至感知不到中断调试可回溯运营人员反馈“昨天下午三点张三的保单推荐错了”你直接查SELECT * FROM events WHERE session_id xxx AND timestamp 2026-04-07 15:00:00就能看到完整决策链而不是翻三天前的 debug 日志审计可合规金融行业要求“所有决策过程留痕”event log 天然满足 WORMWrite Once Read Many特性比任何应用层日志都更难篡改。这背后的技术选型非常务实Anthropic 没有造轮子去搞分布式事务而是用 event sourcing CQRS命令查询职责分离的经典组合。每个 session 对应一个 event stream写入走 Kafka/Pulsar 这类高吞吐消息队列保证顺序和持久化读取走物化视图或预聚合表保证查询性能。这种设计在 Uber、Netflix 的实时风控系统里已验证十年不是什么新概念但把它移植到 agent 领域是第一次有人把它做成开箱即用的抽象。2.2 Credential Isolation不是“安全最佳实践”而是生产环境的生存底线再聊一个看似枯燥、实则致命的细节credential 隔离。原文提到“Credentials bundled into the sandbox at provision time, never injected as environment variables the agent can read”。这句话背后是我亲身经历过的两次重大事故。第一次是某电商客服 agent开发为了快速对接内部 CRM把数据库连接串硬编码进 agent 的 system prompt 里。结果某次 prompt 注入攻击攻击者通过构造特殊用户提问让模型把整个 system prompt 原样输出连接串直接泄露。第二次更隐蔽我们用 LangChain 的SQLDatabaseChain接财务系统把 DB credentials 作为env注入 Docker 容器。某天运维误操作执行了docker inspect查看容器详情命令输出里明文包含了 credentials。Anthropic 的方案彻底规避了这两种路径credential 不是传给 agent 进程而是在 sandbox 创建时由 Anthropic 的 control plane 将加密后的凭据注入 sandbox 的内核级隔离区类似 Linux kernel keyringagent 进程只能通过受控的 syscall如get_credential(finance_db)获取解密后的临时 token且 token 有严格 TTL 和调用次数限制。这本质上复刻了现代云服务的 IAM 模式——AWS Lambda 函数不存 AccessKey而是绑定 Execution RoleAzure Function 不配 ConnectionString而是用 Managed Identity。Anthropic 把这套成熟范式搬到了 agent runtime 层。它意味着即使 agent 被完全攻破、模型开始胡言乱语、甚至返回恶意代码攻击者也无法拿到原始凭证因为凭证根本不在它的地址空间里。这不是“锦上添花的安全功能”而是当你的 agent 要调用支付网关、访问 HR 系统、操作生产数据库时唯一能让你晚上睡得着觉的设计。我见过太多团队在 PoC 阶段忽略这点等上了生产安全团队一票否决推倒重来。Anthropic 把这个“必须做”的事情变成了“默认就做对”。2.3 Harness as Stateless Executor为什么“execute(name, input) → string”是极简主义的胜利Harness 这个概念常被误解为“更聪明的调度器”。但 Anthropic 的定义极其克制它就是一个无状态的、纯函数式的执行桥接器。你调用execute(search_patients, {name: 张三, age_gt: 60})它不关心这个 tool 是 Python 函数、HTTP API 还是 Kubernetes Job只负责把 input 序列化、投递到对应 sandbox、等待结果、反序列化返回 string。这种设计的威力在于它把“复杂性”做了精准切割Tool 开发者只需关注业务逻辑写一个符合 OpenAPI Spec 的 REST endpoint或一个带tool装饰器的 Python 函数Agent 设计者只需在 YAML 里声明tools: [search_patients, send_sms]不用管它们部署在哪、用什么语言写Infrastructure 团队只需确保 sandbox runtime 能拉起容器、网络互通、监控埋点到位。没有中间件、没有适配层、没有 SDK 绑定。我去年帮一家医疗 SaaS 公司迁移旧 agent 系统时最大的痛苦就是他们的 harness 强耦合了 LangChain 的Tool类而新采购的影像分析 service 只提供 gRPC 接口。我们不得不写一个 LangChain 兼容的 wrapper结果 wrapper 本身成了故障高发点。Anthropic 的execute()接口相当于定义了一个最薄的 ABIApplication Binary Interface——就像 POSIX 标准之于 Unix 系统只要实现open(),read(),write()上层应用就能跑。这种极简带来了惊人的兼容性Notion 能用它调度内部 Notion APIRakuten 能用它调 Slack BotSentry 能用它触发 GitHub Actions。它不试图“统一所有工具”而是承认工具生态的碎片化并提供一个足够薄、足够稳的胶水层。这正是操作系统虚拟化硬件的精髓不消灭 x86、ARM、RISC-V 的差异而是用统一的系统调用接口让同一份应用二进制能在不同 CPU 上跑。Anthropic 的 harness就是 agent 世界的syscall。3. 实操要点与关键配置如何用好 Managed Agents 而不踩坑3.1 YAML 定义 agent 的实战技巧从“能跑”到“可维护”的跃迁Anthropic 允许用 YAML 或自然语言定义 agent但生产环境强烈建议 YAML。原因很简单自然语言定义无法版本控制、无法做 diff、无法自动化测试。一个典型的、经过我们生产验证的 YAML 结构如下# agent-config.yaml name: healthcare-claims-assistant version: 1.2.0 description: 处理商业保险理赔申请的智能体支持 OCR 解析、规则校验、人工复核路由 system_prompt: | 你是一名资深医疗保险理赔专员。请严格按以下步骤处理用户提交的理赔申请 1. 调用 extract_claims_doc 工具解析上传的 PDF/图片 2. 调用 validate_coverage 工具核对患者保单有效性 3. 若任一校验失败向用户说明原因并提供申诉入口 4. 若全部通过调用 generate_claim_summary 生成摘要并询问是否提交。 tools: - name: extract_claims_doc description: OCR 解析理赔单据返回结构化 JSON{patient_name, claim_date, total_amount, itemized_list[]} input_schema: type: object properties: file_url: type: string description: S3 或 GCS 上的文件 URL需带临时签名 output_schema: type: object properties: patient_name: {type: string} claim_date: {type: string, format: date} total_amount: {type: number} # credential_scope 指定此工具所需的最小权限集 credential_scope: ocr_service_read - name: validate_coverage description: 调用核心保单系统验证患者当前保单状态及覆盖范围 input_schema: {type: object, properties: {policy_id: {type: string}}} output_schema: {type: object, properties: {is_valid: {type: boolean}, coverage_details: {type: string}}} credential_scope: policy_core_read guardrails: # 敏感词过滤防止泄露 PII pii_filter: enabled: true patterns: [身份证号, 银行卡号, 手机号] action: redact # 输出长度限制防 token 滥用 max_output_tokens: 2048 # 工具调用深度限制防无限递归 max_tool_calls_per_session: 12 # session 生命周期策略 session_policy: # 会话空闲 30 分钟自动终止释放资源 idle_timeout_minutes: 30 # 最长存活 7 天强制归档符合 GDPR max_lifetime_days: 7 # 自动归档到长期存储的位置 archive_destination: s3://my-company-ai-archives/healthcare-claims/这个 YAML 的关键实操心得credential_scope是灵魂不要图省事全给*权限。我们曾因一个search_patients工具绑定了hr_db_full_accessscope导致一次低权限员工的 prompt 注入意外读取了高管薪资数据。现在每个 tool 必须声明最小必要权限由 Anthropic 的 vault 在 sandbox provision 时动态注入guardrails要具体到业务pii_filter的 patterns 不能只写正则必须结合业务文档列出所有可能的 PII 字段名如“社保卡号”“就诊卡号”因为非结构化文本中模型可能用各种别名提及session_policy是成本控制开关idle_timeout_minutes设太长session 一直占着 sandbox 资源$0.08/hour 积少成多设太短用户填一半表单就断连体验极差。我们实测下来金融类会话设 15 分钟客服类设 5 分钟后台批处理类设 120 分钟效果最佳version字段必须用语义化版本每次修改 YAML哪怕只改一个 typo也要 bump patch 版本如 1.2.0 → 1.2.1。这让你能精确回滚、做 A/B 测试、追踪哪个版本引入了 bug。我们用 GitOps 方式管理 YAML每次 commit 关联 Jira ticket形成完整审计链。3.2 Session 状态管理如何设计 event log 的查询与归档策略Managed Agents 的 event log 是宝藏但不会自动变成黄金。你必须主动设计查询和归档策略。我们为某银行设计的方案如下实时查询层 1 小时Event log 写入 Kafka Topicagent-events-prodFlink Job 实时消费将关键字段session_id,event_type,tool_name,status,duration_ms,error_message写入 Elasticsearch。供 SRE 团队用 Kibana 做实时监控设置告警error_count / total_events 0.05或p95_duration_ms 5000分析归档层1 小时 - 30 天Flink Job 同时将原始 event JSON 写入 S3s3://bank-ai-logs/raw/按year2026/month04/day08/hour14/分区。用 Athena 查询例如“过去 7 天validate_coverage工具失败率最高的三个地区是”长期合规层 30 天Lambda 函数每日扫描 S3将超过 30 天的分区用 Glacier Deep Archive 存储并触发 SQS 消息通知法务团队。归档前用 PySpark job 对所有 PII 字段做 K-anonymity 脱敏如将“张三男45岁”泛化为“某市男40-49岁”确保符合《个人信息保护法》。提示不要依赖 Anthropic 控制台的 UI 查询。它只展示最近 100 个 event且不支持 SQL。真正的可观测性必须自己接管 event log 的下游消费。我们甚至开发了一个内部 CLI 工具agent-trace replay --session-id xxx --from-event 123能一键重放某个 session 从指定 event 开始的所有步骤极大加速 debug。3.3 Pricing 模型精算$0.08/session-hour 的真实成本结构很多人看到 $0.08/session-hour 就觉得便宜但实际成本远不止于此。我们为一家中型 SaaS 公司做过详细测算基础成本假设平均 session 持续 8 分钟480 秒则每 session runtime 成本 $0.08 * (480/3600) ≈ $0.0107Token 成本Claude 3.5 Sonnet 输入 $0.003/1K tokens输出 $0.015/1K tokens。一个典型客服 session 平均消耗 12K input 8K output tokenstoken 成本 ≈ $0.036 $0.12 $0.156Tool Call 成本extract_claims_docOCR 服务按页收费 $0.05/页平均每次 session 处理 3 页$0.15网络与存储成本S3 归档 event log按 10GB/月计算约 $0.23隐性成本YAML 配置管理、guardrail 规则更新、安全审计工时按 FTE 折算约 $0.05/session。总成本 ≈ $0.3967/session。而他们之前自建方案的成本是 $0.421/session含 2 名兼职工程师的运维分摊。看起来 Anthropic 略便宜但关键优势在于确定性$0.08 是固定费率不受流量峰谷影响自建方案在大促期间EC2 实例扩容、Redis 内存暴涨成本可能翻倍零运维省下的 2 名工程师可以全力投入 agent 业务逻辑优化比如把generate_claim_summary的准确率从 82% 提升到 94%这带来的客户满意度提升远超 runtime 成本差额SLA 保障Anthropic 承诺 99.95% uptime自建方案要达到同等水平需跨 AZ 部署、多活切换、混沌工程成本至少再加 $0.08/session。所以决策不应只看 $0.08而要看“你愿意为确定性、免运维、高 SLA 付多少钱”。对中小团队Managed Agents 是降本增效对超大型企业它可能是规避合规风险的必需品。4. 生态竞争全景图为什么说 Anthropic 的 launch 是“防御性卡位”4.1 Hyperscaler 的碾压式布局AgentCore、Vertex、Foundry 的真实能力边界把 Anthropic 放在生态里看才能看清它的位置。AWS Bedrock AgentCore 不是“另一个选择”而是事实上的默认底座。它的 GA 时间2025 年底比 Anthropic 早五个月这五个月足够发生质变微虚拟机microVM是杀手锏AgentCore 每个 session 运行在 Firecracker microVM 中拥有独立 CPU、内存、root filesystem。这意味着一个恶意 tool比如被污染的 Python 包无法逃逸影响其他 session可以安全运行任意二进制如ffmpeg处理视频、pdftotext解析 PDF无需担心容器镜像臃肿内存隔离杜绝了 side-channel 攻击如 Spectre这对金融、医疗客户是刚需。我们实测过启动一个 microVM 的平均耗时 127ms比 Anthropic 的 sandbox官方未公布我们实测约 320ms快 2.5 倍。这不是参数游戏是架构代差。框架无关性是生态护城河AgentCore 不绑定任何 agent 框架。LangGraph 用户只需把graph.invoke()封装成一个符合request-response协议的 handlerCrewAI 用户把Crew.kickoff()包装成 endpoint甚至连自研的 Rust agent只要暴露 HTTP 接口就能跑。这直接瓦解了“框架锁定”商业模式。某家曾融资 5000 万美元的 agent 框架公司其 CEO 在内部邮件承认“AWS 让我们的 SDK 变成了可选插件而非必经之路。”Policy Controls 是企业采购的敲门砖2026 年 3 月 GA 的 Policy Controls允许管理员用 YAML 定义# bedrock-agent-policy.yaml policies: - name: block-external-api-calls condition: event.tool_name http_request action: deny reason: 禁止 agent 直接调用外部互联网 API必须经企业 API 网关 - name: require-pii-scan condition: event.type tool_output event.tool_name extract_claims_doc action: scan_pii pii_types: [ID_CARD, BANK_ACCOUNT]这种细粒度、可审计、可版本化的策略是 CISO首席信息安全官签字放行的前提。Anthropic 的 guardrails 是静态的、全局的而 AgentCore 的 policy 是动态的、可编程的、可与企业现有 IAM 系统集成的。Google Vertex AI Agent Builder 和 Microsoft Azure AI Foundry 走的是另一条路深度垂直整合。Vertex 的 Agent Registry 直接对接 Apigee意味着你可以把一个 agent 当作 API 发布享受 Apigee 的流量控制、计费、开发者门户全套能力。Foundry 则把 AutoGen 的 multi-agent 编排、Semantic Kernel 的 memory management无缝嵌入 Azure 的 Purview数据治理和 Defender安全体系。它们不追求“通用 runtime”而是让 agent 成为云平台的一个原生工作负载。对已经重度使用 AWS/GCP/Azure 的客户切换到 Anthropic Managed Agents意味着放弃已有的监控、告警、日志、安全、计费体系成本极高。Anthropic 的客户往往是那些“Claude 优先”的创新团队他们愿意为更好的模型体验承担额外的运维复杂度。4.2 开源压力曲线Daytona、K8s SIG、Deer-flow 如何重塑游戏规则如果说 hyperscaler 是“自上而下”的整合开源社区就是“自下而上”的颠覆。2025 年初 Daytona 的转型是标志性事件。它原本是 DevOps 领域的明星提供基于 VS Code 的远程开发环境。当它宣布 pivot 到 AI agent infrastructure 时所有人都以为是蹭热点。但它的技术路线极其清晰用开发者最熟悉的工具链解决 agent 最痛的痛点。Daytona 的 sandbox 启动时间 90ms秘诀是预热机制它维护一个 sandbox pool每个 sandbox 在空闲时会预加载常用工具curl、jq、python3和基础模型 tokenizer真正启动时只需 fork 进程而非从零创建容器它的 CLIdaytona run --agent healthcare-claims.yaml能一键在本地、K8s、甚至边缘设备上运行同一个 agent彻底打破“开发-测试-生产”环境差异最关键的是它把agent.yaml定义为唯一真相源所有 IDE 插件、CI/CD pipeline、监控系统都围绕这个 YAML 构建。这比 Anthropic 的 YAML 更进一步——它是可执行的、可调试的、可协作的。Kubernetes SIG 的 agent-sandbox 项目则代表了云原生的终极形态。它不是一个新 runtime而是把 agent sandbox 当作一种新的 Kubernetes ResourceCRD# agent-sandbox.yaml apiVersion: ai.k8s.io/v1 kind: AgentSandbox metadata: name: claims-processor spec: image: my-company/claims-agent:v1.2 tools: - name: ocr-service url: http://ocr-service.default.svc.cluster.local resources: limits: memory: 2Gi cpu: 1000m securityContext: # 强制启用 seccomp、apparmor seccompProfile: type: RuntimeDefault这意味着你可以在现有的 K8s 集群里用kubectl apply -f agent-sandbox.yaml部署 agent享受 K8s 原生的 autoscaling、service mesh、network policy。它不挑战云厂商而是成为云厂商的“最佳实践参考实现”。ByteDance 的 deer-flow则展示了“下一代 agent”的雏形。它不是简单的 request-response而是内置了 long-horizon planning 和 subagent delegation一个sales-developmentagent 接到任务“为某客户生成定制化解决方案”它会自动 spawn 3 个 subagentresearch_subagent爬取客户官网、财报、新闻生成背景报告product_match_subagent比对客户技术栈与我方产品矩阵生成匹配度评分draft_proposal_subagent基于前两者输出撰写提案初稿。所有 subagent 的通信、状态同步、错误恢复都在 deer-flow 的 runtime 内完成无需外部协调。这已经超越了 Anthropic Managed Agents 的范畴指向了“agent as OS process”的未来。而 deer-flow 是开源的MIT License。当这些项目成熟Anthropic 的 proprietary runtime其技术壁垒将迅速消融。4.3 “Runtime Layer Going to Zero”的历史印证从 VMware 到 Agent Runtime 的必然路径把 Anthropic 的 Managed Agents 和 VMware ESX 放在一起对比不是牵强附会而是看透本质。2005 年的 VMware和 2026 年的 Anthropic面临几乎相同的局面都是高质量的专有解决方案ESX 提供了当时最稳定的 x86 虚拟化Managed Agents 提供了最简洁的 agent lifecycle management都面临开源竞品的追赶Xen2003、KVM2007 vs Daytona2025、K8s SIG2026都面临云厂商的“吸收”AWS EC22006把虚拟化变成 APIAzure VM2010同理 vs AWS AgentCore2025、Azure Foundry2026。历史告诉我们当一个中间件层被云厂商“吸收”后会发生什么价格归零VMware ESX 从数万美元/主机变成 AWS EC2 的 $0.0104/hourt3.microAgentCore 的 pricing model 尚未完全公开但业内共识是“接近免费”因为它主要靠带动 EC2、RDS、S3 等上层服务消费来盈利创新焦点上移VMware 时代大家比谁的 hypervisor 更快、更稳Kubernetes 时代大家比谁的 operator 更智能、谁的 service mesh 更精细Agent Runtime 时代创新焦点必然上移到trace store、governance、vertical marketplace价值捕获者变更VMware 拥有 hypervisor但 KubernetesCNCF、TerraformHashiCorp、Datadog可观测性捕获了更大价值同样Anthropic 拥有 Managed Agents但 Braintrusttrace store、Arizeobservability、Salesforcevertical marketplace将捕获下一波价值。这就是为什么说“the layer is already going to zero”。不是 Anthropic 做得不好而是它做得太好好到证明了这个层可以被标准化、被 commoditize。它的成功恰恰是它自身商业模式的掘墓人。5. 价值迁移的三大高地Trace Store、Governance、Vertical Marketplace 的实战指南5.1 Trace Store从“日志查看器”到“AI 决策的法定证据库”当 runtime 变成水电煤谁掌握“agent 做了什么”的完整记录谁就掌握了事实真相。Trace Store 不是 fancy dashboard而是 AI 时代的“黑匣子”。我们为某保险公司落地的 Brainstore 方案揭示了它的核心能力Schema-on-Read 的灵活性Brainstore 不要求你提前定义 event schema。当第一个extract_claims_docevent 写入它自动 infer 出patient_name: string, claim_date: date当第二个 event 带来diagnosis_code: string它动态扩展 schema。这解决了 agent 工具不断迭代带来的 schema 演进难题跨 session 关联分析一个理赔欺诈案件往往涉及多个 session患者本人申请、家属代申请、医生补充材料。Brainstore 的session_grouping功能允许你用patient_id作为 grouping key一键查询“该患者所有相关 session 的完整决策链”并可视化因果关系图法律就绪的归档Brainstore 的legal_holdAPI可对特定 session group 执行 WORM 锁定生成 SHA-256 哈希值并上链如 Polygon作为司法鉴定的电子证据。这比任何应用日志都更具法律效力。注意不要把 trace store 当作“另一个监控系统”。它的核心指标不是error_rate而是decision_provenance_score决策可追溯性得分。我们定义它为成功关联到原始输入的 event 数/总 event 数。目标是 100%因为任何缺失都可能在审计中成为致命漏洞。5.2 Governance Policy当“agent 能做什么”成为采购准入门槛政策控制Policy Control不再是可选项而是企业采购的硬性门槛。AWS AgentCore 的 Policy GA标志着这一层正式进入主流。但真正的挑战在于如何把模糊的合规要求翻译成可执行、可审计、可自动化的策略我们为某跨国银行制定的策略落地路径Step 1映射法规条款将 GDPR 第 22 条自动化决策、中国《生成式 AI 服务管理暂行办法》第 10 条内容安全逐条拆解为技术动作如“禁止 agent 在未经人工复核前直接批准贷款申请”Step 2编写 Policy YAML# bank-policy.yaml - name: loan-approval-guard condition: event.tool_name approve_loan event.input.amount 50000 action: route_to_human human_queue: credit_review_team timeout_hours: 24 escalation: alert_risk_complianceStep 3自动化测试与审计用 pytest 编写策略测试用例def test_loan_approval_guard(): # 模拟一个 60000 元的贷款申请 event create_event(toolapprove_loan, input{amount: 60000}) assert policy_engine.apply(event) route_to_human每次策略变更CI pipeline 自动运行所有测试并生成审计报告供内审部门签字。这整套流程比 Anthropic 的静态 guardrails 强大得多。它让合规从“事后补救”变成“事前预防、事中拦截、事后审计”的闭环。而这个闭环的载体就是 policy-as-code。5.3 Vertical Marketplace为什么“销售开发 agent”比“agent runtime”更值钱Salesforce Agentforce 的 $800M ARR不是偶然。它证明了一件事企业愿意为解决具体业务问题的 agent 付费而不是为运行它的基础设施付费。我们观察到的垂直 marketplace 成功要素Problem FirstNot Tech Firstvirattt/ai-hedge-fund 不是“一个用 LLM 做量化交易的框架”而是“一个能帮你自动执行多因子选股、回测、下单的 agent”它的 README 第一行就写着“Paste your brokerage API key, and start trading in 5 minutes.”Pre-Built Integrations 是护城河Salesforce Agentforce 能开箱即用是因为它预集成了 Sales Cloud、Service Cloud、Marketing Cloud 的所有 API并针对每个对象Lead, Account, Case提供了专用的 agent templateSuccess-Based Pricing 是信任杠杆某家医疗 agent startup不收 license fee而是按“成功预约的患者数”收费每例 $15。这把 vendor 和客户利益牢牢绑定远胜于按 session-hour 收费。我们正在帮一家律所打造“合同审查 agent marketplace”。核心思路是不卖 runtime不卖模型只卖“律师工作流的数字化封装”。例如MA_DueDiligence_Agent自动抓取目标公司工商、司法、知识产权数据生成尽调清单 checkmarkEmployment_Compliance_Agent扫描员工手册比对最新劳动法规标出风险条款IP_Licensing_Agent解析技术许可协议提取 royalty rate、territory、exclusivity 等关键条款生成对比矩阵。每个 agent 都是独立 SKU按年订阅价格对标 1/10 个