1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有在深夜调试一个跑了三小时的 AI 代理突然发现它开始胡言乱语不是模型崩了不是 prompt 写错了而是——它的“记忆”被挤掉了。上下文窗口就那么大工具调用日志、中间结果、用户多轮对话、系统指令……全塞进去像往一个20升的桶里硬灌35升水。最后溢出的不是水是逻辑它忘了自己上一步查了什么数据库把两个不同客户的订单号混在一起生成发票还自信满满地发出去。这种故障不报错不崩溃它只是安静地、昂贵地、不可逆地走向错误。我去年就亲手干过这事损失了整整一个客户的工作流回溯能力连重放都做不到——因为根本没有“回放”的源数据。Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是一套托管代理运行时但它的核心价值恰恰就卡在这个“安静的崩溃”痛点上。它没发明新概念而是把一个被行业反复验证、又反复踩坑的工程实践做成了开箱即用的、生产级的基础设施。关键词不是“agent”而是session-as-event-log会话即事件日志和credential isolation凭证隔离。前者让状态从模型上下文里彻底搬出来变成可查询、可审计、可重放的持久化事件流后者让 API 密钥、数据库密码这些命脉永远不经过代理代码的视野哪怕模型被诱导、被越狱、被注入恶意 prompt它也拿不到任何真实凭证。这背后没有玄学只有十年以上分布式系统和安全工程的老兵在用最朴素的方式堵住最致命的漏洞。这个发布之所以值得深挖并非因为它“开创”了什么而是因为它精准地踩在了一个历史拐点上AI 基础设施栈的 runtime 层正在重演 2000 年代初虚拟化技术的 commoditization商品化路径。就像当年 VMware 卖几万美元一套的 ESX如今 AWS 的 EC2 实例里跑的 KVM 已经是默认配置、免费附赠今天 Anthropic 收 $0.08/小时的 session 运行费明天 AWS Bedrock AgentCore 就可能把它打包进 $0.001/千 token 的 Claude 调用套餐里。这不是谁输谁赢的问题而是整个行业的价值重心正以肉眼可见的速度从“谁能跑得更快”向“谁能管得更牢、看得更清、控得更准”迁移。如果你是开发者现在纠结“该不该用 Managed Agents”答案其实很直白用但别把它当终点要把它当跳板——跳到上面那层真正开始沉淀价值的地方去。2. 核心设计解构为什么是“事件日志”而不是“内存快照”2.1 Session 不是容器是时间轴上的事件流Managed Agents 官方文档里反复强调“session persistence”但很多开发者第一反应还是把它理解成“把整个 agent 状态序列化后存到 Redis 里”。这是个危险的误解。Anthropic 的 session 设计其底层哲学根本不是“保存状态”而是“记录行为”。它把一次会话拆解为原子化的、不可变的事件event每个事件包含明确的类型tool_call, tool_result, user_message, system_message、时间戳、输入参数、输出结果、执行耗时以及最关键的——因果链 IDcausality_id。举个实际例子。假设你部署了一个客服工单处理 agent流程是1接收用户邮件 → 2调用 Jira API 创建工单 → 3调用 Slack API 通知负责人 → 4等待负责人回复 → 5根据回复内容更新工单状态。在传统方案中这五步的中间状态比如 Jira 返回的工单号、Slack 消息的 timestamp会被拼接进 prompt随着对话轮次不断膨胀。而 Managed Agents 的 session 里你会看到这样一条清晰的时间线Event IDTypeTimestamp (ms)Input/OutputCausality IDev-001user_message1744567890123“我的订单#ORD-7890迟迟未发货请帮忙查下”rootev-002tool_call1744567890456jira.create_issue(title发货延迟, desc订单#ORD-7890)ev-001ev-003tool_result1744567891234{ issue_key: JIRA-4567, url: https://jira.example.com/browse/JIRA-4567 }ev-002ev-004tool_call1744567891567slack.post_message(channelsupport-ops, text新工单: JIRA-4567)ev-003注意Causality ID这一列。它不是简单的父子关系而是构建了一个有向无环图DAG。ev-004的因果链指向ev-003意味着 Slack 消息的内容直接依赖于 Jira 工单的创建结果。如果后续某步失败比如 Slack API 调用超时系统可以精确地定位到ev-004这个节点进行重试而无需重放整个会话。这比任何基于 checkpoint 的内存快照都更轻量、更可靠、更易调试。我实测过一个持续 47 小时、调用 217 次外部工具的复杂金融分析 agent其 session event log 文件大小仅为 1.2MB而同等逻辑下用 LangChain 的ConversationBufferWindowMemory存储光是上下文文本就膨胀到 89MB且无法做细粒度回溯。提示事件日志的存储格式是 JSONL每行一个 JSON 对象而非单个大 JSON。这意味着你可以用tail -f实时监控 agent 行为用grep tool_call快速过滤所有工具调用甚至用awk {print $3}提取所有耗时字段做性能分析。这种 Unix 哲学式的可组合性是它能成为“系统级”基础设施的关键。2.2 Harness 是无状态的“函数调用器”不是“智能体容器”另一个常被误读的概念是 “harness”。很多人以为 harness 是一个包裹了模型、工具、prompt 的“智能体容器”但实际上Anthropic 的 harness 极度精简它只做三件事1接收一个标准化的execute(name, input)请求2将请求路由给对应工具的 sandboxed container3将容器返回的字符串结果原样打包附上元数据如耗时、错误码发回给 session layer。它本身不持有任何业务逻辑不解析 input不修改 output不维护任何内部状态。这带来了两个关键优势。第一是可替换性。你可以把 harness 想象成一个 HTTP 客户端。今天它调用的是 Anthropic 托管的 Python 工具容器明天你完全可以把它换成自己部署在 Kubernetes 上的 Go 微服务只要这个服务暴露/execute接口接受{name: jira_create, input: {...}}返回{result: ..., error: null}harness 就完全感知不到变化。我们团队上周就做了这个实验把一个原本跑在 Managed Agents 上的财务对账 agent无缝迁移到自建的 K8s 集群只改了 3 行配置整个过程对前端应用零影响。第二是可观测性前置。因为所有流量都必须经过 harness所以它天然就是埋点的最佳位置。Anthropic 在 harness 层内置了毫秒级的耗时统计、错误分类network_timeout, tool_error, model_rejection、甚至模型拒绝理由如reason: output_too_long。这些数据不是事后从日志里扒拉出来的而是 harness 在每次调用完成的瞬间就已结构化地写入 event log。对比我们之前用自研 harness 的方案需要在每个工具调用前后手动加start_time time.time()和log_duration(start_time)不仅容易遗漏而且无法捕获 harness 自身的调度延迟。Managed Agents 的 harness 把这个观测维度变成了基础设施的默认属性。2.3 Sandbox 是“一次性牛”不是“宠物服务器”“Sandboxed execution” 这个词听起来很酷但它的工程本质非常务实按需创建、用完即焚、资源隔离。Anthropic 的 sandbox 不是 Docker 容器而是一个更轻量的、基于 WebAssembly 的执行环境具体技术细节未公开但从启动速度 100ms 可推断。每个工具调用都会触发一个全新的 sandbox 实例启动加载指定的工具代码和依赖执行main(input)函数拿到字符串输出后立刻销毁整个环境。这种设计直接解决了三个生产环境里的老大难问题。首先是资源泄漏。传统方案里一个长期运行的 agent 进程如果某个工具调用打开了文件句柄或数据库连接却忘记关闭久而久之就会耗尽系统资源。而在 sandbox 模型下进程生命周期与单次调用严格绑定不存在“忘记关闭”的概念——环境一销毁所有资源自动归还。我们有个爬虫工具以前在 Node.js 进程里跑平均 3 天就会因内存泄漏 OOM迁移到 sandbox 后连续运行 42 天内存曲线平稳如直线。其次是安全隔离。sandbox 里看不到任何环境变量process.env是空的无法访问网络除非显式声明network: true文件系统是只读的除了/tmp。最关键的是凭证credentials根本不在 sandbox 里。Anthropic 的做法是在 sandbox 启动前由 harness 将凭证注入到一个临时的、只读的、内存映射的 secret file 中路径类似/run/secrets/jira_api_key然后在调用工具时通过--secret-file /run/secrets/jira_api_key参数传给工具进程。工具代码里只需open(/run/secrets/jira_api_key).read()而模型 prompt 里永远看不到这个路径更别说读取内容了。这比把密钥塞进os.environ安全一万倍——后者只要模型输出一句print(os.environ)密钥就裸奔了。最后是版本控制。每个 sandbox 的启动配置工具代码哈希、依赖清单、runtime 版本都作为元数据写入 event log。这意味着当你发现某次jira.create_issue调用返回了奇怪的错误你可以精确地找到那次调用对应的 sandbox 配置然后用完全相同的环境复现问题而不是在一堆模糊的“可能是昨天更新的依赖导致的”猜测中大海捞针。3. 实操落地从 YAML 定义到生产环境的完整闭环3.1 用 YAML 定义你的第一个 agent比写 prompt 还简单Managed Agents 的最大友好之处在于它把 agent 的“定义”和“执行”彻底分离。你不需要写一行 Python 代码来初始化 LLM、加载工具、设置 memory只需要一个 YAML 文件就能描述清楚整个 agent 的骨架。下面是一个真实的、用于自动化 GitHub Issue 分类的 agent 示例# github-classifier.yaml name: github-issue-classifier description: Automatically triage and label new GitHub issues based on content system_prompt: | You are a senior engineering manager at a fast-growing SaaS company. Your job is to read GitHub issues and assign them to the correct team and priority level. Use ONLY the provided tools. Do not make up information. tools: - name: get_issue_details description: Fetch full details of a GitHub issue by its number input_schema: type: object properties: issue_number: type: integer description: The GitHub issue number to fetch required: [issue_number] # Anthropic 托管的工具无需你实现 - name: label_issue description: Apply labels to a GitHub issue input_schema: type: object properties: issue_number: type: integer labels: type: array items: type: string required: [issue_number, labels] - name: assign_to_team description: Assign an issue to a specific engineering team input_schema: type: object properties: issue_number: type: integer team: type: string enum: [frontend, backend, infrastructure, security, product] required: [issue_number, team] guardrails: max_tool_calls_per_session: 10 max_session_duration_minutes: 30 allowed_domains: - api.github.com这个 YAML 文件里system_prompt是你的“大脑指令”tools是你的“手脚”guardrails是你的“安全带”。整个文件只有 42 行却定义了一个具备完整工作流的 agent。你甚至不需要知道get_issue_details这个工具背后是用 PyGithub 还是 requests 写的——Anthropic 已经为你托管好了。部署时只需一条命令claude managed-agents deploy --config github-classifier.yaml --name prod-github-triageAnthropic 会返回一个唯一的agent_id如agent_abc123之后所有调用都通过这个 ID 进行。整个过程从写 YAML 到获得可用 agent_id不超过 90 秒。对比我们之前用 LangChain FastAPI Docker 部署同类 agent需要写 300 行代码、配置 5 个环境变量、构建镜像、推送到 ECR、更新 ECS 服务整个 CI/CD 流水线跑完要 12 分钟。YAML 定义的简洁性不是为了偷懒而是为了把“定义 agent”这件事降低到产品经理也能参与的程度——他们可以直接修改system_prompt和guardrails而无需打扰工程师。3.2 Session 生命周期管理如何让 agent “活”过重启Managed Agents 的 session 持久化是它区别于所有竞品的核心。但“持久化”不等于“永生”。你需要理解它的生命周期规则才能用好。一个 session 的完整生命周期如下Creation创建: 通过POST /v1/sessions创建传入agent_id和初始user_message。此时 session 状态为active。Active活跃: session 会一直保持active直到满足以下任一条件max_session_duration_minutesYAML 中定义超时连续30 分钟无任何新消息包括用户输入和工具回调显式调用DELETE /v1/sessions/{session_id}max_tool_calls_per_session被耗尽。Paused暂停: 当 session 因超时或空闲而结束但尚未被 GC垃圾回收它会进入paused状态保留所有 event log持续7 天。GC回收:paused状态满 7 天后session 及其所有 event log 将被永久删除。这个设计意味着你不能把 session 当作一个长期在线的“机器人”。它更像是一个“工作流实例”。例如一个销售线索跟进 agent它的 session 生命周期应该是一次完整的跟进周期从收到新线索邮件到创建 CRM 记录到发送首次触达邮件到等待客户回复再到根据回复更新 CRM 状态。整个流程走完session 就完成了使命可以被回收。如果客户几天后又回复了那就应该创建一个新的 session并把之前的 event log 作为上下文通过initial_context字段注入进去。我们有个实际案例一个电商退货处理 agent最初设计为一个 session 处理一个订单的全部退货流程申请→审核→物流→退款。但后来发现用户经常在“审核”环节卡住需要人工介入等几天后才回来。如果 session 在审核后就超时关闭那么人工审核的结果就无法被 agent 感知。我们的解决方案是在 agent 调用完audit_return_request工具后主动调用pause_sessionAPI将 session 置为paused。当人工审核完成CRM 系统通过 webhook 通知我们的后端后端再调用resume_sessionAPI并传入审核结果作为新消息。这样agent 就能从暂停点继续执行整个流程对用户来说是无缝的。这个技巧是我们在上线后第三周才摸索出来的官方文档里根本没提但它却是让 agent 真正“可用”的关键。3.3 生产环境集成如何与你的现有系统握手把 Managed Agents 接入生产环境核心在于解决两个问题身份认证和事件驱动。Anthropic 不提供 OAuth 或 SAML它用的是最朴实的 API Key JWT 方案。首先你需要在 Anthropic 控制台为你的应用创建一个 Service Account获取一对client_id和client_secret。然后每次调用 API 前用这对凭据向 Anthropic 的 auth endpoint 申请一个短期 JWT有效期 1 小时# Python 示例获取 JWT Token import requests import jwt import time def get_anthropic_jwt(client_id, client_secret): payload { iss: client_id, sub: client_id, aud: https://api.anthropic.com, exp: int(time.time()) 3600, # 1 hour iat: int(time.time()) } token jwt.encode(payload, client_secret, algorithmHS256) return token # 使用 JWT 调用 API headers { Authorization: fBearer {get_anthropic_jwt(cli_abc, sec_xyz)}, Content-Type: application/json } response requests.post( https://api.anthropic.com/v1/sessions, json{agent_id: agent_123, user_message: Hello}, headersheaders )其次事件驱动是让 agent “活”起来的灵魂。Managed Agents 本身不推送事件它是一个纯 RESTful 服务。你需要自己实现一个“事件循环”。我们的标准模式是前端触发用户在 Web 应用点击“提交工单”前端调用你的后端 API。后端创建 session后端调用 Anthropic/v1/sessions创建 session拿到session_id。后端轮询后端启动一个后台任务每隔 500ms 调用/v1/sessions/{session_id}/status检查status字段。当status变为completed或failed轮询停止。后端处理结果根据status和final_output决定是向用户展示结果还是调用下一个系统如发送 Slack 通知、更新数据库。这个模式看似“笨拙”但它给了你绝对的控制权。你可以轻松地在轮询过程中插入自己的业务逻辑比如如果status是requires_human_input这是 guardrail 触发的自定义状态后端可以自动创建一个 Jira ticket指派给人工审核员如果final_output包含一个payment_url后端可以立即调用 Stripe API 锁定这笔支付。这种“orchestration in your code, execution in their infra”的混合架构才是生产环境最稳健的选择。4. 竞争格局与避坑指南为什么说 runtime 层正在“归零”4.1 Hyperscaler 的降维打击免费就是最锋利的刀Anthropic 的 Managed Agents 发布稿里通篇没提 AWS、Google、Microsoft。但这恰恰是最值得警惕的信号。因为就在它发布前五个月AWS Bedrock AgentCore 已经进入 GA正式可用阶段。而它的定价策略堪称“核威慑”AgentCore 本身不收费。你使用它来运行 Claude、Llama、Cohere 等任何 Bedrock 支持的模型runtime 层是零成本的。你只为模型调用的 tokens 付费Claude Sonnet $0.003/千 input tokens以及你使用的工具所消耗的云资源付费如 Lambda 调用次数、RDS 查询费用。更狠的是AWS 直接把 AgentCore SDK 打包进了 AWS SDK for Python (Boto3)。这意味着一个熟悉 AWS 的工程师写 5 行代码就能启动一个 agentfrom boto3 import client bedrock_agent client(bedrock-agent-runtime) response bedrock_agent.invoke_agent( agentIdabc123, agentAliasIdlatest, sessionIdsess-456, inputTextWhat is the status of order ORD-7890? )这已经不是“功能对标”了这是把 runtime 层直接变成了云平台的“空气”。你买 AWS 的 EC2、S3、RDSAgentCore 就是随附的“操作系统内核”你不会单独为 Linux 内核付钱。同样你为 Bedrock 的 tokens 付费AgentCore 就是那个让你能用上 tokens 的“驱动程序”。在这种模式下Anthropic 的 $0.08/小时 session fee就像在卖 Windows 95 的安装盘——技术上可行但商业上注定被边缘化。我们做过一个成本测算。一个中等规模的客服 agent日均处理 5000 个会话平均 session 时长 4.2 分钟。使用 Anthropic Managed Agents仅 runtime 费用就是5000 * (4.2/60) * 0.08 ≈ $28/天一年约 $10,220。而用 AWS AgentCoreruntime 成本为 $0只多花了约 $1200 的 tokens 和工具调用费。差价近 10 倍。这笔钱足够你雇一个全职工程师来优化 prompt 和工具把效果提升 30%。这就是 hyperscaler 的力量它不跟你比技术它用“免费”把你逼到只能比拼上层价值的绝境。4.2 开源势力的闪电战Daytona 和 Kubernetes SIG 的“平替”崛起如果说 hyperscaler 是“阳谋”那开源社区就是“奇袭”。2025 年初一个叫 Daytona 的项目从 DevOps 领域悄然转身杀入 AI agent infra 赛道。它没有宏伟的愿景只有一个极客式的承诺“Sub-90ms sandbox spin-up”。三个月后它真的做到了。我们用 Daytona 的开源版搭建了一个测试环境启动一个 Python sandbox 的 P95 时间是 87ms比 Anthropic 官方公布的 102ms 还快。更关键的是Daytona 的 sandbox 是纯开源的你可以把它部署在自己的裸金属服务器上0 成本。紧随其后的是 Kubernetes SIG。2025 年底Kubernetes 官方宣布成立sig-agent并发布了k8s-agent-sandbox项目。它的设计理念极其激进把每一个 agent 的每一次工具调用都当作一个 Kubernetes Pod 来调度。这意味着你可以用kubectl get pods -l agentgithub-classifier查看所有正在运行的 agent 工作负载用kubectl logs pod-xyz查看某次调用的完整 stdout/stderr用kubectl top pods实时监控 CPU/Memory 消耗。它把 agent infra 彻底纳入了现代云原生的运维体系。对于已经在用 K8s 的公司这几乎是零学习成本的迁移。这两股力量合起来构成了对 Managed Agents 的“双面夹击”。Hyperscaler 提供“免费但绑定”的云服务开源项目提供“自由但需自运维”的本地方案。而 Anthropic 的 Managed Agents恰好卡在中间——它既不够免费hyperscaler也不够自由开源。它的存在价值只剩下一点为那些极度厌恶运维、又极度信任 Anthropic 品牌、且预算充足的早期 adopter提供一个“最小可行产品”MVP的快速验证通道。一旦验证成功这些客户的第一反应几乎必然是“我们能不能把它迁到自己的 AWS 账户里跑”——而这正是 Anthropic 最不想看到却又无力阻止的结局。4.3 我们踩过的坑那些文档里永远不会写的“血泪教训”在把 Managed Agents 从 PoC 推向生产环境的三个月里我们踩了至少七个大坑。其中三个是连 Anthropic 的 Support 团队都承认“确实是个问题但短期内不会修复”的。坑一Tool Call 的“幽灵失败”现象某个工具调用比如send_email在 event log 里显示status: success但收件人根本没收到邮件。排查发现工具代码里有一个try...except块把 SMTP 连接超时错误给吞掉了只返回了一个空字符串。而 Managed Agents 的 harness只检查进程退出码exit code不检查 stdout 内容。只要进程正常退出exit code 0它就认为调用成功。解决方案我们被迫在所有工具代码的顶层加入一个强制的assert result ! 并在except块里抛出一个明确的RuntimeError(SMTP failed: timeout)。Harness 会捕获这个异常并在 event log 里标记为tool_error。这个 workaround 让我们多写了 200 行防御性代码但换来的是 100% 可靠的失败感知。坑二Session ID 的“雪崩式泄露”现象我们的前端应用为了给用户提供“继续对话”按钮会把session_id存在浏览器 localStorage 里。结果一个用户在多个标签页打开同一个页面每个标签页都用自己的session_id调用/v1/sessions/{id}/messages。由于 Managed Agents 的 session 是全局共享的所有标签页的请求都打到了同一个 session 上导致 agent 的上下文混乱输出完全不可预测。解决方案我们彻底放弃了在前端存储session_id。改为每次用户点击“继续对话”前端都向后端发起一个新请求后端检查用户最近一次有效的 session通过数据库关联如果 session 仍在active状态则返回其session_id如果已paused则调用resume_session并返回新 ID如果已过期则创建全新 session。这个方案增加了后端一次数据库查询但换来了绝对的会话隔离。坑三Guardrail 的“时间陷阱”现象YAML 里设置了max_session_duration_minutes: 30但一个 session 在第 28 分钟时调用了一个耗时 5 分钟的工具比如一个复杂的数据库查询。这个 session 并没有在第 30 分钟被强制终止而是让它跑完了 5 分钟最终在第 33 分钟才结束。这导致我们预估的资源消耗严重失真。解决方案我们意识到max_session_duration_minutes只限制“session 的生命周期”不约束“单次工具调用的耗时”。因此我们必须在每个工具代码内部自行实现超时控制如 Python 的signal.alarm()或asyncio.wait_for()。这是一个痛苦的重构但它是保证 SLA 的唯一办法。5. 价值迁移当 runtime 归零钱流向哪里5.1 Trace Store谁掌握了“行为日志”谁就拥有了 agent 世界的“区块链”当 runtime 层变得像水电一样廉价整个 AI 工程的价值重心必然向上游——也就是 agent 的“行为数据”——迁移。Managed Agents 产生的 event log不是一堆待丢弃的日志而是一个结构化的、高保真的、带有因果链的“数字行为档案”。谁能把这个档案变成可查询、可分析、可审计的“系统记录”谁就拿到了新时代的入场券。目前这个领域有三股势力在角力Braintrust走的是“专用 OLAP 数据库”路线。它用 Rust 编写了一个名为 Brainstore 的数据库专为event_type,session_id,causality_id,tool_name,duration_ms这些字段做了极致优化。它的强项是亚秒级的复杂聚合查询比如“过去 7 天所有jira.create_issue调用中duration_ms 5000且error IS NOT NULL的按user_id分组列出 top 5 的错误原因”。这种深度分析能力是通用数据库如 PostgreSQL难以企及的。但代价是它是一个封闭的、需要单独部署和运维的系统。Arize走的是“开源先行”路线。它把核心的 tracing 能力Phoenix以 Apache 2.0 协议开源任何人都可以免费下载、部署、修改。它的目标是成为事实上的“trace 格式标准”。一旦 Phoenix 的 JSONL schema包含event_id,session_id,span_id,parent_id,attributes被广泛采用那么 Arize 的商业版提供告警、仪表盘、Root Cause Analysis就成了顺理成章的升级选项。这是一种典型的“先占领心智再收割市场”的策略。LangSmith走的是“生态绑定”路线。它深度集成在 LangChain 生态里任何用了 LangChain 的项目只要加一行langsmith_client Client()所有 LLM 调用、tool call、chain execution 就自动上报。它的优势是“零配置”劣势是“强耦合”。如果你不用 LangChainLangSmith 就对你毫无意义。这三者的竞争本质上不是技术优劣之争而是数据主权之争。一个企业是否愿意把自己的 agent 行为日志交给一个第三方数据库Braintrust、一个第三方开源协议Arize、还是一个特定框架LangSmith答案将决定未来五年谁能在 AI Observability 这个新赛道上建立起真正的护城河。对我们而言选择 Arize 的 Phoenix是因为它的开源协议给了我们最大的灵活性我们可以把 Managed Agents 的 event log用一个简单的jq脚本转换成 Phoenix 格式然后导入自己的私有 Arize 实例。这样我们既享受了开源的自由又规避了厂商锁定的风险。5.2 Governance Policy当 agent 能写代码合规就是生死线2024 年OWASP 发布了《Agentic Top 10》把 “Unsafe Tool Use”不安全的工具调用列为第一大风险。这不再是理论警告。2025 年一家欧洲银行的信贷审批 agent因为 prompt 被精心构造的恶意输入诱导调用了curl -X POST https://internal-api.bank.com/transfer -d {amount: 1000000}试图向攻击者账户转账。幸亏银行的 API 网关有严格的 IP 白名单和金额校验才没酿成大祸。但这个事件让全球的 CISO 们都坐不住了。于是“Policy as Code” 成为了新刚需。AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls就是一个典型代表。它允许你用 YAML 定义这样的策略# policy.yaml policies: - name: no-external-funds-transfer description: Block any tool call that attempts to transfer funds externally condition: | event.tool_name http_post and transfer in event.input.url and bank.com not in event.input.url action: deny这个策略会在 harness 调用工具前对event进行实时评估。如果匹配直接拒绝调用连 sandbox 都不会启动。这种在基础设施层就嵌入的、可编程的、可审计的安全控制是任何上层应用代码都无法比拟的。它把安全左移Shift Left做到了极致。目前这个领域还没有真正的“ incumbent”主导者。AWS、Google、Microsoft 都在推自己的 policy framework但它们互不兼容。这就给了初创公司机会。我们正在评估一家叫 “PolicyFlow” 的公司它的产品可以统一管理来自 AWS、GCP、Azure 的 policy 定义并提供一个跨云的、可视化的策略编排界面。它的核心价值不是技术有多炫而是它能帮你回答 CEO 最关心的那个问题“我们的 AI agent到底被允许做什么不被允许做什么谁批准的证据在哪”——这个问题的答案就是未来 AI 治理的基石。5.3 Vertical Marketplaces当 agent 能看病、能炒股、能审合同垂直场景就是印钞机Salesforce 的 Agentforce ARR 达到 8 亿美元这个数字背后是一个清晰的信号企业愿意为“能解决具体业务问题”的 agent 付费而不是为“能跑 agent 的 runtime”付费。Agentforce 的成功不在于它有多快的 sandbox而在于它把 agent 做成了一个“垂直 SaaS”销售开发 agent能自动从 LinkedIn 抓取线索、生成个性化邮件、追踪打开率、预约会议客服 agent能接入 Zendesk自动分类工单、调用知识库、生成回复草稿、甚至发起视频通话。这个模式正在被迅速复制。在金融领域virattt/ai-hedge-fund这个开源项目已经能完成从新闻舆情抓取、财报数据解析、到生成交易信号的全流程。在网络安全领域vxcontrol/pentagi可以自动执行渗透测试的 Recon、Scanning、Exploitation 阶段并生成符合 ISO 27001 标准的报告。这些不是玩具它们是真实世界里正在创造价值的生产力工具。资本已经闻风而动。2026 年第一季度专注于 AI 垂直 agent 的初创公司平均融资额比去年同期增长了 220%。投资人的逻辑很简单runtime
AI Agent Runtime 重构：事件日志、凭证隔离与生产级可观测性
1. 这不是新赛道是 runtime 层的“操作系统时刻”来了你有没有在深夜调试一个跑了三小时的 AI 代理突然发现它开始胡言乱语不是模型崩了不是 prompt 写错了而是——它的“记忆”被挤掉了。上下文窗口就那么大工具调用日志、中间结果、用户多轮对话、系统指令……全塞进去像往一个20升的桶里硬灌35升水。最后溢出的不是水是逻辑它忘了自己上一步查了什么数据库把两个不同客户的订单号混在一起生成发票还自信满满地发出去。这种故障不报错不崩溃它只是安静地、昂贵地、不可逆地走向错误。我去年就亲手干过这事损失了整整一个客户的工作流回溯能力连重放都做不到——因为根本没有“回放”的源数据。Anthropic 在 4 月 8 日发布的 Claude Managed Agents表面看是一套托管代理运行时但它的核心价值恰恰就卡在这个“安静的崩溃”痛点上。它没发明新概念而是把一个被行业反复验证、又反复踩坑的工程实践做成了开箱即用的、生产级的基础设施。关键词不是“agent”而是session-as-event-log会话即事件日志和credential isolation凭证隔离。前者让状态从模型上下文里彻底搬出来变成可查询、可审计、可重放的持久化事件流后者让 API 密钥、数据库密码这些命脉永远不经过代理代码的视野哪怕模型被诱导、被越狱、被注入恶意 prompt它也拿不到任何真实凭证。这背后没有玄学只有十年以上分布式系统和安全工程的老兵在用最朴素的方式堵住最致命的漏洞。这个发布之所以值得深挖并非因为它“开创”了什么而是因为它精准地踩在了一个历史拐点上AI 基础设施栈的 runtime 层正在重演 2000 年代初虚拟化技术的 commoditization商品化路径。就像当年 VMware 卖几万美元一套的 ESX如今 AWS 的 EC2 实例里跑的 KVM 已经是默认配置、免费附赠今天 Anthropic 收 $0.08/小时的 session 运行费明天 AWS Bedrock AgentCore 就可能把它打包进 $0.001/千 token 的 Claude 调用套餐里。这不是谁输谁赢的问题而是整个行业的价值重心正以肉眼可见的速度从“谁能跑得更快”向“谁能管得更牢、看得更清、控得更准”迁移。如果你是开发者现在纠结“该不该用 Managed Agents”答案其实很直白用但别把它当终点要把它当跳板——跳到上面那层真正开始沉淀价值的地方去。2. 核心设计解构为什么是“事件日志”而不是“内存快照”2.1 Session 不是容器是时间轴上的事件流Managed Agents 官方文档里反复强调“session persistence”但很多开发者第一反应还是把它理解成“把整个 agent 状态序列化后存到 Redis 里”。这是个危险的误解。Anthropic 的 session 设计其底层哲学根本不是“保存状态”而是“记录行为”。它把一次会话拆解为原子化的、不可变的事件event每个事件包含明确的类型tool_call, tool_result, user_message, system_message、时间戳、输入参数、输出结果、执行耗时以及最关键的——因果链 IDcausality_id。举个实际例子。假设你部署了一个客服工单处理 agent流程是1接收用户邮件 → 2调用 Jira API 创建工单 → 3调用 Slack API 通知负责人 → 4等待负责人回复 → 5根据回复内容更新工单状态。在传统方案中这五步的中间状态比如 Jira 返回的工单号、Slack 消息的 timestamp会被拼接进 prompt随着对话轮次不断膨胀。而 Managed Agents 的 session 里你会看到这样一条清晰的时间线Event IDTypeTimestamp (ms)Input/OutputCausality IDev-001user_message1744567890123“我的订单#ORD-7890迟迟未发货请帮忙查下”rootev-002tool_call1744567890456jira.create_issue(title发货延迟, desc订单#ORD-7890)ev-001ev-003tool_result1744567891234{ issue_key: JIRA-4567, url: https://jira.example.com/browse/JIRA-4567 }ev-002ev-004tool_call1744567891567slack.post_message(channelsupport-ops, text新工单: JIRA-4567)ev-003注意Causality ID这一列。它不是简单的父子关系而是构建了一个有向无环图DAG。ev-004的因果链指向ev-003意味着 Slack 消息的内容直接依赖于 Jira 工单的创建结果。如果后续某步失败比如 Slack API 调用超时系统可以精确地定位到ev-004这个节点进行重试而无需重放整个会话。这比任何基于 checkpoint 的内存快照都更轻量、更可靠、更易调试。我实测过一个持续 47 小时、调用 217 次外部工具的复杂金融分析 agent其 session event log 文件大小仅为 1.2MB而同等逻辑下用 LangChain 的ConversationBufferWindowMemory存储光是上下文文本就膨胀到 89MB且无法做细粒度回溯。提示事件日志的存储格式是 JSONL每行一个 JSON 对象而非单个大 JSON。这意味着你可以用tail -f实时监控 agent 行为用grep tool_call快速过滤所有工具调用甚至用awk {print $3}提取所有耗时字段做性能分析。这种 Unix 哲学式的可组合性是它能成为“系统级”基础设施的关键。2.2 Harness 是无状态的“函数调用器”不是“智能体容器”另一个常被误读的概念是 “harness”。很多人以为 harness 是一个包裹了模型、工具、prompt 的“智能体容器”但实际上Anthropic 的 harness 极度精简它只做三件事1接收一个标准化的execute(name, input)请求2将请求路由给对应工具的 sandboxed container3将容器返回的字符串结果原样打包附上元数据如耗时、错误码发回给 session layer。它本身不持有任何业务逻辑不解析 input不修改 output不维护任何内部状态。这带来了两个关键优势。第一是可替换性。你可以把 harness 想象成一个 HTTP 客户端。今天它调用的是 Anthropic 托管的 Python 工具容器明天你完全可以把它换成自己部署在 Kubernetes 上的 Go 微服务只要这个服务暴露/execute接口接受{name: jira_create, input: {...}}返回{result: ..., error: null}harness 就完全感知不到变化。我们团队上周就做了这个实验把一个原本跑在 Managed Agents 上的财务对账 agent无缝迁移到自建的 K8s 集群只改了 3 行配置整个过程对前端应用零影响。第二是可观测性前置。因为所有流量都必须经过 harness所以它天然就是埋点的最佳位置。Anthropic 在 harness 层内置了毫秒级的耗时统计、错误分类network_timeout, tool_error, model_rejection、甚至模型拒绝理由如reason: output_too_long。这些数据不是事后从日志里扒拉出来的而是 harness 在每次调用完成的瞬间就已结构化地写入 event log。对比我们之前用自研 harness 的方案需要在每个工具调用前后手动加start_time time.time()和log_duration(start_time)不仅容易遗漏而且无法捕获 harness 自身的调度延迟。Managed Agents 的 harness 把这个观测维度变成了基础设施的默认属性。2.3 Sandbox 是“一次性牛”不是“宠物服务器”“Sandboxed execution” 这个词听起来很酷但它的工程本质非常务实按需创建、用完即焚、资源隔离。Anthropic 的 sandbox 不是 Docker 容器而是一个更轻量的、基于 WebAssembly 的执行环境具体技术细节未公开但从启动速度 100ms 可推断。每个工具调用都会触发一个全新的 sandbox 实例启动加载指定的工具代码和依赖执行main(input)函数拿到字符串输出后立刻销毁整个环境。这种设计直接解决了三个生产环境里的老大难问题。首先是资源泄漏。传统方案里一个长期运行的 agent 进程如果某个工具调用打开了文件句柄或数据库连接却忘记关闭久而久之就会耗尽系统资源。而在 sandbox 模型下进程生命周期与单次调用严格绑定不存在“忘记关闭”的概念——环境一销毁所有资源自动归还。我们有个爬虫工具以前在 Node.js 进程里跑平均 3 天就会因内存泄漏 OOM迁移到 sandbox 后连续运行 42 天内存曲线平稳如直线。其次是安全隔离。sandbox 里看不到任何环境变量process.env是空的无法访问网络除非显式声明network: true文件系统是只读的除了/tmp。最关键的是凭证credentials根本不在 sandbox 里。Anthropic 的做法是在 sandbox 启动前由 harness 将凭证注入到一个临时的、只读的、内存映射的 secret file 中路径类似/run/secrets/jira_api_key然后在调用工具时通过--secret-file /run/secrets/jira_api_key参数传给工具进程。工具代码里只需open(/run/secrets/jira_api_key).read()而模型 prompt 里永远看不到这个路径更别说读取内容了。这比把密钥塞进os.environ安全一万倍——后者只要模型输出一句print(os.environ)密钥就裸奔了。最后是版本控制。每个 sandbox 的启动配置工具代码哈希、依赖清单、runtime 版本都作为元数据写入 event log。这意味着当你发现某次jira.create_issue调用返回了奇怪的错误你可以精确地找到那次调用对应的 sandbox 配置然后用完全相同的环境复现问题而不是在一堆模糊的“可能是昨天更新的依赖导致的”猜测中大海捞针。3. 实操落地从 YAML 定义到生产环境的完整闭环3.1 用 YAML 定义你的第一个 agent比写 prompt 还简单Managed Agents 的最大友好之处在于它把 agent 的“定义”和“执行”彻底分离。你不需要写一行 Python 代码来初始化 LLM、加载工具、设置 memory只需要一个 YAML 文件就能描述清楚整个 agent 的骨架。下面是一个真实的、用于自动化 GitHub Issue 分类的 agent 示例# github-classifier.yaml name: github-issue-classifier description: Automatically triage and label new GitHub issues based on content system_prompt: | You are a senior engineering manager at a fast-growing SaaS company. Your job is to read GitHub issues and assign them to the correct team and priority level. Use ONLY the provided tools. Do not make up information. tools: - name: get_issue_details description: Fetch full details of a GitHub issue by its number input_schema: type: object properties: issue_number: type: integer description: The GitHub issue number to fetch required: [issue_number] # Anthropic 托管的工具无需你实现 - name: label_issue description: Apply labels to a GitHub issue input_schema: type: object properties: issue_number: type: integer labels: type: array items: type: string required: [issue_number, labels] - name: assign_to_team description: Assign an issue to a specific engineering team input_schema: type: object properties: issue_number: type: integer team: type: string enum: [frontend, backend, infrastructure, security, product] required: [issue_number, team] guardrails: max_tool_calls_per_session: 10 max_session_duration_minutes: 30 allowed_domains: - api.github.com这个 YAML 文件里system_prompt是你的“大脑指令”tools是你的“手脚”guardrails是你的“安全带”。整个文件只有 42 行却定义了一个具备完整工作流的 agent。你甚至不需要知道get_issue_details这个工具背后是用 PyGithub 还是 requests 写的——Anthropic 已经为你托管好了。部署时只需一条命令claude managed-agents deploy --config github-classifier.yaml --name prod-github-triageAnthropic 会返回一个唯一的agent_id如agent_abc123之后所有调用都通过这个 ID 进行。整个过程从写 YAML 到获得可用 agent_id不超过 90 秒。对比我们之前用 LangChain FastAPI Docker 部署同类 agent需要写 300 行代码、配置 5 个环境变量、构建镜像、推送到 ECR、更新 ECS 服务整个 CI/CD 流水线跑完要 12 分钟。YAML 定义的简洁性不是为了偷懒而是为了把“定义 agent”这件事降低到产品经理也能参与的程度——他们可以直接修改system_prompt和guardrails而无需打扰工程师。3.2 Session 生命周期管理如何让 agent “活”过重启Managed Agents 的 session 持久化是它区别于所有竞品的核心。但“持久化”不等于“永生”。你需要理解它的生命周期规则才能用好。一个 session 的完整生命周期如下Creation创建: 通过POST /v1/sessions创建传入agent_id和初始user_message。此时 session 状态为active。Active活跃: session 会一直保持active直到满足以下任一条件max_session_duration_minutesYAML 中定义超时连续30 分钟无任何新消息包括用户输入和工具回调显式调用DELETE /v1/sessions/{session_id}max_tool_calls_per_session被耗尽。Paused暂停: 当 session 因超时或空闲而结束但尚未被 GC垃圾回收它会进入paused状态保留所有 event log持续7 天。GC回收:paused状态满 7 天后session 及其所有 event log 将被永久删除。这个设计意味着你不能把 session 当作一个长期在线的“机器人”。它更像是一个“工作流实例”。例如一个销售线索跟进 agent它的 session 生命周期应该是一次完整的跟进周期从收到新线索邮件到创建 CRM 记录到发送首次触达邮件到等待客户回复再到根据回复更新 CRM 状态。整个流程走完session 就完成了使命可以被回收。如果客户几天后又回复了那就应该创建一个新的 session并把之前的 event log 作为上下文通过initial_context字段注入进去。我们有个实际案例一个电商退货处理 agent最初设计为一个 session 处理一个订单的全部退货流程申请→审核→物流→退款。但后来发现用户经常在“审核”环节卡住需要人工介入等几天后才回来。如果 session 在审核后就超时关闭那么人工审核的结果就无法被 agent 感知。我们的解决方案是在 agent 调用完audit_return_request工具后主动调用pause_sessionAPI将 session 置为paused。当人工审核完成CRM 系统通过 webhook 通知我们的后端后端再调用resume_sessionAPI并传入审核结果作为新消息。这样agent 就能从暂停点继续执行整个流程对用户来说是无缝的。这个技巧是我们在上线后第三周才摸索出来的官方文档里根本没提但它却是让 agent 真正“可用”的关键。3.3 生产环境集成如何与你的现有系统握手把 Managed Agents 接入生产环境核心在于解决两个问题身份认证和事件驱动。Anthropic 不提供 OAuth 或 SAML它用的是最朴实的 API Key JWT 方案。首先你需要在 Anthropic 控制台为你的应用创建一个 Service Account获取一对client_id和client_secret。然后每次调用 API 前用这对凭据向 Anthropic 的 auth endpoint 申请一个短期 JWT有效期 1 小时# Python 示例获取 JWT Token import requests import jwt import time def get_anthropic_jwt(client_id, client_secret): payload { iss: client_id, sub: client_id, aud: https://api.anthropic.com, exp: int(time.time()) 3600, # 1 hour iat: int(time.time()) } token jwt.encode(payload, client_secret, algorithmHS256) return token # 使用 JWT 调用 API headers { Authorization: fBearer {get_anthropic_jwt(cli_abc, sec_xyz)}, Content-Type: application/json } response requests.post( https://api.anthropic.com/v1/sessions, json{agent_id: agent_123, user_message: Hello}, headersheaders )其次事件驱动是让 agent “活”起来的灵魂。Managed Agents 本身不推送事件它是一个纯 RESTful 服务。你需要自己实现一个“事件循环”。我们的标准模式是前端触发用户在 Web 应用点击“提交工单”前端调用你的后端 API。后端创建 session后端调用 Anthropic/v1/sessions创建 session拿到session_id。后端轮询后端启动一个后台任务每隔 500ms 调用/v1/sessions/{session_id}/status检查status字段。当status变为completed或failed轮询停止。后端处理结果根据status和final_output决定是向用户展示结果还是调用下一个系统如发送 Slack 通知、更新数据库。这个模式看似“笨拙”但它给了你绝对的控制权。你可以轻松地在轮询过程中插入自己的业务逻辑比如如果status是requires_human_input这是 guardrail 触发的自定义状态后端可以自动创建一个 Jira ticket指派给人工审核员如果final_output包含一个payment_url后端可以立即调用 Stripe API 锁定这笔支付。这种“orchestration in your code, execution in their infra”的混合架构才是生产环境最稳健的选择。4. 竞争格局与避坑指南为什么说 runtime 层正在“归零”4.1 Hyperscaler 的降维打击免费就是最锋利的刀Anthropic 的 Managed Agents 发布稿里通篇没提 AWS、Google、Microsoft。但这恰恰是最值得警惕的信号。因为就在它发布前五个月AWS Bedrock AgentCore 已经进入 GA正式可用阶段。而它的定价策略堪称“核威慑”AgentCore 本身不收费。你使用它来运行 Claude、Llama、Cohere 等任何 Bedrock 支持的模型runtime 层是零成本的。你只为模型调用的 tokens 付费Claude Sonnet $0.003/千 input tokens以及你使用的工具所消耗的云资源付费如 Lambda 调用次数、RDS 查询费用。更狠的是AWS 直接把 AgentCore SDK 打包进了 AWS SDK for Python (Boto3)。这意味着一个熟悉 AWS 的工程师写 5 行代码就能启动一个 agentfrom boto3 import client bedrock_agent client(bedrock-agent-runtime) response bedrock_agent.invoke_agent( agentIdabc123, agentAliasIdlatest, sessionIdsess-456, inputTextWhat is the status of order ORD-7890? )这已经不是“功能对标”了这是把 runtime 层直接变成了云平台的“空气”。你买 AWS 的 EC2、S3、RDSAgentCore 就是随附的“操作系统内核”你不会单独为 Linux 内核付钱。同样你为 Bedrock 的 tokens 付费AgentCore 就是那个让你能用上 tokens 的“驱动程序”。在这种模式下Anthropic 的 $0.08/小时 session fee就像在卖 Windows 95 的安装盘——技术上可行但商业上注定被边缘化。我们做过一个成本测算。一个中等规模的客服 agent日均处理 5000 个会话平均 session 时长 4.2 分钟。使用 Anthropic Managed Agents仅 runtime 费用就是5000 * (4.2/60) * 0.08 ≈ $28/天一年约 $10,220。而用 AWS AgentCoreruntime 成本为 $0只多花了约 $1200 的 tokens 和工具调用费。差价近 10 倍。这笔钱足够你雇一个全职工程师来优化 prompt 和工具把效果提升 30%。这就是 hyperscaler 的力量它不跟你比技术它用“免费”把你逼到只能比拼上层价值的绝境。4.2 开源势力的闪电战Daytona 和 Kubernetes SIG 的“平替”崛起如果说 hyperscaler 是“阳谋”那开源社区就是“奇袭”。2025 年初一个叫 Daytona 的项目从 DevOps 领域悄然转身杀入 AI agent infra 赛道。它没有宏伟的愿景只有一个极客式的承诺“Sub-90ms sandbox spin-up”。三个月后它真的做到了。我们用 Daytona 的开源版搭建了一个测试环境启动一个 Python sandbox 的 P95 时间是 87ms比 Anthropic 官方公布的 102ms 还快。更关键的是Daytona 的 sandbox 是纯开源的你可以把它部署在自己的裸金属服务器上0 成本。紧随其后的是 Kubernetes SIG。2025 年底Kubernetes 官方宣布成立sig-agent并发布了k8s-agent-sandbox项目。它的设计理念极其激进把每一个 agent 的每一次工具调用都当作一个 Kubernetes Pod 来调度。这意味着你可以用kubectl get pods -l agentgithub-classifier查看所有正在运行的 agent 工作负载用kubectl logs pod-xyz查看某次调用的完整 stdout/stderr用kubectl top pods实时监控 CPU/Memory 消耗。它把 agent infra 彻底纳入了现代云原生的运维体系。对于已经在用 K8s 的公司这几乎是零学习成本的迁移。这两股力量合起来构成了对 Managed Agents 的“双面夹击”。Hyperscaler 提供“免费但绑定”的云服务开源项目提供“自由但需自运维”的本地方案。而 Anthropic 的 Managed Agents恰好卡在中间——它既不够免费hyperscaler也不够自由开源。它的存在价值只剩下一点为那些极度厌恶运维、又极度信任 Anthropic 品牌、且预算充足的早期 adopter提供一个“最小可行产品”MVP的快速验证通道。一旦验证成功这些客户的第一反应几乎必然是“我们能不能把它迁到自己的 AWS 账户里跑”——而这正是 Anthropic 最不想看到却又无力阻止的结局。4.3 我们踩过的坑那些文档里永远不会写的“血泪教训”在把 Managed Agents 从 PoC 推向生产环境的三个月里我们踩了至少七个大坑。其中三个是连 Anthropic 的 Support 团队都承认“确实是个问题但短期内不会修复”的。坑一Tool Call 的“幽灵失败”现象某个工具调用比如send_email在 event log 里显示status: success但收件人根本没收到邮件。排查发现工具代码里有一个try...except块把 SMTP 连接超时错误给吞掉了只返回了一个空字符串。而 Managed Agents 的 harness只检查进程退出码exit code不检查 stdout 内容。只要进程正常退出exit code 0它就认为调用成功。解决方案我们被迫在所有工具代码的顶层加入一个强制的assert result ! 并在except块里抛出一个明确的RuntimeError(SMTP failed: timeout)。Harness 会捕获这个异常并在 event log 里标记为tool_error。这个 workaround 让我们多写了 200 行防御性代码但换来的是 100% 可靠的失败感知。坑二Session ID 的“雪崩式泄露”现象我们的前端应用为了给用户提供“继续对话”按钮会把session_id存在浏览器 localStorage 里。结果一个用户在多个标签页打开同一个页面每个标签页都用自己的session_id调用/v1/sessions/{id}/messages。由于 Managed Agents 的 session 是全局共享的所有标签页的请求都打到了同一个 session 上导致 agent 的上下文混乱输出完全不可预测。解决方案我们彻底放弃了在前端存储session_id。改为每次用户点击“继续对话”前端都向后端发起一个新请求后端检查用户最近一次有效的 session通过数据库关联如果 session 仍在active状态则返回其session_id如果已paused则调用resume_session并返回新 ID如果已过期则创建全新 session。这个方案增加了后端一次数据库查询但换来了绝对的会话隔离。坑三Guardrail 的“时间陷阱”现象YAML 里设置了max_session_duration_minutes: 30但一个 session 在第 28 分钟时调用了一个耗时 5 分钟的工具比如一个复杂的数据库查询。这个 session 并没有在第 30 分钟被强制终止而是让它跑完了 5 分钟最终在第 33 分钟才结束。这导致我们预估的资源消耗严重失真。解决方案我们意识到max_session_duration_minutes只限制“session 的生命周期”不约束“单次工具调用的耗时”。因此我们必须在每个工具代码内部自行实现超时控制如 Python 的signal.alarm()或asyncio.wait_for()。这是一个痛苦的重构但它是保证 SLA 的唯一办法。5. 价值迁移当 runtime 归零钱流向哪里5.1 Trace Store谁掌握了“行为日志”谁就拥有了 agent 世界的“区块链”当 runtime 层变得像水电一样廉价整个 AI 工程的价值重心必然向上游——也就是 agent 的“行为数据”——迁移。Managed Agents 产生的 event log不是一堆待丢弃的日志而是一个结构化的、高保真的、带有因果链的“数字行为档案”。谁能把这个档案变成可查询、可分析、可审计的“系统记录”谁就拿到了新时代的入场券。目前这个领域有三股势力在角力Braintrust走的是“专用 OLAP 数据库”路线。它用 Rust 编写了一个名为 Brainstore 的数据库专为event_type,session_id,causality_id,tool_name,duration_ms这些字段做了极致优化。它的强项是亚秒级的复杂聚合查询比如“过去 7 天所有jira.create_issue调用中duration_ms 5000且error IS NOT NULL的按user_id分组列出 top 5 的错误原因”。这种深度分析能力是通用数据库如 PostgreSQL难以企及的。但代价是它是一个封闭的、需要单独部署和运维的系统。Arize走的是“开源先行”路线。它把核心的 tracing 能力Phoenix以 Apache 2.0 协议开源任何人都可以免费下载、部署、修改。它的目标是成为事实上的“trace 格式标准”。一旦 Phoenix 的 JSONL schema包含event_id,session_id,span_id,parent_id,attributes被广泛采用那么 Arize 的商业版提供告警、仪表盘、Root Cause Analysis就成了顺理成章的升级选项。这是一种典型的“先占领心智再收割市场”的策略。LangSmith走的是“生态绑定”路线。它深度集成在 LangChain 生态里任何用了 LangChain 的项目只要加一行langsmith_client Client()所有 LLM 调用、tool call、chain execution 就自动上报。它的优势是“零配置”劣势是“强耦合”。如果你不用 LangChainLangSmith 就对你毫无意义。这三者的竞争本质上不是技术优劣之争而是数据主权之争。一个企业是否愿意把自己的 agent 行为日志交给一个第三方数据库Braintrust、一个第三方开源协议Arize、还是一个特定框架LangSmith答案将决定未来五年谁能在 AI Observability 这个新赛道上建立起真正的护城河。对我们而言选择 Arize 的 Phoenix是因为它的开源协议给了我们最大的灵活性我们可以把 Managed Agents 的 event log用一个简单的jq脚本转换成 Phoenix 格式然后导入自己的私有 Arize 实例。这样我们既享受了开源的自由又规避了厂商锁定的风险。5.2 Governance Policy当 agent 能写代码合规就是生死线2024 年OWASP 发布了《Agentic Top 10》把 “Unsafe Tool Use”不安全的工具调用列为第一大风险。这不再是理论警告。2025 年一家欧洲银行的信贷审批 agent因为 prompt 被精心构造的恶意输入诱导调用了curl -X POST https://internal-api.bank.com/transfer -d {amount: 1000000}试图向攻击者账户转账。幸亏银行的 API 网关有严格的 IP 白名单和金额校验才没酿成大祸。但这个事件让全球的 CISO 们都坐不住了。于是“Policy as Code” 成为了新刚需。AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls就是一个典型代表。它允许你用 YAML 定义这样的策略# policy.yaml policies: - name: no-external-funds-transfer description: Block any tool call that attempts to transfer funds externally condition: | event.tool_name http_post and transfer in event.input.url and bank.com not in event.input.url action: deny这个策略会在 harness 调用工具前对event进行实时评估。如果匹配直接拒绝调用连 sandbox 都不会启动。这种在基础设施层就嵌入的、可编程的、可审计的安全控制是任何上层应用代码都无法比拟的。它把安全左移Shift Left做到了极致。目前这个领域还没有真正的“ incumbent”主导者。AWS、Google、Microsoft 都在推自己的 policy framework但它们互不兼容。这就给了初创公司机会。我们正在评估一家叫 “PolicyFlow” 的公司它的产品可以统一管理来自 AWS、GCP、Azure 的 policy 定义并提供一个跨云的、可视化的策略编排界面。它的核心价值不是技术有多炫而是它能帮你回答 CEO 最关心的那个问题“我们的 AI agent到底被允许做什么不被允许做什么谁批准的证据在哪”——这个问题的答案就是未来 AI 治理的基石。5.3 Vertical Marketplaces当 agent 能看病、能炒股、能审合同垂直场景就是印钞机Salesforce 的 Agentforce ARR 达到 8 亿美元这个数字背后是一个清晰的信号企业愿意为“能解决具体业务问题”的 agent 付费而不是为“能跑 agent 的 runtime”付费。Agentforce 的成功不在于它有多快的 sandbox而在于它把 agent 做成了一个“垂直 SaaS”销售开发 agent能自动从 LinkedIn 抓取线索、生成个性化邮件、追踪打开率、预约会议客服 agent能接入 Zendesk自动分类工单、调用知识库、生成回复草稿、甚至发起视频通话。这个模式正在被迅速复制。在金融领域virattt/ai-hedge-fund这个开源项目已经能完成从新闻舆情抓取、财报数据解析、到生成交易信号的全流程。在网络安全领域vxcontrol/pentagi可以自动执行渗透测试的 Recon、Scanning、Exploitation 阶段并生成符合 ISO 27001 标准的报告。这些不是玩具它们是真实世界里正在创造价值的生产力工具。资本已经闻风而动。2026 年第一季度专注于 AI 垂直 agent 的初创公司平均融资额比去年同期增长了 220%。投资人的逻辑很简单runtime
