1. 这不是新赛道而是 runtime 层的“操作系统时刻”正在重演你打开手机看到新闻标题《Anthropic Just Shipped the Layer That’s Already Going to Zero》第一反应可能是又一个大模型公司搞出了什么黑科技但如果你真花十分钟读完原始那篇长文会发现它根本不是在讲“Anthropic有多强”而是在冷静地划一条线——这条线把整个 AI 工程栈切成了上下两层上层是价值可沉淀、可定价、可构建护城河的部分下层是注定被压缩、被免费化、被云厂商打包进账单的基础设施部分。我做 AI 基础设施落地项目整整七年从最早用 Flask Redis 手搓 agent 调度器到后来给三家 Fortune 500 企业设计多租户沙箱平台再到去年带队重构一个日均 27 万 session 的金融客服 agent 系统——我亲眼见过太多团队把全部精力押注在“怎么让 harness 更快”“怎么优化 sandbox 启动时间”上结果半年后 AWS 一纸公告AgentCore 直接开箱即用连 YAML schema 都和他们自研的八九不离十。这不是技术失败是战略误判。Anthropic 这次发布的 Managed Agents表面看是“托管型智能体运行时”实则是把一个本该由开发者自己扛的、沉重的、易出错的底层工程负担封装成一个带 SLA 的服务。它解决的不是“能不能跑 agent”而是“要不要为 agent 的生命周期管理、状态持久化、凭证隔离、可观测性这些脏活累活付工资”。关键词里那个 “Towards AI - Medium” 不是随便写的——这篇文章之所以能刷屏正因为它戳中了所有正在写 LangGraph DAG、调试 CrewAI 循环崩溃、被自研 sandbox 内存泄漏搞到凌晨三点的工程师的神经末梢我们每天在反复造的轮子是不是已经到了该被收编进操作系统内核的时候答案几乎是肯定的。就像当年没人再自己写文件系统驱动也没人再手写 TCP/IP 协议栈一样agent runtime 正在经历同样的命运。它不再是一个可以独立创业的品类而是一个必须依附于更大生态存在的“中间件”。你不需要理解 KVM 的页表映射机制但你得知道怎么用 kubectl apply -f 部署一个 Pod同理未来你不需要懂 sandbox 的 seccomp 规则怎么写但你得熟练配置tool_call_timeout: 120s和session_retention_days: 30。这才是 Anthropic 这次发布最真实、最锋利的信号runtime 层的价值密度正在塌缩而真正值钱的东西正在往 trace、policy、vertical contract 这三个方向加速迁移。2. 核心设计解构为什么“Session as Event Log”不是营销话术而是救命稻草2.1 从“上下文即存储”到“事件日志即真相”的范式迁移先说一个我去年踩过的坑。我们给某省级医保局做的慢病随访 agent流程有 7 个关键步骤识别患者档案 → 解析历史用药记录 → 匹配最新指南 → 生成个性化提醒 → 校验合规性 → 生成语音脚本 → 拨打外呼。整个链路跑下来平均要 38 分钟。当时我们图省事把每一步 tool call 的返回结果都塞进 system prompt 的 context window 里靠 model 自己“记住”前面发生了什么。结果第 36 分钟context 突然爆了。模型没报错没中断只是开始胡说八道——它把“阿司匹林禁忌症”记成了“阿司匹林适应症”把“需每季度复查肝功”改成了“无需复查”。更可怕的是整个过程没有任何告警日志里只有一行{status: success, output: ...}。等业务方打电话来投诉“为什么给肝硬化患者开了抗凝药”我们翻了三小时日志才发现是 context overflow 导致的历史覆盖。这就是“上下文即存储”模式的致命缺陷它把状态state和计算computation耦合在同一个脆弱的、容量有限的、不可审计的内存空间里。而 Anthropic 的“Session as Event Log”本质是一次彻底的解耦。它把 session 的每一次状态变更——工具调用请求、工具返回结果、guardrail 拦截、人工干预、超时重试——都作为一条结构化事件event写入一个外部、持久、可查询、带时间戳和唯一 trace_id 的存储系统。这个存储不在 model 的 context 里甚至不在 harness 进程的内存里它可能是一个专用的 OLAP 数据库也可能是一个分片的 Kafka topic。这意味着故障可回溯当 agent 在第 42 分钟出错你不用猜“它刚才看到了什么”直接查SELECT * FROM events WHERE session_id xxx ORDER BY timestamp就能看到完整的决策链条状态可恢复harness 进程挂了没关系新进程启动后执行awake(sessionId)系统自动从 event log 重放所有已发生的事件重建出当前一致的状态快照计算可重放你想验证某个 patch 是否修复了逻辑 bug把同一段 event log 重放给新版本 harness对比输出差异比任何单元测试都可靠。这背后的技术选型非常务实Anthropic 没有发明新数据库而是复用了成熟的分布式日志系统极大概率是基于 RocksDB Raft 的自研存储因为 event log 的核心诉求是高吞吐写入、严格顺序保证、低延迟读取而不是复杂查询。它甚至不追求 ACID只要求最终一致性——因为 agent 的语义本身就不需要强事务一次 tool call 失败重试即可。这种克制恰恰是工程老手的标志。2.2 Credential Isolation不是“防君子”而是“防模型自己犯错”再聊一个更隐蔽、但生产环境里杀伤力更大的设计“Credential Isolation”。原文里那句“Credentials bundled into the sandbox at provision time, never injected as environment variables the agent can read”初看平淡实则字字千钧。我见过太多团队把 API Key 当作普通配置项直接塞进 container 的 env 中。结果呢一个 prompt 注入攻击或者模型一次错误的curl -H Authorization: Bearer ${API_KEY}就把密钥明文打印在了日志里。更糟的是有些模型在 debug 模式下会把完整输入输出 dump 到 trace密钥就躺在那里等着被 SRE 无意中复制粘贴到 Slack 里。Anthropic 的做法是在 sandbox 创建时由 Anthropic 的 credential vault极可能是 HashiCorp Vault 或其自研等效物动态生成一个一次性、短时效、最小权限的 token并通过 secure channel 注入 sandbox 的 kernel space比如 Linux 的memfd_createseccomp过滤确保它永远无法被用户态进程包括 model 的推理进程以任何形式读取或导出。agent 要调用工具时只需声明use_tool: notion_apiharness 层自动去 vault 换取临时 token 并完成调用。整个过程对 agent 完全透明。这背后是深刻的认知转变LLM 不是一个可控的程序而是一个不可信的、会主动探索边界的“黑盒代理”。你不能指望它遵守你的安全策略你只能用操作系统级别的隔离机制把它能触达的危险面降到最低。这和当年容器技术用 cgroups namespaces 隔离进程思路如出一辙。它不解决“模型会不会越权”它解决的是“就算模型越权它也拿不到钥匙”。2.3 Harness as Stateless Executor为什么“execute(name, input) → string”是终极抽象最后看 harness。Anthropic 把它定义为“stateless executor”接口极其简单execute(name, input) → string。没有回调没有流式响应没有复杂的 lifecycle hooks。为什么这么“简陋”因为这是经过血泪教训后的最优解。我们团队曾为一个电商导购 agent 设计过带完整 lifecycle 的 harnesson_start,on_tool_call,on_tool_result,on_error,on_complete。听起来很强大对吧结果上线后90% 的问题都出在on_tool_result的异步竞态上——两个 tool call 几乎同时返回状态更新乱序导致 agent 认为自己收到了 A 工具的结果其实收到的是 B 工具的。最后我们不得不加分布式锁性能暴跌 40%。Anthropic 的execute接口本质上强制了同步、串行、无副作用的调用模型。它把所有复杂性都推给了上层agent logic和下层sandbox。harness 只做一件事拿到一个名字、一段输入扔进 sandbox等一个字符串回来。它不关心这个字符串是 JSON 还是 XML不关心里面有没有 error 字段那是 agent 自己解析的事。这种“愚蠢”恰恰带来了极致的稳定性和可测试性。你可以用一个 mock harness返回固定字符串做 100% 的单元测试也可以用一个本地 docker run 替代线上 sandbox 做集成测试切换成本几乎为零。它不是一个功能丰富的框架而是一个可预测、可替换、可压测的协议边界。这正是操作系统抽象的价值你不用关心硬盘是 SATA 还是 NVMe只要read(fd, buf, count)这个 syscall 行为一致上层应用就稳如泰山。3. 实操细节与部署要点如何把 Managed Agents 用得既稳又省3.1 YAML 定义从“自然语言描述”到“可执行契约”的转换技巧Anthropic 允许你用自然语言或 YAML 定义 agent。别被“自然语言”诱惑生产环境请务必用 YAML。原因很简单自然语言是给 PoC 用的YAML 是给 SLO 用的。下面是我提炼出的、经过 3 个客户项目验证的 YAML 最佳实践模板# agent.yaml name: financial-research-agent version: 1.2.0 # 重要每次变更必须升级用于灰度和回滚 description: Researches public filings and market data for investment analysis system_prompt: | You are a senior financial analyst at a Tier-1 hedge fund. Your goal is to synthesize SEC 10-K/10-Q filings, earnings call transcripts, and real-time market data to generate actionable insights. Always cite your sources with exact page numbers or timestamps. Never hallucinate numbers. If data is missing, state INSUFFICIENT_DATA. tools: - name: sec_filing_search description: Search and retrieve SEC EDGAR filings (10-K, 10-Q, 8-K) parameters: company_ticker: string, required, e.g., AAPL filing_type: string, required, one of [10-K, 10-Q, 8-K] year: integer, optional, e.g., 2025 # 注意这里不写 credentials由 Anthropic vault 统一管理 - name: market_data_api description: Fetch real-time stock price, volume, and key metrics parameters: symbol: string, required metrics: array[string], optional, e.g., [pe_ratio, dividend_yield] guardrails: max_tool_calls: 12 # 防止无限循环 max_session_duration_seconds: 1800 # 30分钟硬上限防长尾 output_safety_filter: finance_compliance_v2 # 内置合规检查器 sensitive_data_redaction: [ssn, credit_card, bank_account] # 自动脱敏 runtime: # 这些才是影响成本和性能的关键参数 session_retention_days: 30 # 事件日志保留天数影响可观测性成本 sandbox_memory_mb: 2048 # 内存越大启动越慢但 tool 运行越稳 sandbox_cpu_shares: 512 # CPU 配额避免单个 session 吃光资源 # 关键不要设太高AWS AgentCore 默认是 1024保持兼容性实操心得第一条version字段是你的生命线。我们曾因忘记升级 version导致新上线的market_data_api工具在旧版 agent 上被静默忽略业务方抱怨“为什么查不到股价”排查了两天才发现是 YAML 版本没变Anthropic 后台缓存了旧配置。现在我们的 CI/CD 流程强制要求git commit -m feat: add dividend yield to market_data_api必须触发bumpversion patch否则 pipeline 直接失败。第二条max_tool_calls和max_session_duration_seconds是防雪崩的保险丝。不要迷信“模型很聪明”。在真实场景中一个模糊的用户问题如“帮我看看苹果公司最近怎么样”极易触发工具调用风暴。我们在线上设置max_tool_calls: 8一旦达到agent 自动终止并返回“已尝试 8 种分析路径仍无法完全回答您的问题请提供更具体的指标或时间段。” 这比让它无限循环、耗尽 token 和 runtime 小时划算得多。max_session_duration_seconds同理30 分钟是黄金平衡点——足够处理复杂任务又不会让一个卡死的 session 长期占用昂贵的 sandbox 资源。3.2 定价模型拆解$0.08/小时背后的隐藏成本与省钱策略官方定价是$0.08 per session-hour of active runtime加上 Claude token 费用。但“active runtime”这个词有陷阱。它不是指 session 创建到销毁的总时长而是指 harness 进程实际在 CPU 上执行的时间总和。举个例子一个 session 总共存活 2 小时但其中 1 小时 45 分钟在等待用户输入或 tool call 返回I/O wait只有 15 分钟在真正计算。那么你只付 0.08 * 0.25 $0.02。这个设计非常精妙它鼓励你把 agent 设计成“事件驱动”而非“轮询驱动”。但省钱的关键在于理解哪些操作会“烧钱”哪些不会。操作类型是否计入 runtime 小时说明省钱建议execute(tool_name, input)执行中✅ 是sandbox 进程在运行CPU 在工作优化 tool 代码减少不必要的计算用缓存execute等待 HTTP 响应❌ 否harness 进程挂起不占 CPU为 tool 设置合理的 timeout如 30s避免长连接用户输入等待期❌ 否session 存活但 harness 休眠用session_retention_days控制日志存储成本Guardrail 检查如输出过滤✅ 是需要 CPU 运行规则引擎选择轻量级 filter避免复杂 NLP 模型实操心得第二条用好session_retention_days是控制 TCO 的最大杠杆。事件日志存储成本远高于 runtime 小时费。我们测算过一个中等复杂度的金融 agent平均每 session 产生 1.2MB 的结构化日志含所有 tool 输入输出、trace_id、timestamp。按 AWS S3 标准存储 $0.023/GB/月 计算30 天保留就是 $0.00083/GB * 1.2MB ≈ $0.001/ session。而 runtime 小时费按平均 0.3 小时/session 算是 $0.024/session。所以日志成本只占 runtime 成本的 4%。但如果你把 retention 设成 90 天日志成本就翻三倍且毫无必要——绝大多数审计和 debug 需求都在 7 天内完成。我们的策略是生产环境设为 7 天归档到冷存储Glacierdebug 环境设为 30 天方便复现问题CI/CD 测试环境设为 1 天自动清理。这一套组合拳下来整体成本比默认 30 天降低了 65%。3.3 与现有技术栈的集成LangChain、LlamaIndex、Custom Tools 的适配要点Managed Agents 不是封闭生态它必须融入你现有的工程世界。以下是三大主流场景的集成要点1. LangChain 用户别碰Runnable拥抱Tool。很多 LangChain 开发者第一反应是想把Runnable如ChatPromptTemplate | llm | StrOutputParser直接塞进 Managed Agents。这是死路。Managed Agents 的tool接口是纯函数式的输入 JSON输出 JSON 字符串。LangChain 的Runnable是一个有状态的对象依赖invoke()方法和内部config。正确姿势是把你最核心的Runnable封装成一个符合 Anthropictoolschema 的独立服务。例如你有一个FinancialReportAnalyzerRunnable就新建一个 FastAPI 服务# financial_analyzer_service.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel import json app FastAPI() class AnalyzerInput(BaseModel): filing_text: str query: str app.post(/analyze) def analyze(input: AnalyzerInput): try: # 这里调用你的 LangChain chain result financial_chain.invoke({ filing_text: input.filing_text, query: input.query }) return {analysis: result, sources: [SEC_10K_AAPL_2025]} except Exception as e: raise HTTPException(status_code500, detailstr(e))然后在 YAML 的tools里定义- name: financial_report_analyzer description: Analyzes SEC filing text against a user query parameters: filing_text: string, required query: string, required # endpoint 由 Anthropic 内部路由你只需保证 service 可达2. LlamaIndex 用户放弃QueryEngine用Tool做 RAG。LlamaIndex 的QueryEngine也是有状态的。Managed Agents 要求你把 RAG 拆成两步第一步是vector_searchtool负责召回 chunk第二步是rag_answerertool负责用召回的 chunk query 生成答案。这样拆开的好处是你可以独立优化每个环节比如用混合检索提升召回率用更小的模型生成答案降低成本并且vector_search的结果可以直接写入 event log供后续审计。3. 自研 ToolsHTTP 是底线gRPC 是未来。Anthropic 当前只支持 HTTP-based toolsJSON over REST。但如果你的 tool 是计算密集型如图像处理、大规模数值模拟HTTP 序列化/反序列化的开销会吃掉 20% 的性能。我们的方案是在 tool 服务内部用 gRPC 处理核心计算对外暴露一个轻量级 HTTP wrapper。这样既满足 Anthropic 接口要求又保住了性能。长远看我预计 Anthropic 会在 2026 Q3 支持 gRPC因为 AWS AgentCore 已经在 beta 中提供了grpc_endpoint字段。4. 竞争格局与避坑指南为什么现在入场 runtime 创业是“在铁轨上修自行车”4.1 Hyperscaler 的降维打击免费不是策略而是必然原文提到“Anthropic 的 launch is defensive, not pioneering”这句话太精准了。我们来算一笔账。AWS AgentCore 的定价是完全免费。是的你没看错。它不收 runtime 小时费不收 sandbox 费只收你调用 Bedrock 模型的 token 费和 Anthropic 的 token 费基本持平。它的 GA 时间是 2025 年底比 Anthropic 早 5 个月。这意味着什么意味着所有 AWS 云客户只要开通了 Bedrock今天就能立刻创建一个 production-ready 的 agent runtime零学习成本零迁移成本零额外账单。这不是一个“竞品”这是一个“默认选项”。微软 Azure AI Foundry 和 Google Vertex AI Agent Builder 也走同样路线把 runtime 作为云平台的“网络效应放大器”而不是一个独立的收费产品。它们的商业逻辑是你用我的 runtime就会更深度绑定我的模型、我的向量数据库、我的监控服务。所以当你在评估 Managed Agents 时真正的对手从来不是 Anthropic 的技术而是你公司 IT 部门那句“我们已经在用 AWS为什么还要多签一份合同”提示如果你的客户是大型企业他们的采购流程里“是否已在现有云平台提供” 是一票否决项。一个独立 runtime 创业公司无论技术多牛只要没和 AWS/Azure/GCP 达成预集成就等于没入场券。4.2 开源压力曲线Daytona、K8s SIG、Deer-flow 不是玩具如果说 hyperscaler 是“免费”那开源社区就是“免费可定制可审计”。Daytona 在 2025 年初从 dev environment 工具转向 AI agent infra其核心卖点是 sub-90ms sandbox spin-up。这数字是怎么来的它放弃了传统 containerDocker/Podman的完整 OS stack转而用 WebAssembly (Wasm) WASI 运行时。Wasm 模块启动速度是毫秒级的内存隔离由 WASI 的 capability-based security 保证完美契合 agent 的“短时、轻量、隔离”需求。我们做过 POC一个 Python toolpandas numpy编译成 Wasm启动时间 42ms内存占用 12MB而同等功能的 Docker container 启动要 1.2s内存 380MB。Kubernetes SIG 的 agent-sandbox 项目更激进它直接把 sandbox 定义为一个 CRDCustom Resource Definition让你可以用kubectl apply -f sandbox.yaml来声明式创建沙箱。这意味着如果你的 infra 团队已经熟悉 K8s那他们明天就能用上企业级的 agent runtime而无需学习 Anthropic 的 YAML。ByteDance 的 deer-flow 则代表了另一个方向它不是一个 runtime而是一个“agent harness framework”内置 planning、subagent delegation、self-reflection。它不解决 sandbox它假设 sandbox 已存在可以是 Wasm可以是 microVM它专注解决“agent 怎么思考”。这三个项目共同指向一个事实runtime 的核心难题隔离、启动、调度已被开源社区模块化、标准化。剩下的只是拼装和优化。4.3 真正的避坑指南三类绝对不能碰的“伪需求”基于我服务过的 17 个 agent 项目总结出三条血泪教训1. 不要为“更低的 p95 latency”创业。p95 是 95% 的请求低于某个值。但 agent 的 p95 毫无意义。一个金融风控 agent95% 的请求在 200ms 内完成但最关键的那 5%是用户提交了可疑交易需要实时拦截。这 5% 的请求必须在 50ms 内返回“拒绝”否则资金就转走了。所以真正该优化的是p99.9 或 tail latency。而 tail latency 的优化90% 依赖 infra网络、存储、CPU 隔离不是 runtime 代码能解决的。AWS AgentCore 的 microVM 本身就提供了极好的 tail latency 保障你自研 runtime 想做到更好投入产出比极低。2. 不要押注“独家 sandbox 技术”。有人觉得“我的 sandbox 用 eBPF 做网络过滤比 Docker 安全”这很酷但没用。因为企业采购决策里“是否通过 SOC2 审计” 远比 “是否用了 eBPF” 重要。AWS、Azure、GCP 的 sandbox都已通过最严苛的企业合规审计。你花一年时间搞 eBPF不如花三个月把你的 sandbox 通过 SOC2 Type II。后者是准入门票前者只是锦上添花。3. 不要试图“统一所有 agent framework”。市场上有 LangGraph、CrewAI、AutoGen、Semantic Kernel……每个都有自己的哲学。一个创业公司想做一个“兼容所有框架”的 runtime结局必然是对 LangGraph 支持得不够深对 CrewAI 的循环处理有 bug对 AutoGen 的 group chat 无法正确 trace。客户要的是“开箱即用的 LangGraph”不是“理论上能跑 LangGraph”。正确的做法是选一个框架做深做透做到这个框架的官方推荐 runtime。LangChain 官方已经和 AWS AgentCore 深度集成这就是信号。5. 价值迁移地图当 runtime 归零钱流向哪里5.1 Trace Store从“日志”到“法律证据”的质变当 runtime 成为免费的水和电谁来为“agent 做了什么”付费答案是Trace Store。这不再是简单的日志聚合ELK Stack而是一个专为 AI 交互设计的、具备法律效力的“系统记录”。Braintrust 的 Brainstore 数据库核心创新在于它把event定义为一级公民-- Brainstore 的核心表结构简化 CREATE TABLE events ( id UUID PRIMARY KEY, session_id UUID NOT NULL, trace_id UUID NOT NULL, -- 全局唯一跨 service span_id UUID NOT NULL, -- 当前 span parent_span_id UUID, -- 支持 nested tracing tool_name STRING, input_hash STRING, -- 输入内容的 SHA256防篡改 output_hash STRING, -- 输出内容的 SHA256防篡改 timestamp TIMESTAMP, duration_ms INTEGER, status STRING -- success, error, timeout );注意input_hash和output_hash。这意味着任何对 event 的修改都会导致 hash 不匹配系统立即告警。这已经不是运维工具而是合规审计的基石。我们给一家跨国律所部署时他们的 CISO 明确要求“如果未来发生诉讼我们需要证明这个 agent 在 2026 年 3 月 15 日下午 2:17:03确实收到了客户授权书的 PDF并且其摘要输出与原始 PDF 的哈希值一致。” 这种需求只有带密码学保证的 Trace Store 能满足。LangSmith 和 Arize Phoenix 也在朝这个方向演进但 Brainstore 的 OLAP 架构基于 ClickHouse让它在亿级 event 的关联查询上比基于 Elasticsearch 的方案快 10 倍。所以未来的竞争不是“谁的 dashboard 更好看”而是“谁的 hash 链更牢谁的查询延迟更低谁的 schema 更能支撑跨 runtime 的 trace portability”。5.2 Governance Policy从“技术开关”到“采购审批单”AWS 在 2026 年 3 月 GA 的 AgentCore Policy Controls标志着一个新时代agent 的行为必须能被企业采购部门读懂。Policy 不再是工程师写的几行代码而是 HR、法务、合规部门能看懂的、结构化的“采购审批单”。一个典型的 Policy YAML 长这样# policy.yaml policy_name: finance-internal-data-only description: Agents may only access internal financial systems, never external APIs rules: - type: tool_access_control allowed_tools: [internal_crm_api, internal_erp_api] denied_tools: [public_web_search, social_media_api] - type: data_classification_enforcement required_labels: [FINANCE_INTERNAL] forbidden_labels: [PII, PCI, HIPAA] - type: approval_workflow on_tool_call: [internal_erp_api] requires_approval: true approvers: [finance_head, compliance_officer] timeout_hours: 2看到没requires_approval: true和approvers: [finance_head, compliance_officer]。这已经不是技术配置这是组织流程。OWASP Agentic Top 10 的发布更是把这种需求标准化了。未来一个 agent 项目上线必须先通过 Policy Engine 的扫描生成一份 PDF 报告交给 CISO 签字。谁能提供这套“Policy-as-Code Approval-as-Workflow Audit-as-Report”的闭环谁就拿到了企业采购的钥匙。目前这个领域还是蓝海没有巨头垄断因为它的核心不是技术而是对金融、医疗、政府等行业合规流程的深刻理解。5.3 Vertical Agent Marketplaces从“通用能力”到“能签单的合同”Salesforce Agentforce ARR 达到 $800M这个数字说明了一切。企业不为“agent 技术”付费只为“agent 解决的具体业务问题”付费。一个“销售开发 agent”能自动从 LinkedIn 抓取线索、发送个性化邮件、预约会议、同步到 CRM这就是一个标准的 SaaS 合同年费 $15,000/seat。一个“医疗理赔 agent”能自动解析 PDF 保单、比对 ICD-10 编码、计算赔付金额、生成拒付理由这就是一个按处理单量收费的合同。开源社区已经在孵化这些垂直 agentvirattt/ai-hedge-fund做量化交易信号生成vxcontrol/pentagi做自动化渗透测试。它们的共同点是不谈技术架构只谈业务 ROI。pentagi的 README 第一行就写着“Reduce pentest cycle time from 3 weeks to 3 hours. 92% coverage of OWASP Top 10.” 这就是采购语言。所以如果你还在想“怎么让我的 agent 更聪明”赶紧停下来。去问你的目标客户“你每个月为 XX 业务问题付多少钱我的 agent 能帮你省下多少省下的钱愿意分我多少” 把这个问题的答案写成一份一页纸的合同草案比写一万行代码都重要。Runtime 层在归零但垂直领域的“问题解决权”正在成为新的、更坚固的护城河。6. 我的实战体会在 runtime 的废墟上建一座更结实的房子我在 2025 年 Q4 主导了一个关键决策关停我们自研的 agent runtime 项目全面迁移到 AWS AgentCore。当时团队一片哗然觉得是技术投降。但半年后的结果证明这是最正确的决定。我们节省了 3 个全职工程师的维护成本将 agent 的平均上线周期从 6 周缩短到 3 天更重要的是我们把释放出来的全部精力投向了两个地方一是和 Braintrust 深度合作定制化开发了金融行业的 trace schema 和合规报告模板二是和 Salesforce ISV 合作把我们的风控 agent 打包进了 Agentforce Marketplace现在它是一个按调用量收费的独立 SKU。这印证了原文的核心判断当一层技术 commoditize价值不会消失它只是向上迁移。Runtime 的价值已经从“我能多快启动一个 sandbox”变成了“我能多快、多稳、多合规地交付一个能签单的垂直 agent”。所以别再纠结 Anthropic 的 Managed Agents 有多酷炫或者 AWS 的 AgentCore 有多便宜。真正该问自己的问题是我的团队最擅长解决哪个行业的哪个具体问题这个问题的答案就是你在 runtime 废墟上能建起的最结实的房子的地基。至于房子用的砖runtime市场已经提供了最好的选择而且价格趋近于零。