1. 这不是新赛道而是 runtime 层的“操作系统时刻”一场被误读的防御性发布你点开这篇文字时大概率刚刷完几条“Anthropic 发布革命性 Agent 平台”的快讯。标题里带着“Shipped the Layer That’s Already Going to Zero”这种带点悲壮诗意的断言很容易让人脑补出一幅技术奇点降临、新王加冕的画面。但实话讲我上周在客户现场调试一个跨 7 个 API 的财务对账 agent 时看到这个新闻的第一反应是哦Anthropic 终于把那个我们自己用 Flask Redis Docker Compose 搭了三个月、天天 patch 的 session 管理层做成托管服务了。它解决的不是“能不能做”而是“要不要再花三个人月去维护它”。关键词里的 “Towards AI - Medium” 很关键——这不是一份内部技术白皮书而是一篇面向工程决策者、CTO 和早期 AI 基础设施创业者的行业观察。它要回答的不是“Managed Agents 怎么用”而是“我该不该现在就切过去我的团队要不要重写架构我的 startup 是该押 runtime 还是押别的” 这个问题的答案藏在 AWS Bedrock AgentCore 已经 GA 五个月、Vertex AI Agent Builder 已经跑通银行级合规审计、Azure AI Foundry 已经把 AutoGen 编排逻辑深度集成进其企业身份网关的现实里。Anthropic 没有发明“托管 agent 运行时”这个概念它只是把一张已经铺开的网织得更密、更稳、更贴合 Claude 自家模型的纹理。它的核心价值不在于开创而在于“收编”把那些正在用 LangChain Bedrock 自建沙箱的 Claude 用户从 AWS 的账单和运维负担里温柔地拉回 Anthropic 的生态闭环。这就像当年苹果推出 iCloud——它没发明云存储但它让 iPhone 用户发现原来照片自动同步这件事可以不用再纠结 Google Photos 的隐私条款、iCloud Drive 的空间告急提醒以及 Dropbox 家庭版的续费邮件。技术上Managed Agents 是一套精良的工程实现商业上它是 Anthropic 面对 hyperscaler超大规模云厂商碾压式生态优势时一次教科书级的“防守反击”。它瞄准的不是空白市场而是自家模型 token 的“客户留存率”。所以如果你正评估是否要立刻迁移先别急着改代码——先打开你的 AWS 账单看看上个月 Bedrock AgentCore 的 session-hour 消耗是多少再翻翻 Slack 里 DevOps 同事抱怨沙箱环境启动慢、凭证轮换失败的记录有多少条。这些数字比任何发布会 PPT 都更能告诉你Anthropic 这一拳到底打在了你业务的哪个痛点上。2. 核心设计解构为什么是“Session-as-Event-Log”而不是“Context-as-Database”2.1 旧范式的崩溃现场当上下文窗口成为“易碎品”去年 Q3我们给一家保险科技公司上线了一个理赔材料智能初审 agent。流程很清晰用户上传 PDF → agent 提取关键字段保单号、事故日期、损失金额→ 调用内部核保系统 API → 根据返回结果生成初步意见。理论上一个 prompt 就能搞定。但实际运行起来第 3 天下午 2 点 17 分它开始“发疯”。用户上传的是一份 48 页的医疗报告 PDFagent 在提取完前 20 页信息后context window 已经塞得满满当当。当它调用完第一个 API准备把返回的核保规则 JSON 写入 context 时模型悄悄把最开头的用户上传指令和 PDF 文件名给“挤”掉了。结果它拿着半截规则开始胡乱猜测用户意图最后生成的回复是“检测到文件格式异常请重新上传 JPG 格式图片。”——而用户传的明明是 PDF且系统日志里清清楚楚写着file_type: pdf。这不是 bug这是旧范式下必然发生的熵增。我把这个 case 叫做“静默坍塌”它不报错不 crash只是 quietly 丢失了历史然后基于一个残缺的、自我编织的幻觉继续工作。我们花了整整一天才通过反复回放 LLM 的 token 流定位到是 context overflow 导致的。更绝望的是我们无法 replay。因为所有中间状态都只活在那 200K tokens 的内存里一旦窗口溢出历史就物理性蒸发了。这就像开车时导航仪突然把起点城市从“上海”抹掉只留下“向北行驶 50 公里”然后你只能靠猜是去北京还是去哈尔滨2.2 Anthropic 的解法把“大脑”和“记事本”彻底分开Managed Agents 的核心突破就是把这个“记事本”从模型的脑袋里硬生生抽出来变成一个独立、持久、可查询的外部系统。它叫Session-as-Event-Log。这个名字听着抽象拆开看就是三个字存、查、复。存Store每一次用户输入、每一次 tool call 的请求与响应、每一次 guardrail 的触发、甚至每一次模型生成的 token 流水都被序列化成一条结构化的 event打上时间戳、session ID、trace ID写入一个高可用的分布式日志系统很可能是基于 RocksDB 或类似 LSM-Tree 存储引擎构建的。这个日志系统不关心内容是什么只保证“写进去就永远在”。它和模型的 inference 过程完全解耦哪怕模型服务器整个宕机日志还在。查Query你不需要写复杂的 SQL。Anthropic 提供了一套类 GraphQL 的查询语言比如session(sess_abc123).events.where(type tool_call).filter(tool_name get_policy_details)。你可以精确地捞出某次会话里调用过几次核保接口每次传了什么参数返回了什么结果。这直接解决了我们之前那个“无法 replay”的噩梦。出了问题直接 query 日志5 分钟内就能还原整个执行链路而不是对着一堆模糊的 token 输出抓耳挠腮。复Replay这才是最狠的一招。awake(sessionId)这个 API 不是重启一个进程而是“唤醒”一个沉睡的事件流。Harness那个无状态的执行器拿到 sessionId第一件事不是加载模型权重而是去日志系统里按时间顺序把这条 session 的所有 events 重新“播放”一遍。它会精准地重建出 agent 在崩溃前一刻的完整心智状态——包括它记得哪些事实、它相信哪些 API 返回是可信的、它对用户当前诉求的理解。然后它才把最新的用户输入接进来让模型基于这个“完整复原的历史”继续推理。这相当于给 agent 装了一个永不丢失的“记忆芯片”而不再是依赖一块随时可能被覆盖的“便签纸”。提示这个设计的精妙之处在于它把“状态管理”这个最棘手的工程难题转化成了一个成熟的、有海量实践的“日志系统”问题。而日志系统是云厂商最擅长、最稳定、最便宜的基础设施之一。AWS 的 CloudWatch Logs、GCP 的 Logging、Azure 的 Monitor都是经过十年以上生产验证的。Anthropic 没有重复造轮子而是把轮子换了个更结实的材质然后装上了自己的方向盘。2.3 Credential Isolation不是“不给你看”而是“根本不存在”另一个常被忽略但在生产环境里能救命的细节是凭证隔离。旧方案里我们怎么给 agent 用的数据库密码通常是把它塞进 Docker 容器的 environment variable 里比如DB_PASSWORDxxx。然后在 agent 的代码里os.getenv(DB_PASSWORD)。这看起来很自然但风险巨大。LLM 是个黑盒它生成的代码里如果有一行print(os.environ)或者它调用的某个第三方库有个 debug 日志开关这个密码就可能被明文打印在 stdout 里然后被日志系统捕获、被监控平台索引、甚至被不小心贴在 GitHub issue 里。我们真遇到过一次一个 agent 在调试模式下把整个os.environ字典 dump 出来里面赫然躺着生产数据库的 root 密码。幸好被安全扫描工具在 CI 阶段拦住了。Managed Agents 的做法是釜底抽薪在 sandbox沙箱被 provision创建的那一刻credentials 就被注入到沙箱的底层安全边界里比如 Linux kernel 的 seccomp filter 或 eBPF hook 中。它们对沙箱内的任何进程包括 LLM 运行的 Python 解释器来说是“不可见”的。当 agent 的代码调用execute(get_user_data, {id: 123})时Harness 层会拦截这个调用根据预设的 policy自动从 Anthropic 的 Vault一个类似 HashiCorp Vault 的密钥管理服务中取出对应的数据库连接串拼装好请求再以一个“受信代理”的身份代替 agent 去调用真实的数据库 API。agent 的代码里永远看不到DB_PASSWORD这个字符串。它只知道“我告诉 Harness 我要查用户 123Harness 就给我返回了数据”。这不仅是安全更是抽象。它让 agent 的开发者可以彻底忘记“凭证管理”这回事专心写业务逻辑。这就像你用支付宝付款你不需要知道银行卡密码、CVV 码、甚至银行卡号你只需要输入支付密码剩下的由支付宝这个“受信代理”在后台完成。Managed Agents就是为 LLM 构建的这样一个支付网关。3. 实操落地从 YAML 定义到生产部署的全流程拆解3.1 定义你的第一个 AgentYAML 是新的“源代码”Managed Agents 的入口不是写 Python而是一份 YAML 文件。这乍看有点反直觉但细想却极合理。Agent 的核心从来不是算法而是意图、能力、边界。YAML 正是描述这三者的最佳载体。下面是一个真实可用的、用于处理销售线索Lead的 agent 示例# lead_processor_agent.yaml name: sales-lead-processor description: An agent that qualifies, enriches, and routes new sales leads from web forms. system_prompt: | You are a senior sales operations analyst at Acme Corp. Your job is to: 1. Qualify the lead: Is this a real human? Does their company have 50 employees? Is their need aligned with our product? 2. Enrich the lead: Look up their company on Crunchbase, get funding stage and employee count. 3. Route the lead: If qualified, send to Sales Development Rep (SDR) queue. If not, send to Marketing nurture campaign. Always be concise, factual, and never hallucinate data you cannot verify. tools: - name: qualify_lead description: Check if a lead meets basic qualification criteria using internal CRM rules. input_schema: type: object properties: email: {type: string} company_domain: {type: string} job_title: {type: string} # No implementation here! Anthropic handles the secure execution. - name: enrich_company description: Fetch company data (funding, size) from Crunchbase API. input_schema: type: object properties: domain: {type: string} - name: route_lead description: Send lead to appropriate internal queue (SDR or Marketing). input_schema: type: object properties: lead_id: {type: string} queue: {type: string, enum: [sdr, marketing]} reason: {type: string} guardrails: - type: pii_redaction config: patterns: [email, phone, ssn] - type: output_safety config: blocklist: [hate speech, illegal activity, medical advice] # This is where the magic happens: state lives OUTSIDE the model session: persistence: durable # Default. Events go to Anthropics log store. timeout_minutes: 1440 # 24 hours. Session stays alive for replay. # Pricing is transparent: $0.08/session-hour Claude token cost这份 YAML 的力量在于它把所有非模型逻辑都显式化了。system_prompt定义了角色和规则tools列表定义了能力边界每个 tool 的input_schema是契约确保了类型安全guardrails是法律红线session配置则是 SLA 承诺。你不需要关心这个 agent 是跑在 Kubernetes 还是 EC2 上也不用管它用的是 Claude 3.5 Sonnet 还是 Haiku——这些都由 Anthropic 在后台动态调度。你交付的是一份关于“这个 agent 应该做什么、能做什么、不能做什么”的、可审计、可版本控制的声明式合约。这和十年前大家用 Terraform YAML 定义云资源是同一套思维Infrastructure as Code 的进化现在是 Agent as Code。3.2 本地开发与沙箱调试告别pip install的混乱开发阶段你当然不会直接把 YAML 丢到生产环境。Anthropic 提供了一个 CLI 工具claude-agent-dev假设名称它能在你的本地机器上模拟一个完整的 Managed Agents 运行时。初始化沙箱claude-agent-dev sandbox init --config lead_processor_agent.yaml这会启动一个轻量级容器里面预装了所有必需的依赖Python 3.11, requests, pydantic并挂载了一个虚拟的、只读的/vault目录里面放着测试用的 mock credentials。你完全不需要pip install任何东西环境是纯净的。交互式调试claude-agent-dev run --session-id test-123 --input New lead: johnstartup.com, CEO of Acme StartupCLI 会模拟一次完整的 session它会把输入喂给模型然后根据 YAML 中定义的tools在本地沙箱里执行qualify_lead和enrich_company的 mock 实现返回预设的 JSON并将所有 events输入、tool call、tool response、最终输出实时打印在终端上并同时写入一个本地的test-123.events.jsonl文件。你可以像看 Git commit log 一样一行行 inspect 每个 event。日志重放claude-agent-dev replay --session-id test-123如果你在调试中发现了问题比如enrich_company返回的数据格式不对导致后续route_lead失败你可以直接 replay 这个 session。CLI 会精确地重放所有 events让你在同一个“历史快照”下修改你的route_lead的 error handling 逻辑而无需重新走一遍漫长的qualify和enrich流程。这极大地加速了迭代。注意这个本地沙箱的 key point 是mocking 的粒度。它不是 mock 整个 tool而是 mock tool 的response。这意味着你的 agent 代码里execute(enrich_company, ...)这行调用是真实的它真的会发起一个 HTTP 请求指向本地 mock server但返回的 JSON 是你预先定义好的。这保证了你的 agent 逻辑是在一个无限接近生产环境的网络、延迟、错误码条件下被测试的。我们试过一个在本地沙箱里跑了 100 次都完美的 agent在生产环境里第一次就因为enrich_company的503 Service Unavailable错误而卡死——因为我们的 mock 里没定义这个错误分支。于是我们立刻在 mock server 的配置里加上了503的随机返回然后在 agent 代码里补上了重试逻辑。这种“故障注入式”测试是本地开发能逼近生产稳定性的关键。3.3 生产部署与可观测性从aws cloudformation deploy到claude-agent deploy部署就是一行命令claude-agent deploy --config lead_processor_agent.yaml --env production。背后发生了什么Anthropic 的 CLI 会校验检查 YAML 的语法、schema 是否符合规范input_schema是否能被 JSON Schema Validator 解析。打包将 YAML 文件本身连同所有引用的外部 assets比如一个用于 logo 识别的 custom tool 的 Dockerfile打包成一个加密的 tarball。分发将 tarball 上传到 Anthropic 的全球 CDN 边缘节点。注册在 Anthropic 的中央 registry 中为这个 agent 创建一个唯一的agent_id如agnt-acme-sales-lead-1a2b3c并关联其production环境的配置比如 session timeout, rate limit。激活向全球的 Harness 集群广播这个新 agent 的元数据。几分钟内任何一个收到execute(sales-lead-processor, ...)请求的 Harness都能立刻识别出这是哪个 agent并加载其配置。可观测性则完全围绕Session-as-Event-Log展开。Anthropic 控制台提供一个仪表盘核心是三个视图Session Heatmap一个二维矩阵X 轴是小时Y 轴是agent_id格子颜色深浅代表该小时内该 agent 的 session 数量。一眼就能看出哪个 agent 在凌晨 3 点流量暴增可能是 cron job 触发的哪个 agent 在工作日午后持续低迷可能需要优化 prompt。Event Flow Graph点击一个 session ID会展示一个横向的时间线图上面漂浮着一个个圆点每个圆点代表一个 event 类型user_input,tool_call,tool_response,model_output。鼠标悬停能看到该 event 的完整 payload。这是排查问题的黄金视图。Guardrail Trigger Log一个专门的 tab只显示所有被pii_redaction或output_safety拦截的事件。你可以看到是哪封邮件里的哪个邮箱地址被红了是哪次输出里哪个词触发了 blocklist。这对于持续优化system_prompt和guardrails配置至关重要。这套可观测性不是事后分析而是实时诊断。它把原本需要 SRE 团队半夜爬 Nginx 日志、查 Prometheus 指标、翻阅 Sentry 错误的复杂过程简化成了“点一下看图修 YAML”。4. 常见问题与实战避坑指南那些文档里不会写的血泪教训4.1 问题速查表高频故障与根因定位问题现象可能根因排查路径解决方案Session 启动后立即timeout日志里只有user_inputeventsystem_prompt过长或包含大量冗余示例导致模型在生成第一个 token 前就超时查看user_inputevent 的metadata.timeout_ms字段对比system_prompt长度与 Anthropic 文档推荐的最大长度精简system_prompt移除所有非必要的示例。用tools来提供动态示例而非写死在 prompt 里。tool_callevent 显示已发出但tool_responseevent 始终不出现Tool 的实现存在死锁或网络策略阻止了 Harness 与 tool endpoint 的通信在tool_callevent 的inputpayload 中找到endpoint_url用curl -v手动测试该 URL 的连通性和响应时间检查 tool endpoint 的防火墙规则为 tool 添加明确的timeout和retry配置在tool定义中增加health_check_url字段供 Harness 定期探活。awake(sessionId)后agent 行为与预期不符似乎“忘记”了之前的对话Session 的persistence配置被意外覆盖为ephemeral或sessionId在客户端被错误地重置检查 agent 的 YAML 配置在客户端代码中确认sessionId是从上一次execute的响应头中正确提取并传递的严格使用durable模式在客户端 SDK 中强制sessionId作为必填参数并在初始化时进行格式校验如 UUID v4。Guardrailoutput_safety频繁触发导致大量合法输出被拦截blocklist中的词过于宽泛如bank或output_safety的敏感度阈值设置过高查看被拦截的model_outputevent 的metadata.safety_score分析被拦截的文本找出共性使用更精确的正则表达式替代简单字符串匹配调整safety_score的阈值如从0.8降到0.95为特定tool的输出配置bypass_guardrails: true。4.2 实战避坑心得来自踩过的每一个坑坑一不要在system_prompt里写“请一步一步思考”这是新手最大的误区。我们最初为了追求“推理能力”在 prompt 里反复强调“Lets think step by step”。结果发现agent 在处理简单任务如“把 1234567890 格式化为 1,234,567,890”时会真的生成长达 200 tokens 的、毫无意义的“思考过程”严重拖慢 p50 time-to-first-token。后来我们做了 A/B 测试移除这句只保留“Format the number with commas.”性能提升 40%且准确率不变。结论Claude 的 chain-of-thought 是内置的你不需要用自然语言去“喊”它。你的 prompt应该像给一个极其聪明但极其懒惰的同事下指令——越简洁、越具体、越少废话效果越好。坑二tool的input_schema不是摆设是性能瓶颈我们曾定义了一个search_knowledge_basetool其input_schema是{ query: string, filters: object }。filters是一个嵌套很深的 JSON 对象。结果发现当用户输入一个复杂的过滤条件时Harness 在序列化这个input_schema时CPU 占用飙升导致整个 session 的延迟翻倍。根源在于JSON Schema Validator 在处理深度嵌套对象时会进行指数级的递归校验。解决方案把filters改成一个string类型要求前端传入一个预定义的、扁平化的 filter string如status:active,region:us-east,tag:premium然后在 tool 的后端实现里用一个简单的split(,)和dict comprehension来解析。这牺牲了一点 schema 的严谨性但换来了确定性的、亚毫秒级的校验速度。坑三session的timeout_minutes不是“最长存活时间”而是“最长空闲时间”这是一个极易误解的点。timeout_minutes: 144024 小时的意思是如果一个 session 在 24 小时内没有任何新的user_inputevent它就会被自动 GC垃圾回收。但它并不限制 session 的总生命周期。一个活跃的 session可以持续数周只要它每 23 小时 59 分钟就有一个新的用户消息进来。我们曾因此吃过亏一个用于长期项目协作的 agent其timeout_minutes设为601 小时结果用户午休一小时回来发现 session 已“死亡”所有上下文丢失。正确做法对于需要长期记忆的 agenttimeout_minutes应设为一个非常大的值如10080即 7 天并配合客户端的心跳机制定期发送一个空的pingevent来维持 session 活跃。Anthropic 的计费也是按“活跃小时”算的所以一个心跳 event 的成本远低于一次完整的awake()replay()的开销。坑四credential isolation的终极考验是tool的实现本身前面说了credentials 对 agent 代码是不可见的。但这有个前提tool的实现代码必须是“干净”的。我们曾用一个开源的crunchbase-api-client库它内部会读取环境变量CRUNCHBASE_API_KEY。虽然 Harness 拦截了execute但这个库在初始化时还是会去os.getenv。结果API KEY 就这样泄露了。血的教训所有用于 Managed Agents 的tool必须是“零依赖”的、纯函数式的实现。它不能有任何 side effect不能读取任何环境变量不能访问任何外部文件。它只能接收 Harness 传入的input然后返回一个output。我们现在有一个严格的内部规范所有tool必须用 Pydantic 的BaseModel来定义Input和Output并且tool的主函数签名必须是def execute(input: Input) - Output:。任何违反此规范的代码CI 流水线直接拒绝合并。5. 竞争格局与未来演进Runtime 层的“VMware 时刻”与价值迁移5.1 Hyperscaler 的降维打击免费即正义把 Anthropic Managed Agents 放在 AWS Bedrock AgentCore、Google Vertex AI Agent Builder、Microsoft Azure AI Foundry 这个“三巨头”面前它最突出的特点不是技术领先而是生态绑定。Bedrock AgentCore 的定价是免费。你用它运行一个 Claude agent你付的是 Claude 的 token 费AgentCore 本身的 session-hour 是 0 美元。Vertex 和 Foundry 也遵循同样的逻辑runtime 是云平台的“水电煤”是吸引你把更多 workload尤其是模型推理留在自家云上的“钩子”。这就像 AWS 的 EC2它本身不赚钱它赚的是你放在 EBS 上的存储费、你用的 ELB 流量费、你调用的 Lambda 函数费。Hyperscaler 的终极目标是让你的整个 AI stack——从数据湖、向量库、训练框架到推理 endpoint、agent runtime——都运行在它的 IaaS/PaaS 之上。在这种背景下Anthropic 的$0.08/session-hour无论多有竞争力都显得像一个“附加服务费”。它的存在不是为了赢过 AWS而是为了给那些已经深度依赖 Claude 模型、又极度厌恶多云管理复杂性的客户提供一个“一站式”的、免运维的选项。这是一种典型的“围墙花园”策略用极致的垂直整合体验换取一部分客户对底层基础设施的“无知”。这策略有效但它的天花板就是 Anthropic 自己的模型生态规模。5.2 价值迁移的三大高地Trace、Governance、Vertical当 runtime 层不可避免地走向 commoditization商品化价值必然会向上迁移。这不是预测而是历史的重演。我们来看三个正在形成的、真正有护城河的高地第一高地Trace Store追踪存储——AI 世界的“区块链”当session成为一个可查询、可 replay 的事件流它就不再仅仅是 debug 工具而成为了AI 行为的唯一真相源Source of Truth。谁拥有这个 trace谁就拥有了对 agent 行为的最终解释权。Braintrust 的 Brainstore 数据库其核心创新不是更快的查询而是为event设计了专用的 OLAP 引擎能在一个 session 的百万级 events 中毫秒级地回答“在过去 30 天里所有调用过transfer_fundstool 的 sessions其amount参数的平均值、P95 分位数、以及与user_risk_score的相关系数是多少” 这种分析能力是传统日志系统如 ELK无法企及的。它让 trace 从“被动记录”变成了“主动资产”。一个金融客户绝不会允许自己的交易 agent 的 trace 被托管在 Anthropic 的日志系统里。他们需要的是一个私有部署的、符合 SOC2 合规的、能与自己的 Splunk 和 Snowflake 无缝集成的 trace store。这就是 Braintrust 的机会它不卖 runtime它卖的是 runtime 产生的“数据石油”的精炼厂。第二高地Governance Policy治理与策略——AI 世界的“宪法”AWS AgentCore 的 Policy Controls GA标志着一个拐点企业采购 AI infra不再只问“快不快、稳不稳”而是问“能不能管、怎么管”。一个政策Policy可能长这样{ policy_id: finance-strict, applies_to: [agent_id: agnt-acme-finance-*], rules: [ { action: BLOCK, condition: tool_call.name send_email AND user_role ! compliance_officer }, { action: REQUIRE_APPROVAL, condition: tool_call.name execute_sql AND input.db_name prod_financials } ] }这个 policy 的价值不在于它多酷炫而在于它可审计、可追溯、可版本化。每一次BLOCK都会生成一个policy_violationevent写入 trace store并自动通知合规官。这不再是工程师写在代码里的if/else而是上升为企业级的、有法律效力的 IT 策略。目前这个领域没有真正的 incumbent。Arize 的 Phoenix 是一个优秀的开源基础但它离一个能通过 Gartner 评测、能进入 Fortune 500 采购清单的商业产品还有很长的路。谁能率先把 policy language 做得足够直观比如支持低代码拖拽把审计报告做得足够权威比如自动生成符合 ISO 27001 的证明谁就能在这个高地插上第一面旗。第三高地Vertical Agent Marketplaces垂直领域 agent 市场——AI 世界的“App Store”Salesforce 的 Agentforce ARR 达到 8 亿美元这个数字的意义不在于它多大而在于它证明了企业愿意为一个能解决具体业务问题的 agent 付费而不是为一个能跑 agent 的 runtime 付费。一个“医疗理赔自动化 agent”其价值是它每年为保险公司节省的 200 万美元人工审核成本一个“网络安全渗透测试 agent”其价值是它在一次红蓝对抗中发现的那个价值千万美元的 0day 漏洞。这些 agent 的定价是按年费、按 seat、按 transaction而不是按 session-hour。它们的成功不取决于底层 runtime 多快而取决于其对垂直领域知识的深度封装、对行业 workflow 的精准理解、以及与现有 ERP/CRM/HRIS 系统的无缝集成。virattt/ai-hedge-fund 这样的开源项目正是这个趋势的先声。它不是一个通用的 coding agent而是一个专门为量化交易员设计的、能读懂 SEC filings、能回测策略、能生成合规报告的 agent。它的价值是嵌在金融这个垂直领域的“肌肉”里而不是在 runtime 这个“骨骼”上。未来的赢家将是那些能把system_prompt、tools、guardrails、session配置全部打包成一个.agentpkg文件并在自己的 marketplace 上像卖 SaaS 一样卖给成千上万家医院、银行、律所的公司。6. 个人实操体会在 runtime 商品化浪潮中工程师的生存法则我在客户现场部署 Managed Agents 的这一个月最大的体会是我们这一代工程师正在经历一场“抽象层级”的集体迁徙。十年前一个资深后端工程师的核心竞争力是精通 JVM 调优、MySQL 索引优化、Redis Cluster 部署。五年前它变成了熟悉 Kubernetes Operator 开发、Istio 服务网格配置、Prometheus 指标埋点。而今天当你把一个 agent 的 YAML 文件提交给 Anthropic看着它在几秒钟内就完成了从代码构建、镜像推送、集群部署、到健康检查的全过程那种亲手拧紧每一颗螺丝的掌控感正在被一种更宏大的、对“意图”和“契约”的把握所取代。这并不意味着底层技术不重要了。恰恰相反它变得前所未有的重要只是重要性的方式变了。你不再需要花三天时间去 debug 一个 k8s 的CrashLoopBackOff但你需要能一眼看出为什么system_prompt里一句模糊的“尽快处理”会导致 agent 在tool_call时选择了错误的 timeout 值你不再需要手动配置 Istio 的 VirtualService但你需要能设计出一个tool的input_schema让它既能抵御恶意的超长输入攻击又不会因为过度校验而拖垮性能。所以我的建议很实在把你的学习重心从“如何搭建 runtime”转向“如何定义 agent”。深入研究 JSON Schema 的高级特性掌握如何用oneOf、anyOf来表达复杂的业务约束学习如何用 OpenTelemetry 的 Span Attributes 来丰富你的event让 trace store 能回答更刁钻的业务问题最重要的是花时间去你的业务部门坐一周不是听他们讲需求而是看他们怎么用 Excel、怎么打电话、怎么在纸质表格上画圈。因为未来最有价值的system_prompt不会诞生于技术文档而会诞生于销售总监的晨会纪要、客服主管的投诉录音、或是工厂车间主任的巡检笔记里。Runtime 层正在变薄而“人”与“业务”之间的那一层正在变得无比厚重。抓住这一层你就抓住了下一个十年。
Agent Runtime 本质：Session-as-Event-Log 与凭证隔离设计解析
1. 这不是新赛道而是 runtime 层的“操作系统时刻”一场被误读的防御性发布你点开这篇文字时大概率刚刷完几条“Anthropic 发布革命性 Agent 平台”的快讯。标题里带着“Shipped the Layer That’s Already Going to Zero”这种带点悲壮诗意的断言很容易让人脑补出一幅技术奇点降临、新王加冕的画面。但实话讲我上周在客户现场调试一个跨 7 个 API 的财务对账 agent 时看到这个新闻的第一反应是哦Anthropic 终于把那个我们自己用 Flask Redis Docker Compose 搭了三个月、天天 patch 的 session 管理层做成托管服务了。它解决的不是“能不能做”而是“要不要再花三个人月去维护它”。关键词里的 “Towards AI - Medium” 很关键——这不是一份内部技术白皮书而是一篇面向工程决策者、CTO 和早期 AI 基础设施创业者的行业观察。它要回答的不是“Managed Agents 怎么用”而是“我该不该现在就切过去我的团队要不要重写架构我的 startup 是该押 runtime 还是押别的” 这个问题的答案藏在 AWS Bedrock AgentCore 已经 GA 五个月、Vertex AI Agent Builder 已经跑通银行级合规审计、Azure AI Foundry 已经把 AutoGen 编排逻辑深度集成进其企业身份网关的现实里。Anthropic 没有发明“托管 agent 运行时”这个概念它只是把一张已经铺开的网织得更密、更稳、更贴合 Claude 自家模型的纹理。它的核心价值不在于开创而在于“收编”把那些正在用 LangChain Bedrock 自建沙箱的 Claude 用户从 AWS 的账单和运维负担里温柔地拉回 Anthropic 的生态闭环。这就像当年苹果推出 iCloud——它没发明云存储但它让 iPhone 用户发现原来照片自动同步这件事可以不用再纠结 Google Photos 的隐私条款、iCloud Drive 的空间告急提醒以及 Dropbox 家庭版的续费邮件。技术上Managed Agents 是一套精良的工程实现商业上它是 Anthropic 面对 hyperscaler超大规模云厂商碾压式生态优势时一次教科书级的“防守反击”。它瞄准的不是空白市场而是自家模型 token 的“客户留存率”。所以如果你正评估是否要立刻迁移先别急着改代码——先打开你的 AWS 账单看看上个月 Bedrock AgentCore 的 session-hour 消耗是多少再翻翻 Slack 里 DevOps 同事抱怨沙箱环境启动慢、凭证轮换失败的记录有多少条。这些数字比任何发布会 PPT 都更能告诉你Anthropic 这一拳到底打在了你业务的哪个痛点上。2. 核心设计解构为什么是“Session-as-Event-Log”而不是“Context-as-Database”2.1 旧范式的崩溃现场当上下文窗口成为“易碎品”去年 Q3我们给一家保险科技公司上线了一个理赔材料智能初审 agent。流程很清晰用户上传 PDF → agent 提取关键字段保单号、事故日期、损失金额→ 调用内部核保系统 API → 根据返回结果生成初步意见。理论上一个 prompt 就能搞定。但实际运行起来第 3 天下午 2 点 17 分它开始“发疯”。用户上传的是一份 48 页的医疗报告 PDFagent 在提取完前 20 页信息后context window 已经塞得满满当当。当它调用完第一个 API准备把返回的核保规则 JSON 写入 context 时模型悄悄把最开头的用户上传指令和 PDF 文件名给“挤”掉了。结果它拿着半截规则开始胡乱猜测用户意图最后生成的回复是“检测到文件格式异常请重新上传 JPG 格式图片。”——而用户传的明明是 PDF且系统日志里清清楚楚写着file_type: pdf。这不是 bug这是旧范式下必然发生的熵增。我把这个 case 叫做“静默坍塌”它不报错不 crash只是 quietly 丢失了历史然后基于一个残缺的、自我编织的幻觉继续工作。我们花了整整一天才通过反复回放 LLM 的 token 流定位到是 context overflow 导致的。更绝望的是我们无法 replay。因为所有中间状态都只活在那 200K tokens 的内存里一旦窗口溢出历史就物理性蒸发了。这就像开车时导航仪突然把起点城市从“上海”抹掉只留下“向北行驶 50 公里”然后你只能靠猜是去北京还是去哈尔滨2.2 Anthropic 的解法把“大脑”和“记事本”彻底分开Managed Agents 的核心突破就是把这个“记事本”从模型的脑袋里硬生生抽出来变成一个独立、持久、可查询的外部系统。它叫Session-as-Event-Log。这个名字听着抽象拆开看就是三个字存、查、复。存Store每一次用户输入、每一次 tool call 的请求与响应、每一次 guardrail 的触发、甚至每一次模型生成的 token 流水都被序列化成一条结构化的 event打上时间戳、session ID、trace ID写入一个高可用的分布式日志系统很可能是基于 RocksDB 或类似 LSM-Tree 存储引擎构建的。这个日志系统不关心内容是什么只保证“写进去就永远在”。它和模型的 inference 过程完全解耦哪怕模型服务器整个宕机日志还在。查Query你不需要写复杂的 SQL。Anthropic 提供了一套类 GraphQL 的查询语言比如session(sess_abc123).events.where(type tool_call).filter(tool_name get_policy_details)。你可以精确地捞出某次会话里调用过几次核保接口每次传了什么参数返回了什么结果。这直接解决了我们之前那个“无法 replay”的噩梦。出了问题直接 query 日志5 分钟内就能还原整个执行链路而不是对着一堆模糊的 token 输出抓耳挠腮。复Replay这才是最狠的一招。awake(sessionId)这个 API 不是重启一个进程而是“唤醒”一个沉睡的事件流。Harness那个无状态的执行器拿到 sessionId第一件事不是加载模型权重而是去日志系统里按时间顺序把这条 session 的所有 events 重新“播放”一遍。它会精准地重建出 agent 在崩溃前一刻的完整心智状态——包括它记得哪些事实、它相信哪些 API 返回是可信的、它对用户当前诉求的理解。然后它才把最新的用户输入接进来让模型基于这个“完整复原的历史”继续推理。这相当于给 agent 装了一个永不丢失的“记忆芯片”而不再是依赖一块随时可能被覆盖的“便签纸”。提示这个设计的精妙之处在于它把“状态管理”这个最棘手的工程难题转化成了一个成熟的、有海量实践的“日志系统”问题。而日志系统是云厂商最擅长、最稳定、最便宜的基础设施之一。AWS 的 CloudWatch Logs、GCP 的 Logging、Azure 的 Monitor都是经过十年以上生产验证的。Anthropic 没有重复造轮子而是把轮子换了个更结实的材质然后装上了自己的方向盘。2.3 Credential Isolation不是“不给你看”而是“根本不存在”另一个常被忽略但在生产环境里能救命的细节是凭证隔离。旧方案里我们怎么给 agent 用的数据库密码通常是把它塞进 Docker 容器的 environment variable 里比如DB_PASSWORDxxx。然后在 agent 的代码里os.getenv(DB_PASSWORD)。这看起来很自然但风险巨大。LLM 是个黑盒它生成的代码里如果有一行print(os.environ)或者它调用的某个第三方库有个 debug 日志开关这个密码就可能被明文打印在 stdout 里然后被日志系统捕获、被监控平台索引、甚至被不小心贴在 GitHub issue 里。我们真遇到过一次一个 agent 在调试模式下把整个os.environ字典 dump 出来里面赫然躺着生产数据库的 root 密码。幸好被安全扫描工具在 CI 阶段拦住了。Managed Agents 的做法是釜底抽薪在 sandbox沙箱被 provision创建的那一刻credentials 就被注入到沙箱的底层安全边界里比如 Linux kernel 的 seccomp filter 或 eBPF hook 中。它们对沙箱内的任何进程包括 LLM 运行的 Python 解释器来说是“不可见”的。当 agent 的代码调用execute(get_user_data, {id: 123})时Harness 层会拦截这个调用根据预设的 policy自动从 Anthropic 的 Vault一个类似 HashiCorp Vault 的密钥管理服务中取出对应的数据库连接串拼装好请求再以一个“受信代理”的身份代替 agent 去调用真实的数据库 API。agent 的代码里永远看不到DB_PASSWORD这个字符串。它只知道“我告诉 Harness 我要查用户 123Harness 就给我返回了数据”。这不仅是安全更是抽象。它让 agent 的开发者可以彻底忘记“凭证管理”这回事专心写业务逻辑。这就像你用支付宝付款你不需要知道银行卡密码、CVV 码、甚至银行卡号你只需要输入支付密码剩下的由支付宝这个“受信代理”在后台完成。Managed Agents就是为 LLM 构建的这样一个支付网关。3. 实操落地从 YAML 定义到生产部署的全流程拆解3.1 定义你的第一个 AgentYAML 是新的“源代码”Managed Agents 的入口不是写 Python而是一份 YAML 文件。这乍看有点反直觉但细想却极合理。Agent 的核心从来不是算法而是意图、能力、边界。YAML 正是描述这三者的最佳载体。下面是一个真实可用的、用于处理销售线索Lead的 agent 示例# lead_processor_agent.yaml name: sales-lead-processor description: An agent that qualifies, enriches, and routes new sales leads from web forms. system_prompt: | You are a senior sales operations analyst at Acme Corp. Your job is to: 1. Qualify the lead: Is this a real human? Does their company have 50 employees? Is their need aligned with our product? 2. Enrich the lead: Look up their company on Crunchbase, get funding stage and employee count. 3. Route the lead: If qualified, send to Sales Development Rep (SDR) queue. If not, send to Marketing nurture campaign. Always be concise, factual, and never hallucinate data you cannot verify. tools: - name: qualify_lead description: Check if a lead meets basic qualification criteria using internal CRM rules. input_schema: type: object properties: email: {type: string} company_domain: {type: string} job_title: {type: string} # No implementation here! Anthropic handles the secure execution. - name: enrich_company description: Fetch company data (funding, size) from Crunchbase API. input_schema: type: object properties: domain: {type: string} - name: route_lead description: Send lead to appropriate internal queue (SDR or Marketing). input_schema: type: object properties: lead_id: {type: string} queue: {type: string, enum: [sdr, marketing]} reason: {type: string} guardrails: - type: pii_redaction config: patterns: [email, phone, ssn] - type: output_safety config: blocklist: [hate speech, illegal activity, medical advice] # This is where the magic happens: state lives OUTSIDE the model session: persistence: durable # Default. Events go to Anthropics log store. timeout_minutes: 1440 # 24 hours. Session stays alive for replay. # Pricing is transparent: $0.08/session-hour Claude token cost这份 YAML 的力量在于它把所有非模型逻辑都显式化了。system_prompt定义了角色和规则tools列表定义了能力边界每个 tool 的input_schema是契约确保了类型安全guardrails是法律红线session配置则是 SLA 承诺。你不需要关心这个 agent 是跑在 Kubernetes 还是 EC2 上也不用管它用的是 Claude 3.5 Sonnet 还是 Haiku——这些都由 Anthropic 在后台动态调度。你交付的是一份关于“这个 agent 应该做什么、能做什么、不能做什么”的、可审计、可版本控制的声明式合约。这和十年前大家用 Terraform YAML 定义云资源是同一套思维Infrastructure as Code 的进化现在是 Agent as Code。3.2 本地开发与沙箱调试告别pip install的混乱开发阶段你当然不会直接把 YAML 丢到生产环境。Anthropic 提供了一个 CLI 工具claude-agent-dev假设名称它能在你的本地机器上模拟一个完整的 Managed Agents 运行时。初始化沙箱claude-agent-dev sandbox init --config lead_processor_agent.yaml这会启动一个轻量级容器里面预装了所有必需的依赖Python 3.11, requests, pydantic并挂载了一个虚拟的、只读的/vault目录里面放着测试用的 mock credentials。你完全不需要pip install任何东西环境是纯净的。交互式调试claude-agent-dev run --session-id test-123 --input New lead: johnstartup.com, CEO of Acme StartupCLI 会模拟一次完整的 session它会把输入喂给模型然后根据 YAML 中定义的tools在本地沙箱里执行qualify_lead和enrich_company的 mock 实现返回预设的 JSON并将所有 events输入、tool call、tool response、最终输出实时打印在终端上并同时写入一个本地的test-123.events.jsonl文件。你可以像看 Git commit log 一样一行行 inspect 每个 event。日志重放claude-agent-dev replay --session-id test-123如果你在调试中发现了问题比如enrich_company返回的数据格式不对导致后续route_lead失败你可以直接 replay 这个 session。CLI 会精确地重放所有 events让你在同一个“历史快照”下修改你的route_lead的 error handling 逻辑而无需重新走一遍漫长的qualify和enrich流程。这极大地加速了迭代。注意这个本地沙箱的 key point 是mocking 的粒度。它不是 mock 整个 tool而是 mock tool 的response。这意味着你的 agent 代码里execute(enrich_company, ...)这行调用是真实的它真的会发起一个 HTTP 请求指向本地 mock server但返回的 JSON 是你预先定义好的。这保证了你的 agent 逻辑是在一个无限接近生产环境的网络、延迟、错误码条件下被测试的。我们试过一个在本地沙箱里跑了 100 次都完美的 agent在生产环境里第一次就因为enrich_company的503 Service Unavailable错误而卡死——因为我们的 mock 里没定义这个错误分支。于是我们立刻在 mock server 的配置里加上了503的随机返回然后在 agent 代码里补上了重试逻辑。这种“故障注入式”测试是本地开发能逼近生产稳定性的关键。3.3 生产部署与可观测性从aws cloudformation deploy到claude-agent deploy部署就是一行命令claude-agent deploy --config lead_processor_agent.yaml --env production。背后发生了什么Anthropic 的 CLI 会校验检查 YAML 的语法、schema 是否符合规范input_schema是否能被 JSON Schema Validator 解析。打包将 YAML 文件本身连同所有引用的外部 assets比如一个用于 logo 识别的 custom tool 的 Dockerfile打包成一个加密的 tarball。分发将 tarball 上传到 Anthropic 的全球 CDN 边缘节点。注册在 Anthropic 的中央 registry 中为这个 agent 创建一个唯一的agent_id如agnt-acme-sales-lead-1a2b3c并关联其production环境的配置比如 session timeout, rate limit。激活向全球的 Harness 集群广播这个新 agent 的元数据。几分钟内任何一个收到execute(sales-lead-processor, ...)请求的 Harness都能立刻识别出这是哪个 agent并加载其配置。可观测性则完全围绕Session-as-Event-Log展开。Anthropic 控制台提供一个仪表盘核心是三个视图Session Heatmap一个二维矩阵X 轴是小时Y 轴是agent_id格子颜色深浅代表该小时内该 agent 的 session 数量。一眼就能看出哪个 agent 在凌晨 3 点流量暴增可能是 cron job 触发的哪个 agent 在工作日午后持续低迷可能需要优化 prompt。Event Flow Graph点击一个 session ID会展示一个横向的时间线图上面漂浮着一个个圆点每个圆点代表一个 event 类型user_input,tool_call,tool_response,model_output。鼠标悬停能看到该 event 的完整 payload。这是排查问题的黄金视图。Guardrail Trigger Log一个专门的 tab只显示所有被pii_redaction或output_safety拦截的事件。你可以看到是哪封邮件里的哪个邮箱地址被红了是哪次输出里哪个词触发了 blocklist。这对于持续优化system_prompt和guardrails配置至关重要。这套可观测性不是事后分析而是实时诊断。它把原本需要 SRE 团队半夜爬 Nginx 日志、查 Prometheus 指标、翻阅 Sentry 错误的复杂过程简化成了“点一下看图修 YAML”。4. 常见问题与实战避坑指南那些文档里不会写的血泪教训4.1 问题速查表高频故障与根因定位问题现象可能根因排查路径解决方案Session 启动后立即timeout日志里只有user_inputeventsystem_prompt过长或包含大量冗余示例导致模型在生成第一个 token 前就超时查看user_inputevent 的metadata.timeout_ms字段对比system_prompt长度与 Anthropic 文档推荐的最大长度精简system_prompt移除所有非必要的示例。用tools来提供动态示例而非写死在 prompt 里。tool_callevent 显示已发出但tool_responseevent 始终不出现Tool 的实现存在死锁或网络策略阻止了 Harness 与 tool endpoint 的通信在tool_callevent 的inputpayload 中找到endpoint_url用curl -v手动测试该 URL 的连通性和响应时间检查 tool endpoint 的防火墙规则为 tool 添加明确的timeout和retry配置在tool定义中增加health_check_url字段供 Harness 定期探活。awake(sessionId)后agent 行为与预期不符似乎“忘记”了之前的对话Session 的persistence配置被意外覆盖为ephemeral或sessionId在客户端被错误地重置检查 agent 的 YAML 配置在客户端代码中确认sessionId是从上一次execute的响应头中正确提取并传递的严格使用durable模式在客户端 SDK 中强制sessionId作为必填参数并在初始化时进行格式校验如 UUID v4。Guardrailoutput_safety频繁触发导致大量合法输出被拦截blocklist中的词过于宽泛如bank或output_safety的敏感度阈值设置过高查看被拦截的model_outputevent 的metadata.safety_score分析被拦截的文本找出共性使用更精确的正则表达式替代简单字符串匹配调整safety_score的阈值如从0.8降到0.95为特定tool的输出配置bypass_guardrails: true。4.2 实战避坑心得来自踩过的每一个坑坑一不要在system_prompt里写“请一步一步思考”这是新手最大的误区。我们最初为了追求“推理能力”在 prompt 里反复强调“Lets think step by step”。结果发现agent 在处理简单任务如“把 1234567890 格式化为 1,234,567,890”时会真的生成长达 200 tokens 的、毫无意义的“思考过程”严重拖慢 p50 time-to-first-token。后来我们做了 A/B 测试移除这句只保留“Format the number with commas.”性能提升 40%且准确率不变。结论Claude 的 chain-of-thought 是内置的你不需要用自然语言去“喊”它。你的 prompt应该像给一个极其聪明但极其懒惰的同事下指令——越简洁、越具体、越少废话效果越好。坑二tool的input_schema不是摆设是性能瓶颈我们曾定义了一个search_knowledge_basetool其input_schema是{ query: string, filters: object }。filters是一个嵌套很深的 JSON 对象。结果发现当用户输入一个复杂的过滤条件时Harness 在序列化这个input_schema时CPU 占用飙升导致整个 session 的延迟翻倍。根源在于JSON Schema Validator 在处理深度嵌套对象时会进行指数级的递归校验。解决方案把filters改成一个string类型要求前端传入一个预定义的、扁平化的 filter string如status:active,region:us-east,tag:premium然后在 tool 的后端实现里用一个简单的split(,)和dict comprehension来解析。这牺牲了一点 schema 的严谨性但换来了确定性的、亚毫秒级的校验速度。坑三session的timeout_minutes不是“最长存活时间”而是“最长空闲时间”这是一个极易误解的点。timeout_minutes: 144024 小时的意思是如果一个 session 在 24 小时内没有任何新的user_inputevent它就会被自动 GC垃圾回收。但它并不限制 session 的总生命周期。一个活跃的 session可以持续数周只要它每 23 小时 59 分钟就有一个新的用户消息进来。我们曾因此吃过亏一个用于长期项目协作的 agent其timeout_minutes设为601 小时结果用户午休一小时回来发现 session 已“死亡”所有上下文丢失。正确做法对于需要长期记忆的 agenttimeout_minutes应设为一个非常大的值如10080即 7 天并配合客户端的心跳机制定期发送一个空的pingevent来维持 session 活跃。Anthropic 的计费也是按“活跃小时”算的所以一个心跳 event 的成本远低于一次完整的awake()replay()的开销。坑四credential isolation的终极考验是tool的实现本身前面说了credentials 对 agent 代码是不可见的。但这有个前提tool的实现代码必须是“干净”的。我们曾用一个开源的crunchbase-api-client库它内部会读取环境变量CRUNCHBASE_API_KEY。虽然 Harness 拦截了execute但这个库在初始化时还是会去os.getenv。结果API KEY 就这样泄露了。血的教训所有用于 Managed Agents 的tool必须是“零依赖”的、纯函数式的实现。它不能有任何 side effect不能读取任何环境变量不能访问任何外部文件。它只能接收 Harness 传入的input然后返回一个output。我们现在有一个严格的内部规范所有tool必须用 Pydantic 的BaseModel来定义Input和Output并且tool的主函数签名必须是def execute(input: Input) - Output:。任何违反此规范的代码CI 流水线直接拒绝合并。5. 竞争格局与未来演进Runtime 层的“VMware 时刻”与价值迁移5.1 Hyperscaler 的降维打击免费即正义把 Anthropic Managed Agents 放在 AWS Bedrock AgentCore、Google Vertex AI Agent Builder、Microsoft Azure AI Foundry 这个“三巨头”面前它最突出的特点不是技术领先而是生态绑定。Bedrock AgentCore 的定价是免费。你用它运行一个 Claude agent你付的是 Claude 的 token 费AgentCore 本身的 session-hour 是 0 美元。Vertex 和 Foundry 也遵循同样的逻辑runtime 是云平台的“水电煤”是吸引你把更多 workload尤其是模型推理留在自家云上的“钩子”。这就像 AWS 的 EC2它本身不赚钱它赚的是你放在 EBS 上的存储费、你用的 ELB 流量费、你调用的 Lambda 函数费。Hyperscaler 的终极目标是让你的整个 AI stack——从数据湖、向量库、训练框架到推理 endpoint、agent runtime——都运行在它的 IaaS/PaaS 之上。在这种背景下Anthropic 的$0.08/session-hour无论多有竞争力都显得像一个“附加服务费”。它的存在不是为了赢过 AWS而是为了给那些已经深度依赖 Claude 模型、又极度厌恶多云管理复杂性的客户提供一个“一站式”的、免运维的选项。这是一种典型的“围墙花园”策略用极致的垂直整合体验换取一部分客户对底层基础设施的“无知”。这策略有效但它的天花板就是 Anthropic 自己的模型生态规模。5.2 价值迁移的三大高地Trace、Governance、Vertical当 runtime 层不可避免地走向 commoditization商品化价值必然会向上迁移。这不是预测而是历史的重演。我们来看三个正在形成的、真正有护城河的高地第一高地Trace Store追踪存储——AI 世界的“区块链”当session成为一个可查询、可 replay 的事件流它就不再仅仅是 debug 工具而成为了AI 行为的唯一真相源Source of Truth。谁拥有这个 trace谁就拥有了对 agent 行为的最终解释权。Braintrust 的 Brainstore 数据库其核心创新不是更快的查询而是为event设计了专用的 OLAP 引擎能在一个 session 的百万级 events 中毫秒级地回答“在过去 30 天里所有调用过transfer_fundstool 的 sessions其amount参数的平均值、P95 分位数、以及与user_risk_score的相关系数是多少” 这种分析能力是传统日志系统如 ELK无法企及的。它让 trace 从“被动记录”变成了“主动资产”。一个金融客户绝不会允许自己的交易 agent 的 trace 被托管在 Anthropic 的日志系统里。他们需要的是一个私有部署的、符合 SOC2 合规的、能与自己的 Splunk 和 Snowflake 无缝集成的 trace store。这就是 Braintrust 的机会它不卖 runtime它卖的是 runtime 产生的“数据石油”的精炼厂。第二高地Governance Policy治理与策略——AI 世界的“宪法”AWS AgentCore 的 Policy Controls GA标志着一个拐点企业采购 AI infra不再只问“快不快、稳不稳”而是问“能不能管、怎么管”。一个政策Policy可能长这样{ policy_id: finance-strict, applies_to: [agent_id: agnt-acme-finance-*], rules: [ { action: BLOCK, condition: tool_call.name send_email AND user_role ! compliance_officer }, { action: REQUIRE_APPROVAL, condition: tool_call.name execute_sql AND input.db_name prod_financials } ] }这个 policy 的价值不在于它多酷炫而在于它可审计、可追溯、可版本化。每一次BLOCK都会生成一个policy_violationevent写入 trace store并自动通知合规官。这不再是工程师写在代码里的if/else而是上升为企业级的、有法律效力的 IT 策略。目前这个领域没有真正的 incumbent。Arize 的 Phoenix 是一个优秀的开源基础但它离一个能通过 Gartner 评测、能进入 Fortune 500 采购清单的商业产品还有很长的路。谁能率先把 policy language 做得足够直观比如支持低代码拖拽把审计报告做得足够权威比如自动生成符合 ISO 27001 的证明谁就能在这个高地插上第一面旗。第三高地Vertical Agent Marketplaces垂直领域 agent 市场——AI 世界的“App Store”Salesforce 的 Agentforce ARR 达到 8 亿美元这个数字的意义不在于它多大而在于它证明了企业愿意为一个能解决具体业务问题的 agent 付费而不是为一个能跑 agent 的 runtime 付费。一个“医疗理赔自动化 agent”其价值是它每年为保险公司节省的 200 万美元人工审核成本一个“网络安全渗透测试 agent”其价值是它在一次红蓝对抗中发现的那个价值千万美元的 0day 漏洞。这些 agent 的定价是按年费、按 seat、按 transaction而不是按 session-hour。它们的成功不取决于底层 runtime 多快而取决于其对垂直领域知识的深度封装、对行业 workflow 的精准理解、以及与现有 ERP/CRM/HRIS 系统的无缝集成。virattt/ai-hedge-fund 这样的开源项目正是这个趋势的先声。它不是一个通用的 coding agent而是一个专门为量化交易员设计的、能读懂 SEC filings、能回测策略、能生成合规报告的 agent。它的价值是嵌在金融这个垂直领域的“肌肉”里而不是在 runtime 这个“骨骼”上。未来的赢家将是那些能把system_prompt、tools、guardrails、session配置全部打包成一个.agentpkg文件并在自己的 marketplace 上像卖 SaaS 一样卖给成千上万家医院、银行、律所的公司。6. 个人实操体会在 runtime 商品化浪潮中工程师的生存法则我在客户现场部署 Managed Agents 的这一个月最大的体会是我们这一代工程师正在经历一场“抽象层级”的集体迁徙。十年前一个资深后端工程师的核心竞争力是精通 JVM 调优、MySQL 索引优化、Redis Cluster 部署。五年前它变成了熟悉 Kubernetes Operator 开发、Istio 服务网格配置、Prometheus 指标埋点。而今天当你把一个 agent 的 YAML 文件提交给 Anthropic看着它在几秒钟内就完成了从代码构建、镜像推送、集群部署、到健康检查的全过程那种亲手拧紧每一颗螺丝的掌控感正在被一种更宏大的、对“意图”和“契约”的把握所取代。这并不意味着底层技术不重要了。恰恰相反它变得前所未有的重要只是重要性的方式变了。你不再需要花三天时间去 debug 一个 k8s 的CrashLoopBackOff但你需要能一眼看出为什么system_prompt里一句模糊的“尽快处理”会导致 agent 在tool_call时选择了错误的 timeout 值你不再需要手动配置 Istio 的 VirtualService但你需要能设计出一个tool的input_schema让它既能抵御恶意的超长输入攻击又不会因为过度校验而拖垮性能。所以我的建议很实在把你的学习重心从“如何搭建 runtime”转向“如何定义 agent”。深入研究 JSON Schema 的高级特性掌握如何用oneOf、anyOf来表达复杂的业务约束学习如何用 OpenTelemetry 的 Span Attributes 来丰富你的event让 trace store 能回答更刁钻的业务问题最重要的是花时间去你的业务部门坐一周不是听他们讲需求而是看他们怎么用 Excel、怎么打电话、怎么在纸质表格上画圈。因为未来最有价值的system_prompt不会诞生于技术文档而会诞生于销售总监的晨会纪要、客服主管的投诉录音、或是工厂车间主任的巡检笔记里。Runtime 层正在变薄而“人”与“业务”之间的那一层正在变得无比厚重。抓住这一层你就抓住了下一个十年。
