Agent Runtime 归零时代：从上下文管理到事件日志的范式革命

1. 这不是新赛道，是 runtime 层的“操作系统时刻”——但没人告诉你它正在快速归零

我第一次在生产环境里跑一个需要连续调用 7 次外部 API、中间穿插 3 轮人工审核确认、还要跨 4 个时区协调的客户支持代理时，是在 2025 年初。当时我们没用任何托管运行时，全靠自己搭的轻量级状态机 + Redis 缓存 + 自研沙箱容器。上线第三天凌晨两点，系统报警：context window overflow — truncated history at step 5/12。我们紧急登录后台查日志，发现模型把前两轮用户上传的 PDF 合同摘要、客服工单编号、法务反馈意见全“记混”了，最后生成的回复里，把客户 A 的合同条款套到了客户 B 的退款请求上。更糟的是，整个 session 没有完整事件流记录，只有零散的 LLM 输出快照和工具调用返回码。我们花了 6 小时手动拼凑出发生了什么，又花 2 天重写状态持久化逻辑——把所有中间态从 prompt 里彻底剥离，存进独立的、带版本号的事件日志表。这件事之后，我桌上贴了张便签：“永远别让 context window 成为你的数据库”。Anthropic 这次发布的 Claude Managed Agents，核心就干了这一件事：把这张便签，做成了开箱即用的基础设施。它不是在造一个“更聪明的 agent”，而是在终结一种低效、脆弱、注定被淘汰的工程范式。关键词里反复出现的 “Towards AI - Medium”，恰恰说明这已不是技术圈内部的暗语，而是正在被主流开发者社区集体确认的底层共识：agent runtime 正在经历和当年虚拟化技术一模一样的历史路径——从高价值专有产品，走向免费、透明、无感的基础设施层。它解决的不是“能不能做 agent”，而是“能不能放心让 agent 做事”。适合谁？如果你还在用 LangChain 的ConversationBufferMemory存 session、还在把 API key 写进 system prompt、还在为 context 长度焦虑到要写 prompt 工程脚本去“裁剪历史”，那你不是在开发 agent，你是在给 runtime 层打补丁。这篇文章不讲概念，只拆解真实世界里，一个靠谱的 agent 运行时到底长什么样、为什么必须长这样、以及当它开始归零时，你该往哪一层去抢位置。

2. 核心设计逻辑：三层解耦不是炫技，是踩过坑后的生存本能

2.1 Session 作为独立、可查询、可回溯的事件日志

Anthropic 官方文档里那句 “Session as durable event log living outside the model context” 看似平淡，实则是整套架构的基石，也是所有失败案例的反面教材。我们来算一笔账：Claude 3.5 Sonnet 的上下文窗口是 200K tokens。假设一个典型客服 agent 的单次交互平均消耗 800 tokens（含 system prompt、user input、tool call 结果、model response），那么理论上最多能塞下 250 轮对话。但现实远比这残酷。当你引入 RAG，每次检索返回的 chunk 可能就占掉 3000–5000 tokens；当 agent 调用一个财务 API 返回一份结构化 JSON，光是那个 JSON 的字符串化表示就可能吃掉 10K tokens；当用户上传一张截图，OCR 后的文本描述轻松突破 5K。更致命的是，LLM 的“记忆”不是线性存储，而是依赖 attention 机制对整个上下文做加权计算。一旦历史过长，早期关键信息（比如用户明确说的“不要折扣，只要换货”）的 attention score 就会指数级衰减，模型开始“自由发挥”。我们去年那个崩溃的 agent，就是在第 42 分钟、第 17 轮交互时，把用户最初强调的“发票必须开成技术服务费”这条指令，完全丢进了 attention 的黑洞。而 Anthropic 的 session 日志，本质是一个严格序列化的、带时间戳和因果链的 WAL（Write-Ahead Log）。每一次 tool call 的输入、输出、执行耗时、返回状态码；每一次 human-in-the-loop 的审批动作、附带的评论；每一次模型生成的 reasoning chain 和最终 action，都被原子化地写入这个日志。它不依赖模型的记忆力，它本身就是事实的唯一来源。这意味着：你可以随时GET /sessions/{id}/events?from=2026-04-08T14:22:00Z&to=2026-04-08T14:25:00Z拉取精确三分钟内的全部操作流；你可以用 SQL 查询 “所有在finance_api.create_invoice调用后 5 秒内触发email.send的 session”；你甚至可以基于这个日志，训练一个专门用于诊断 agent 行为异常的轻量级 classifier。这不是锦上添花的功能，这是生产环境的底线。没有它，agent 就是黑盒里的薛定谔猫——你永远不知道它在想什么，直到它搞砸一切。

2.2 Harness：无状态、可替换、只负责“调用”的执行器

Harness 这个词选得极妙。它不是 engine（引擎），不是 core（核心），不是 platform（平台），而是 harness（挽具、束带）。它的唯一使命，就是把模型的“思考”和工具的“执行”这两个物理上分离的动作，用最轻量、最可靠的方式连接起来。Anthropic 的 harness 实现，本质上就是一个高度封装的execute(name, input) → string接口。name是你在 YAML 中定义的 tool 名称（比如notion_search_pages），input是一个严格 schema 化的 JSON 对象（由模型根据 tool description 自动生成），string是执行结果的原始字符串（不经过任何 LLM 解析或清洗）。这里的关键在于“无状态”。Harness 本身不保存任何 session 数据，不维护任何缓存，不参与任何决策。它就像一个精准的快递员：收到一个写着“送到 302 房间，收件人张三，包裹内容是 JSON”的指令，它就去敲门、递包裹、拿回签收单，然后立刻转身走人。下次再有指令，它还是从零开始。这种设计直接规避了两个经典陷阱：第一，避免了 harness 自身成为故障点。如果 harness 进程崩溃，awake(sessionId)调用会直接从 session 日志的最新 checkpoint 加载，重新构造出当前所需的所有上下文变量，然后继续调用下一个 tool。整个过程对用户完全透明，没有“重连”、“重试”、“断线重连”的概念。第二，它实现了模型与执行环境的彻底解耦。今天你用 Claude 3.5，明天换成 Grok-3 或者本地部署的 Qwen2.5，只要它们能生成符合你 tool schema 的 JSON，harness 就能无缝工作。我们团队在测试阶段做过对比：用同一个 harness，分别接入 Claude、Llama-3-70B-Instruct 和一个微调过的 Phi-3-mini，三者的 tool call 成功率几乎一致（>99.2%），差异只在于生成 JSON 的格式严谨度——Claude 最稳，Llama 需要加一条output_format: "strict_json"的 prompt 约束，Phi-3 则需要额外一个轻量级 parser 做兜底校验。Harness 的价值，不在于它多强大，而在于它多“无聊”——越无聊，越可靠。

2.3 Sandbox：按需创建、用完即焚、凭证永不暴露的 cattle 式环境

“Sandboxes as cattle, not pets” 这句话背后，是一整套面向生产安全的工程哲学。所谓 “cattle”，意味着每一个 sandbox 都是标准化、可复制、可批量销毁的。Anthropic 的 sandbox 实现，其核心创新点不在隔离技术本身（Linux namespaces + cgroups 是成熟方案），而在于 credential（凭证）的注入方式。传统做法是把 API key、数据库密码等敏感信息，通过环境变量（export NOTION_API_KEY=xxx）或配置文件挂载进容器。这等于把钥匙直接塞进快递员的口袋里——万一快递员（sandbox 进程）被恶意代码劫持，钥匙就暴露了。Anthropic 的方案是：credential vault 在 sandbox 外部，由 Anthropic 的可信执行环境（TEE）管理；sandbox 内部只有一个临时的、短时效的、作用域极窄的 access token；当 tool call 发起时，这个 token 会被自动附加到 HTTP 请求头中，由外部的 credential gateway 进行实时鉴权和权限检查，再将真正的密钥注入到下游服务的调用链中。整个过程，sandbox 进程的内存空间里，永远看不到明文的NOTION_API_KEY。我们曾用 Burp Suite 抓包分析过 sandbox 内部发出的POST /v1/pages/search请求，header 里只有X-Anthropic-Sandbox-Token: eyJhbGciOi...，没有一丝一毫的密钥痕迹。这种设计，直接堵死了 LLM 注入攻击（Prompt Injection）中最危险的一条路：诱导模型生成curl -H "Authorization: Bearer xxx" https://api.notion.com/v1/pages这类命令。因为模型根本不知道xxx是什么。它只知道，调用notion_search_pages这个 tool，传入{ "query": "Q4 sales report" }，然后等待 harness 返回结果。sandbox 的生命周期也极其干净：一个 session 启动时创建，session 结束或超时（默认 24 小时）后自动销毁。没有残留进程，没有未清理的临时文件，没有 dangling network interfaces。它像一次性手术刀，用完即焚，杜绝了横向移动（lateral movement）的可能性。这才是真正意义上的 “production-grade sandboxing”，而不是 demo 里那种开着 root shell 的玩具。

3. 实操细节深挖：从 YAML 定义到生产部署的每一步

3.1 Agent 定义：YAML 是声明式编程的起点，不是配置文件

Anthropic 的 agent 定义，表面看是 YAML，实质上是一种受限的、面向 agent 行为的 DSL（Domain Specific Language）。它强制你以“行为契约”而非“实现细节”的方式思考。一个典型的sales_agent.yaml文件如下：

# sales_agent.yaml name: "Sales Development Agent" description: "Qualifies leads from LinkedIn and schedules demos via Calendly" system_prompt: | You are a senior sales development representative at Acme Corp. Your goal is to qualify inbound leads and book 30-minute discovery calls. Always ask for company size and current tech stack before proceeding. If lead is unqualified (e.g., student, non-tech), politely decline. tools: - name: "linkedin_lead_enrich" description: "Fetches detailed company info and contact person from LinkedIn URL" input_schema: type: "object" properties: linkedin_url: type: "string" format: "uri" required: ["linkedin_url"] - name: "calendly_schedule_demo" description: "Books a 30-min demo slot with the lead using Calendly" input_schema: type: "object" properties: email: type: "string" format: "email" first_name: type: "string" last_name: type: "string" timezone: type: "string" required: ["email", "first_name", "last_name", "timezone"] guardrails: - type: "content_moderation" severity_threshold: "high" - type: "pii_redaction" patterns: ["email", "phone", "ssn"]

这个 YAML 的每一行，都在定义一个不可协商的契约。system_prompt不是给模型的“建议”，而是 agent 的宪法，它决定了模型的 persona 和基本行为边界。tools下的input_schema是铁律，模型生成的 JSON 必须 100% 符合这个 schema，否则 harness 会直接拒绝执行，并返回一个清晰的 validation error。guardrails是硬性开关，不是可选项。实操中，我们发现最容易被忽略的是input_schema的严谨性。初期我们写过一个search_dbtool，schema 里只写了{"query": "string"}，结果模型有时会生成{"query": "SELECT * FROM users WHERE email = 'user@example.com'"}（带 SQL），有时又生成{"query": "users with email user@example.com"}（自然语言）。这导致下游数据库 connector 频繁报错。解决方案是：把 schema 写死到原子级别。最终版是：

- name: "search_db" description: "Searches the CRM database for leads matching criteria" input_schema: type: "object" properties: filters: type: "array" items: type: "object" properties: field: type: "string" enum: ["company_name", "industry", "employee_count", "status"] operator: type: "string" enum: ["equals", "contains", "gt", "lt"] value: type: ["string", "number"] required: ["field", "operator", "value"] limit: type: "integer" minimum: 1 maximum: 100 default: 10 required: ["filters"]

这个 schema 强制模型只能生成结构化的过滤条件，彻底杜绝了 SQL 注入和自然语言歧义。YAML 的价值，在于它把“意图”和“实现”彻底分开。你定义“我要做什么”，Anthropic 负责“怎么安全、可靠地做到”。这正是现代云原生架构的核心思想。

3.2 Session 生命周期管理：从创建、交互到归档的全流程

一个 production-ready 的 agent session，绝不是POST /sessions然后坐等结果那么简单。它是一个有始有终、可审计、可干预的业务流程。以下是我们在实际项目中梳理出的标准流程：

1. Session 创建 (POST /v1/sessions)：发送一个包含agent_id（对应上面的 YAML）、initial_input（用户的第一句话，如 “Hi, I saw your ad on LinkedIn”）和可选的metadata（如{"source": "linkedin", "campaign_id": "Q4_SALES"}）的请求。响应会返回一个唯一的session_id和一个session_url（用于前端嵌入）。

2. 交互循环 (POST /v1/sessions/{id}/messages)：这是核心。每次用户发消息，都向这个 endpoint 发送。请求体是纯文本（{"content": "What's the pricing?"}）。Harness 会自动：

   • 从 session 日志加载最新状态。
   • 将用户输入、历史事件摘要、system_prompt 拼接成新的 prompt。
   • 调用 Claude 模型。
   • 解析模型输出，提取 tool call 或 final response。
   • 如果是 tool call，执行execute(name, input)，并将结果写入 session 日志。
   • 如果是 final response，将其标记为message_type: "assistant"并写入日志。
   • 返回一个包含content（给用户的回复）、tool_calls（如果有）、next_step（下一步建议）的 JSON。

3. Human-in-the-Loop (HITL) 干预：当 agent 遇到无法处理的模糊请求（如 “帮我看看这个合同有没有风险？”），它会生成一个tool_call名为escalate_to_human，并附带{"reason": "requires legal review", "document_id": "doc_abc123"}。此时，session 日志会记录此事件，并触发一个 webhook 到你的内部工单系统。客服人员在工单系统里处理完后，调用POST /v1/sessions/{id}/human_response，传入处理结果。Harness 会把这个结果当作一次“用户输入”，无缝接入后续流程。

4. Session 归档与查询：Session 默认存活 24 小时。结束后，它不会被删除，而是进入archived状态。你可以随时用GET /v1/sessions/{id}获取完整日志，或用GET /v1/sessions?filter=agent_id:eq:sales_agent&sort_by=created_at:desc&limit=100进行批量查询。我们用这个接口每天凌晨自动生成一份 “昨日 agent 效能报告”，统计p50_time_to_first_token,tool_call_success_rate,human_escalation_rate等核心指标。

提示：time_to_first_token（TTFT）是衡量 agent 响应速度的黄金指标，而非端到端延迟。Anthropic 报告的 p50 TTFT 下降 60%，意味着用户从点击发送到看到第一个字的等待时间，从平均 1200ms 降到了 480ms。这对用户体验是质的飞跃。我们实测，在东京节点，使用 Claude 3.5，p50 TTFT 稳定在 380–420ms 区间。

3.3 定价模型与成本控制：$0.08/小时背后的精算逻辑

Anthropic 的定价$0.08 per session-hour of active runtime看似简单，但藏着精妙的成本控制逻辑。这里的 “session-hour” 不是 wall-clock time，而是指 session 处于active状态下的累计 CPU 时间。一个 session 从创建到结束，大部分时间其实是 idle（空闲）的——它在等待用户输入，或者等待一个异步 tool call（如发送邮件、生成报告）完成。在这段时间里，harness 进程是休眠的，不计费。只有当 harness 被唤醒、加载 context、调用模型、执行 tool 时，才会计入 runtime。这和 AWS Lambda 的计费模式（按 GB-seconds）异曲同工。我们做了个压力测试：模拟 1000 个并发 session，每个 session 平均每 5 分钟发起一次交互，每次交互平均消耗 1.2 秒 active runtime。那么，1000 个 session * (1.2秒/次 * 12次/小时) / 3600秒 ≈ 4 小时的 active runtime/hour。按 $0.08 计算，每小时成本仅 $0.32，远低于为这 1000 个 session 单独维护一个常驻 Kubernetes 集群的成本（节点费用、运维人力、监控告警）。更重要的是，这个定价模型天然鼓励高效设计。如果你的 agent 每次交互都要调用 5 个 tool，每个 tool 平均耗时 800ms，那么 active runtime 就会飙升。这倒逼你去优化 tool 的粒度——把fetch_user_profile和fetch_company_info合并成一个enrich_leadtool，把多个小 API 调用合并成一个批处理接口。成本控制，就这样变成了架构演进的驱动力。

4. 竞争格局全景扫描：为什么说 Anthropic 是在防守，而非开创

4.1 AWS Bedrock AgentCore：已经落地的“云原生”标准

当 Anthropic 在 2026 年 4 月高调宣布 Managed Agents 时，AWS Bedrock AgentCore 已经在生产环境里跑了整整五个月。它的 GA（General Availability）时间是 2025 年 11 月。这个时间差，不是技术落后，而是战略选择的不同。Bedrock AgentCore 的核心优势，在于它不是一个孤立的产品，而是深度融入 AWS 庞大生态的“云原生 runtime”。它的 session 运行在一个真正的 microVM（微型虚拟机）里，拥有完全隔离的 CPU、内存和文件系统，安全等级对标 EC2。一个 session 最长可运行 8 小时，远超 Anthropic 的 24 小时（但注意，是 24 小时 idle timeout，非 active time）。最关键的是，它是 framework-agnostic（框架无关）的。LangGraph、CrewAI、Strands，甚至是你自己用 Flask 写的一个 request-response loop，只要它能接收一个 JSON 输入、返回一个 JSON 输出，就能被 AgentCore 托管。模型选择也完全开放：你可以用 Claude，也可以用 Llama 3、Command-R+、或者你自己的微调模型，只要它在 Bedrock 上可用。我们团队曾用 AgentCore 托管了一个混合模型 agent：前两步用 Claude 做复杂推理，中间三步用 Llama 3 做低成本文本生成，最后一步用 Command-R+ 做结构化数据提取。整个流程在同一个 session 里无缝切换，API 调用完全透明。这背后是 AWS 的巨大优势：它不卖模型，它卖的是“运行一切”的能力。对于一个已经在用 AWS 的企业客户来说，AgentCore 不是“另一个需要评估的新服务”，而是“我现有云账单里，多勾选一个复选框就能用的功能”。它的 SDK 下载量在五个月内突破两百万次，不是因为营销做得好，而是因为它解决了开发者最痛的痛点：我不想再为 runtime 操心，我只想专注我的 agent 逻辑。

4.2 Google Vertex AI Agent Builder 与 Microsoft Azure AI Foundry：巨头的“全家桶”策略

Google 和 Microsoft 的策略，则是典型的“生态绑定”。Vertex AI Agent Builder 的核心是Agent Registry，它不是一个独立的 runtime，而是一个深度集成在 Apigee（Google 的 API 管理平台）之上的服务目录。你创建的每一个 agent，都会自动注册为一个 Apigee API。这意味着，你可以用 Apigee 的全套企业级能力来管理它：设置配额（rate limiting）、添加 OAuth2 认证、配置审计日志、甚至用 Apigee 的 Analytics 来分析 agent 的调用模式。一个销售 agent，可以被限制为每个用户每天最多调用 5 次；一个财务 agent，可以强制要求调用者必须持有finance_readscope 的 JWT token。这种设计，让 agent 从一个 AI 功能，瞬间升级为企业 IT 架构中的一个受控服务。Microsoft 的 Azure AI Foundry 更进一步，它把 AutoGen 和 Semantic Kernel 这两个开源框架，直接“编译”进了自己的 PaaS（Platform-as-a-Service）层。你不需要在自己的 VM 上安装 AutoGen，你只需要在 Foundry 的 UI 里拖拽几个组件（GroupChatManager,CodeExecutor,WebSearchTool），配置好参数，点击部署，Foundry 就会在后台为你启动一个完全托管的、基于 AutoGen 的 agent 集群。它的目标用户非常明确：那些已经深度使用 Microsoft 365、Teams、Dynamics 365 的企业。一个销售 agent，可以直接访问 Teams 的聊天历史、Dynamics 的客户数据、SharePoint 的产品文档，所有这些集成，都是开箱即用的。这三家巨头（AWS、Google、MS）的共同点是：它们不试图说服你“Claude 是最好的模型”，而是告诉你“无论你用哪个模型，我们的 runtime 都能让你省心、安全、合规”。这是一种降维打击。Anthropic 的 Managed Agents，无论架构多么优雅，定价多么合理，它都无法绕过一个事实：对于一个 AWS 重度用户，迁移到 Anthropic 的 runtime，意味着要额外管理一套身份认证、一套监控告警、一套成本中心。这笔迁移成本，往往远超 runtime 本身的费用。

4.3 开源势力的崛起：Daytona、Kubernetes SIG、Deer-flow —— 压力曲线正在形成

如果说巨头们提供了“开箱即用”的商业方案，那么开源社区则在构建“未来可期”的底层标准。2025 年初，Daytona 这个原本专注于开发者环境的公司，宣布全面转向 AI agent infrastructure。他们的核心产品Daytona Agent Runtime，主打一个极致的性能指标：sub-90ms sandbox spin-up time（亚 90 毫秒的沙箱启动时间）。这比 Anthropic 和 AWS 的百毫秒级启动快了一个数量级。他们是怎么做到的？答案是：放弃通用性，追求极致垂直。Daytona 的 sandbox 不是一个完整的 Linux 环境，而是一个高度定制的、基于 WebAssembly 的轻量级执行环境。它只支持 Python 和 JavaScript，只提供最基础的网络和文件 I/O，所有复杂的工具调用，都通过一个预置的、高性能的 gRPC client 来完成。这种“削足适履”式的优化，让它在特定场景（如高频、低延迟的金融行情分析 agent）下，拥有了无可比拟的优势。与此同时，Kubernetes 社区也行动起来了。Kubernetes SIG（Special Interest Group）在 2026 年 3 月正式发布了k8s-agent-sandbox项目。这是一个官方认可的、用于在 Kubernetes 集群内安全运行 agent 的 Operator。它利用 Kubernetes 原生的 Pod Security Admission (PSA) 和 Seccomp profiles，为每个 agent pod 设置了最严格的权限限制：readOnlyRootFilesystem: true,allowPrivilegeEscalation: false,capabilities: drop: ["ALL"]。它不提供任何高级功能，只做一件事：确保你的 agent 在 K8s 里跑得比在裸机上还安全。而 ByteDance 的deer-flow，则代表了另一种思路：它不是一个 runtime，而是一个“agent 操作系统”。它内置了 long-horizon planning（长周期规划）、subagent coordination（子 agent 协作）、self-reflection（自我反思）等高级能力。一个deer-flowagent 可以自主决定：“我现在需要先查市场数据，再写一份报告，最后把报告发给 CEO”，然后它会自动创建并调度多个 subagent 来完成这些任务。它的 GitHub Stars 在三个月内冲到 59,000，证明了开发者对“更高层次抽象”的强烈渴求。这三股力量，构成了对 proprietary runtime 的“压力曲线”：Daytona 用性能施压，K8s SIG 用标准和安全施压，deer-flow 用智能和抽象施压。它们共同指向一个结论：runtime 层的价值，正在被快速压缩。你很难再靠“更快的 sandbox”或“更酷的 harness”来建立长期壁垒。

5. 价值迁移地图：当 runtime 归零，钱流向哪里？

5.1 Trace Store：谁掌握了“agent 的 DNA”，谁就拥有了未来十年的入场券

当 runtime 变成水电煤一样的基础设施，所有关于“agent 做了什么”的原始数据，就从 runtime 的副产品，变成了最核心的资产。这就是 Trace Store（追踪存储）的诞生逻辑。目前，这个领域有三股主要力量在角力：

这三者的竞争，表面上是产品的竞争，实质上是“数据主权”的争夺。一个企业，如果它的所有 agent 日志都存在 Brainstore 里，那么当它想把 agent 迁移到 Azure AI Foundry 时，就必须先解决日志格式兼容性问题。反之，如果它用的是开源的 Phoenix，那么无论 runtime 换成哪家，日志都能无缝接入。因此，“trace portability”（追踪可移植性）成为了这个领域的终极战场。谁能定义一个被广泛接受的、开放的 trace schema（例如，类似 OpenTelemetry 的 OTLP 协议），谁就能成为事实上的标准。我们团队目前采用的是“Phoenix + 自研 adapter”的混合方案：所有 agent 的原始日志，都按 Phoenix 的 OpenTelemetry 格式上报；同时，我们开发了一个轻量级的 adapter，将 Phoenix 的数据，实时同步到一个内部的、基于 PostgreSQL 的审计数据库，供法务和风控部门直接查询。这个方案，既享受了开源生态的红利，又保留了对核心数据的绝对控制权。Trace Store 的价值，已经超越了技术层面。它正在成为企业的“AI 行为法典”。当一个 agent 因为错误的 tool call 导致客户损失，法庭上出示的，不再是模糊的“模型输出”，而是精确到毫秒的、不可篡改的event_log。这份日志，就是法律意义上的“证据”。

5.2 Governance & Policy：当 agent 获得权力，监管必须先行

Runtime 的 commoditization，带来了一个被严重低估的后果：agent 的能力边界，正在以前所未有的速度扩张。一个 agent，现在可以读取你的邮箱、修改你的日历、提交代码、甚至操作你的银行账户。这不再是一个技术问题，而是一个治理问题。AWS 在 2026 年 3 月将 AgentCore 的 policy controls 推向 GA，正是对这一趋势的回应。这些 policy，不再是简单的“允许/禁止”开关，而是精细到字段级别的动态规则。例如，一个财务 agent 的 policy 可能是：

{ "rules": [ { "name": "block_external_funds_transfer", "condition": "tool == 'bank_transfer' && input.amount > 10000", "action": "deny", "reason": "Transfer amount exceeds $10,000 requires manual approval" }, { "name": "require_pii_masking", "condition": "tool == 'email_send' && input.body contains 'SSN' || 'phone'", "action": "mask_pii", "masking_rules": ["SSN: XXX-XX-XXXX", "phone: XXX-XXX-XXXX"] } ] }

这套 policy，可以和企业的 IAM（Identity and Access Management）系统联动。一个 junior developer 的 agent，policy 可能只允许读取数据库；而一个 CTO 的 agent，则可以被授权执行terraform apply。OWASP（开放式网络应用安全项目）发布的《Agentic Top 10》，更是为这个领域提供了权威的风险清单，从L1: Prompt Injection到L10: Untrusted Tool Execution，每一项都对应着具体的、可落地的防护策略。这个领域的空白，是巨大的。目前，还没有一个统一的、跨云厂商的 policy language。AWS 有自己的，Google 有 Apigee 的，Azure 有 Foundry 的。这为企业的多云战略带来了新的复杂性。谁能率先推出一个被主流云厂商共同支持的、开源的 policy standard（比如叫OpenPolicyAgent-Agentic），谁就能在这个新兴的治理层，建立起难以撼动的领导地位。这将是下一个十年，企业级 AI 安全的主战场。

5.3 Vertical Agent Marketplaces：当“agent”变成商品，采购流程就变了

Salesforce 的 Agentforce ARR 在 2026 年 Q4 达到 8 亿美元，同比增长 169%，这个数字背后，是一个深刻的范式转移。它表明，企业采购 AI 的方式，正在从“买技术”转向“买结果”。没有人会因为 AWS 的 EC2 很快，就去买一堆服务器。同样，企业也不会因为 Anthropic 的 runtime 很稳定，就去采购它。企业采购的，是“能帮销售团队多签 20% 的合同”、“能让客服团队减少 30% 的重复劳动”、“能让研发团队把 bug 修复时间缩短一半”的具体能力。这就是 vertical agent marketplaces（垂直领域 agent 市场）的爆发逻辑。这些 marketplace，售卖的不是代码，而是经过行业验证的、开箱即用的“agent 合同”。一个 healthcare claims agent，它的 SLA（服务等级协议）会明确写：“99.5% 的理赔申请，将在 2 小时内完成初审，准确率 ≥ 98.7%”。一个 finance-research agent，它的合同会承诺：“每日提供 10 条基于 SEC filings 的、经 verified 的投资线索”。这种合同化的采购，彻底绕过了 CTO 和工程师，直接进入了 CFO 和业务部门的预算审批流程。开源社区已经敏锐地捕捉到了这一点。virattt/ai-hedge-fund这个项目，已经不是一个 demo，而是一个功能完备的、用于量化交易的 agent 套件，它集成了新闻情感分析、财报数据提取、技术指标计算、订单执行等多个模块。vxcontrol/pentagi则是一个面向网络安全的 offensive security agent，它可以自动执行渗透测试的 Recon、Scanning、Exploitation、Post-Exploitation 全流程。这些项目，正在为未来的 commercial vertical marketplaces 提供最宝贵的“种子模型”。当 runtime 归零，价值就会向上迁移。而最高的一层，永远是离业务最近、最能用金钱衡量 ROI 的那一层。Anthropic 的 Managed Agents，是一个优秀的、及时的、防御性的产品。但它不是故事的主角。主角，是那些正在构建 trace store、制定 governance policy、打造 vertical marketplace 的公司。它们才是下一个十年，AI 价值创造的真正引擎。我个人在实际操作中的体会是：与其花精力去争论哪个 runtime 更快，不如静下心来，好好梳理你的业务流程，找出那个最痛、最耗时、最能用 agent 自动化的环节。然后，用 Anthropic 或 AWS 的 runtime，把它快速做出来。做完之后，立刻把重心转向：如何把这次成功的经验，沉淀成一个可复用、可审计、可销售的 trace schema？如何为这个 agent 设计一套符合你公司安全规范的 policy？如何把这个 agent 的能力，包装成一个能让业务部门一眼就看懂价值的 vertical solution？这才是属于实干家的、真正的护城河。