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 日志本质是一个严格序列化的、带时间戳和因果链的 WALWrite-Ahead Log。每一次 tool call 的输入、输出、执行耗时、返回状态码每一次 human-in-the-loop 的审批动作、附带的评论每一次模型生成的 reasoning chain 和最终 action都被原子化地写入这个日志。它不依赖模型的记忆力它本身就是事实的唯一来源。这意味着你可以随时GET /sessions/{id}/events?from2026-04-08T14:22:00Zto2026-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_pagesinput是一个严格 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 的 JSONharness 就能无缝工作。我们团队在测试阶段做过对比用同一个 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_KEYxxx或配置文件挂载进容器。这等于把钥匙直接塞进快递员的口袋里——万一快递员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 行为的 DSLDomain 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_dbtoolschema 里只写了{query: string}结果模型有时会生成{query: SELECT * FROM users WHERE email userexample.com}带 SQL有时又生成{query: users with email userexample.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然后坐等结果那么简单。它是一个有始有终、可审计、可干预的业务流程。以下是我们在实际项目中梳理出的标准流程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用于前端嵌入。交互循环 (POST /v1/sessions/{id}/messages)这是核心。每次用户发消息都向这个 endpoint 发送。请求体是纯文本{content: Whats 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。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 会把这个结果当作一次“用户输入”无缝接入后续流程。Session 归档与查询Session 默认存活 24 小时。结束后它不会被删除而是进入archived状态。你可以随时用GET /v1/sessions/{id}获取完整日志或用GET /v1/sessions?filteragent_id:eq:sales_agentsort_bycreated_at:desclimit100进行批量查询。我们用这个接口每天凌晨自动生成一份 “昨日 agent 效能报告”统计p50_time_to_first_token,tool_call_success_rate,human_escalation_rate等核心指标。提示time_to_first_tokenTTFT是衡量 agent 响应速度的黄金指标而非端到端延迟。Anthropic 报告的 p50 TTFT 下降 60%意味着用户从点击发送到看到第一个字的等待时间从平均 1200ms 降到了 480ms。这对用户体验是质的飞跃。我们实测在东京节点使用 Claude 3.5p50 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 已经在生产环境里跑了整整五个月。它的 GAGeneral 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而是一个深度集成在 ApigeeGoogle 的 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 这两个开源框架直接“编译”进了自己的 PaaSPlatform-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 SIGSpecial 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追踪存储的诞生逻辑。目前这个领域有三股主要力量在角力公司/项目核心产品技术特点关键优势潜在短板BraintrustBrainstore专为 AI 交互日志设计的 OLAP 数据库基于 ClickHouse 改造极致的查询性能支持 PB 级日志的亚秒级聚合分析商业闭源价格高昂学习曲线陡峭ArizePhoenixApache 2.0 开源的 tracing observability 平台开源免费社区活跃与 LangChain/LlamaIndex 生态深度集成商业版功能如高级告警、SLA 保障需付费LangChainLangSmithLangChain 生态的默认 tracing 工具随 SDK 自动集成零配置开箱即用与 LangChain 代码完全同构生态锁定迁移到其他框架如 AutoGen成本高这三者的竞争表面上是产品的竞争实质上是“数据主权”的争夺。一个企业如果它的所有 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可以和企业的 IAMIdentity and Access Management系统联动。一个 junior developer 的 agentpolicy 可能只允许读取数据库而一个 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这才是属于实干家的、真正的护城河。
Agent Runtime 归零时代：从上下文管理到事件日志的范式革命
发布时间：2026/6/9 6:23:05
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 日志本质是一个严格序列化的、带时间戳和因果链的 WALWrite-Ahead Log。每一次 tool call 的输入、输出、执行耗时、返回状态码每一次 human-in-the-loop 的审批动作、附带的评论每一次模型生成的 reasoning chain 和最终 action都被原子化地写入这个日志。它不依赖模型的记忆力它本身就是事实的唯一来源。这意味着你可以随时GET /sessions/{id}/events?from2026-04-08T14:22:00Zto2026-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_pagesinput是一个严格 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 的 JSONharness 就能无缝工作。我们团队在测试阶段做过对比用同一个 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_KEYxxx或配置文件挂载进容器。这等于把钥匙直接塞进快递员的口袋里——万一快递员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 行为的 DSLDomain 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_dbtoolschema 里只写了{query: string}结果模型有时会生成{query: SELECT * FROM users WHERE email userexample.com}带 SQL有时又生成{query: users with email userexample.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然后坐等结果那么简单。它是一个有始有终、可审计、可干预的业务流程。以下是我们在实际项目中梳理出的标准流程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用于前端嵌入。交互循环 (POST /v1/sessions/{id}/messages)这是核心。每次用户发消息都向这个 endpoint 发送。请求体是纯文本{content: Whats 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。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 会把这个结果当作一次“用户输入”无缝接入后续流程。Session 归档与查询Session 默认存活 24 小时。结束后它不会被删除而是进入archived状态。你可以随时用GET /v1/sessions/{id}获取完整日志或用GET /v1/sessions?filteragent_id:eq:sales_agentsort_bycreated_at:desclimit100进行批量查询。我们用这个接口每天凌晨自动生成一份 “昨日 agent 效能报告”统计p50_time_to_first_token,tool_call_success_rate,human_escalation_rate等核心指标。提示time_to_first_tokenTTFT是衡量 agent 响应速度的黄金指标而非端到端延迟。Anthropic 报告的 p50 TTFT 下降 60%意味着用户从点击发送到看到第一个字的等待时间从平均 1200ms 降到了 480ms。这对用户体验是质的飞跃。我们实测在东京节点使用 Claude 3.5p50 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 已经在生产环境里跑了整整五个月。它的 GAGeneral 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而是一个深度集成在 ApigeeGoogle 的 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 这两个开源框架直接“编译”进了自己的 PaaSPlatform-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 SIGSpecial 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追踪存储的诞生逻辑。目前这个领域有三股主要力量在角力公司/项目核心产品技术特点关键优势潜在短板BraintrustBrainstore专为 AI 交互日志设计的 OLAP 数据库基于 ClickHouse 改造极致的查询性能支持 PB 级日志的亚秒级聚合分析商业闭源价格高昂学习曲线陡峭ArizePhoenixApache 2.0 开源的 tracing observability 平台开源免费社区活跃与 LangChain/LlamaIndex 生态深度集成商业版功能如高级告警、SLA 保障需付费LangChainLangSmithLangChain 生态的默认 tracing 工具随 SDK 自动集成零配置开箱即用与 LangChain 代码完全同构生态锁定迁移到其他框架如 AutoGen成本高这三者的竞争表面上是产品的竞争实质上是“数据主权”的争夺。一个企业如果它的所有 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可以和企业的 IAMIdentity and Access Management系统联动。一个 junior developer 的 agentpolicy 可能只允许读取数据库而一个 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这才是属于实干家的、真正的护城河。
相关文章
React 并发模式深度解析：Suspense 与 Transition 的渲染策略
React 并发模式深度解析：Suspense 与 Transition 的渲染策略一、React 渲染的"卡顿"根源：同步更新的阻塞效应 React 18 之前，所有状态更新都是同步渲染的。一个复杂组件树的状态更新，可能需要 100ms 以上的渲染时间&…
多维聚合实战指南：从GROUP BY到OLAP立方体构建
1. 项目概述：多维聚合中的数据操作，远不止GROUP BY那么简单“Part 20: Data Manipulation in Multi-Dimensional Aggregation”这个标题乍看像教科书里的章节编号，但如果你正在处理销售仪表盘、用户行为漏斗、IoT设备时序汇总，或是…
别再只看PSNR了！用PyTorch复现SRGAN，聊聊感知损失（Perceptual Loss）如何让AI修图更‘顺眼’
超越PSNR陷阱：用PyTorch实战SRGAN，揭秘感知损失如何重塑AI图像修复美学当你在老旧照片修复项目中反复调整参数，却发现PSNR值提升的同时，图像反而显得愈发"塑料感"；当游戏贴图增强后的数值报告完美࿰…
别再只认升压芯片了！聊聊电荷泵驱动NMOS的那些‘坑’：从原理到PCB布局避坑指南
电荷泵驱动NMOS的工程实践：从原理到PCB布局的深度避坑指南在电力电子设计中，NMOS管因其导通电阻低、成本效益高而广受欢迎，但上管驱动始终是工程师面临的挑战。传统升压芯片方案虽稳定，却存在成本高、布局复杂的问题。电荷泵电路以…
大模型容量与上下文窗口：从Token计费到LangGraph工程落地
1. 项目概述：当“大模型”三个字不再只是营销话术，而是你每天要和它掰手腕的工程现实你有没有在选型时被这些参数绕晕过？“7B参数”、“128K上下文”、“MoE架构”、“推理token成本0.0002美元”……这些词像一串串密码，贴在模型介…
GPT-4稀疏激活真相：MoE架构下2%激活率的工程本质
1. 项目概述：参数规模与稀疏激活的真相拆解“GPT-4 Has 1.8 Trillion Parameters. It Uses 2% of Them Per Token.”——这句话过去两年在技术社区反复刷屏，常被当作“大模型已突破算力瓶颈”的佐证，也频繁出现在自媒体标题、投资人简报甚至高…
【办公增效必备】，OpenClaw v2.7.9 主流 Skill 功能详解（包含安装包）
OpenClaw 最实用 Skill 技能推荐｜办公效率直接拉满（小白必开） OpenClaw（小龙虾）的核心亮点在于丰富的 Skill 技能扩展，开启对应功能后，它不再局限于基础对话交互，能够高效完成各类电…
【提升办公效率】，详解 OpenClaw 在 Windows 平台的安装与使用（包含安装包）
OpenClaw（小龙虾）Windows 部署指南 快速搭建本地 AI 数字员工 如今各类 AI 工具层出不穷，OpenClaw（也被大家称作小龙虾）作为热门开源 AI 智能体，主打电脑全流程自动化操作，凭借本地运行、易上手…
基于Python Socket的多人在线聊天室（含服务端+4个客户端+表情图标）
本文还有配套的精品资源，点击获取 简介：开箱即用的Python实时聊天系统，包含一个server.py服务端和四个独立客户端脚本（client-user-1.py到client-user-4.py），支持多用户同时连接、消息实时广播与基础表情…
5分钟上手：BilibiliDown——你的B站视频下载全能助手
5分钟上手：BilibiliDown——你的B站视频下载全能助手 【免费下载链接】BilibiliDown (GUI-多平台支持) B站 哔哩哔哩 视频下载器。支持稍后再看、收藏夹、UP主视频批量下载|Bilibili Video Downloader 😳 项目地址: https://gitcode.com/gh_mirrors/bi…
【AI】服务化部署：把AI Agent变成API服务
服务化部署：把AI Agent变成API服务📝 本章学习目标：本章聚焦安全与工程化，确保AI Agent稳定可靠运行。通过本章学习，你将全面掌握"服务化部署：把AI Agent变成API服务"这一核心主题。一、引言&…
Playnite：一站式游戏库管理器，告别多平台切换烦恼
Playnite：一站式游戏库管理器，告别多平台切换烦恼 【免费下载链接】Playnite Video game library manager with support for wide range of 3rd party libraries and game emulation support, providing one unified interface for your games. 项目地…
LED驱动技术全解析：从核心架构到实战选型与避坑指南
1. 从一颗灯珠到千亿市场：LED驱动的技术演进与商业逻辑十几年前，当我第一次从料盘上拿起一颗0603封装的白色LED时，它微弱的光晕和高达几块钱的单颗成本，让我很难想象今天它几乎照亮了我们生活的每一个角落。从手机屏幕的一抹背光&…
索引堆及其优化
索引堆及其优化 引言 索引堆是一种数据结构，广泛应用于计算机科学和软件工程领域。它主要用于解决优先队列问题，如最小堆和最大堆。本文将详细介绍索引堆的概念、实现方法以及优化策略。 索引堆的定义 索引堆是一种基于堆数据结构的索引机制。它通过维护一个堆来存储数据…
从零到日增237精准粉丝，我靠CSDN这张AI卡片爆了！手把手复刻全流程，含配置避坑清单
更多请点击： https://intelliparadigm.com 第一章：CSDN AI 数字营销的官方引流卡片是什么功能？ CSDN AI 数字营销平台推出的「官方引流卡片」，是一种面向技术创作者的轻量级、可嵌入式内容分发组件，专为提升博文、教程…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…