1. 这不是新赛道，是 runtime 层的“操作系统时刻”来了
你有没有试过让一个 AI 代理连续工作四十分钟，处理一份需要反复查文档、调 API、写草稿、再校对的复杂任务？我去年就干过这事。当时我们把所有中间状态——用户原始提问、检索到的三份 PDF 摘要、两次 API 调用返回的 JSON、上一轮生成的初稿段落——全塞进模型的上下文窗口里。开始很顺，但到第三十七分钟，上下文满了。模型没报错，也没中断，它只是悄悄把最早那条 PDF 摘要给“挤掉”了。接着，它基于一个残缺的历史，开始编造后续步骤。我们直到最后提交前五分钟才意识到：整个流程的依据链断了，而那个 session 的完整过程，根本没法回溯、没法重放、没法 debug。它就像一盘没保存的棋局，输得无声无息，却花了团队两天工时。
Anthropic 在 4 月 8 日发布的 Claude Managed Agents，表面看是一套托管运行时，但它的核心价值，恰恰就是为了解决这个“无声崩溃”的问题。它把 session（会话）从模型的上下文里彻底剥离出来，变成一个独立、持久、可查询的事件日志。这不是锦上添花的功能，而是把整个 agent 系统从“易碎品”变成“工业品”的关键分水岭。关键词里的 “Towards AI - Medium” 并非指向某个平台，而是代表一种典型的、面向工程实践者的深度技术分析语境——它不讲“AI 将如何改变世界”，只问“这个东西在生产环境里能不能扛住真实用户的胡乱点击和长达八小时的连续追问”。
Managed Agents 的本质，是一个被精心设计的、面向企业级可靠性的 agent 执行框架。它不试图取代 LangChain 或 LangGraph 这类编排层，也不跟 Cursor 或 GitHub Copilot 这类 IDE 工具抢用户界面。它专注做一件事：当你的 agent 逻辑写好之后，谁来保证它每次执行都干净、隔离、可审计、可恢复？答案是 Anthropic 提供的 harness（执行器）、sandbox（沙箱）和 session store（会话存储）这三层抽象。这三层加起来，构成了一个现代 agent 应用的“操作系统内核”。它让你能像当年开发者依赖 Linux 内核管理内存和文件一样，放心地把 agent 的状态管理、工具调用、权限隔离这些脏活累活，交给一个稳定、透明、有 SLA 的底层去处理。所以，如果你正在评估是否要把自己手写的 agent 部署到 AWS Lambda 上，或者纠结于怎么安全地把数据库密码传给一个 LLM 调用的 Python 脚本，那么 Managed Agents 就不是“又一个新玩具”，而是你技术选型中一个值得严肃对待的、能立刻降低运维熵值的务实选项。
2. 核心设计拆解：为什么是“Session as Event Log”，而不是“Session as Context”
2.1 会话即事件日志：一场静默的架构革命
“Session as Event Log” 这个短语，在 Anthropic 的工程博客里被反复强调，但它背后的技术含义远比字面深刻。我们先拆解一下传统做法的痛点。假设你用 LangChain 写一个客服 agent，它需要：1）读取用户问题；2）查询知识库；3）调用订单系统 API；4）综合信息生成回复。在传统模式下，这四步的每一步结果，都会被拼接成一段长长的字符串，塞进模型的输入 prompt 里。这导致三个致命问题：
第一，状态膨胀不可控。一次简单的订单查询，API 返回的 JSON 可能就有 2KB；知识库检索的摘要再加 1KB；再加上历史对话，很快就会逼近 Claude 3.5 Sonnet 的 200K token 上下文上限。更糟的是，token 计费是按输入+输出总和算的，这意味着你为“记住自己做过什么”付出了越来越贵的账单。
第二，故障不可追溯。当第 4 步生成的回复出现事实性错误时，你是无法精准定位问题出在哪一步的。你只能看到最终的 prompt 字符串，而不知道是知识库摘要本身有误，还是 API 返回了异常数据，抑或是模型在整合时理解错了。整个过程像一个黑箱，只有输入和输出，没有中间态的“快照”。
第三，恢复成本极高。如果 agent 在第 3 步调用 API 时因网络超时而中断，你无法让它从第 3 步重新开始。你必须重跑整个流程，再次消耗 token 去重新检索知识库、再次生成冗长的 prompt。这在需要长时间运行的自动化任务（比如周报生成、合规审查）中，是不可接受的效率损失。
Managed Agents 的解法，是引入一个外部的、持久化的、结构化的事件日志系统。每一次 agent 的动作，都被记录为一条带时间戳、唯一 ID 和明确类型的事件：
EVENT_TYPE: TOOL_CALL_STARTtool_name: "search_knowledge_base"input: {"query": "退货政策"}session_id: "sess_abc123"EVENT_TYPE: TOOL_CALL_COMPLETEtool_name: "search_knowledge_base"output: {"summary": "7天无理由退货...", "source_url": "https://..."}session_id: "sess_abc123"EVENT_TYPE: MODEL_OUTPUTcontent: "根据我们的退货政策，您可以在7天内申请无理由退货..."session_id: "sess_abc123"
这个日志不是存在内存里，而是由 Anthropic 后端以高可用方式存储。这意味着，无论你的 agent harness（执行器）是运行在 AWS 上还是 Azure 上，甚至它自己崩溃了，只要 session_id 不丢，你就能随时通过awake(sessionId)接口，让一个新的 harness 实例加载这个完整的事件流，从中断点精确续跑。这不再是“重启”，而是“热迁移”。它把 agent 的“灵魂”（状态）和“肉体”（执行环境）彻底解耦了。这种设计，直接对标的是分布式系统里的“Command Query Responsibility Segregation (CQRS)”模式——命令（tool call）和查询（model output）被分离，状态变更被记录为不可变事件，从而天然支持审计、重放和补偿。
2.2 Harness：无状态的“执行引擎”，而非有状态的“大脑”
Harness 这个词在 Anthropic 的文档里被定义为“stateless executor”，即无状态执行器。这是另一个常被误解的关键点。很多开发者第一反应是：“无状态？那我的 agent 逻辑怎么保持记忆？”答案是：harness 本身不负责记忆，它只负责“干活”。它是一个极其轻量的、纯粹的调度器。
你可以把它想象成一个高级版的curl命令行工具。它的核心接口只有一个：execute(name, input) → string。当你调用execute("search_knowledge_base", {"query": "退货政策"})时，harness 的工作流程是：
- 解析请求：确认
search_knowledge_base是一个已注册的、被允许的工具。 - 准备沙箱：向 Anthropic 的沙箱服务发起请求，要求启动一个全新的、隔离的容器实例。
- 注入凭证与输入：将预设的、经过严格权限控制的 API Key（例如知识库的只读 Token），以安全的方式注入沙箱内部，同时把
{"query": "退货政策"}作为标准输入（stdin）传递进去。 - 等待执行：监控沙箱进程，等待其完成或超时。
- 捕获输出：读取沙箱的标准输出（stdout），将其作为
string返回给调用方。
整个过程中，harness 自身的内存里，除了当前这次调用的参数，不保留任何关于“之前调用过什么”、“用户是谁”、“session 是什么”的信息。所有的状态，都由外部的 session event log 来承载。这种设计带来了巨大的工程优势：
- 极致的可伸缩性：你可以水平扩展无数个 harness 实例，它们之间完全不需要共享任何状态，也不存在“状态同步”的难题。流量高峰时，自动扩容；低谷时，自动缩容，零成本。
- 极简的故障域：harness 崩溃了？没关系，下一个请求会被路由到另一个健康的实例上，它会从 event log 里读取到上一步的状态，无缝继续。整个系统的“心脏”不是 harness，而是那个高可用的 event log 存储。
- 清晰的责任边界：开发者只需关心两件事：1）我的 agent 逻辑（即
execute的调用序列）是否正确；2）我的工具（如search_knowledge_base）的代码是否健壮。harness 的可靠性，由 Anthropic 保障。这极大地降低了团队的运维心智负担。
2.3 Sandbox：真正的“一次性 cattle”，而非“娇贵的 pets”
如果说 harness 是调度员，那么 sandbox 就是那个真正动手干活的“临时工人”。Anthropic 对 sandbox 的设计哲学，完美体现了云原生时代的“cattle not pets”理念——即把计算资源当作可批量替换的牲畜，而不是需要精心呵护的宠物。
传统上，很多团队为了运行 agent 的工具脚本，会维护一个长期运行的服务器或容器。这个环境里装着 Python、各种 SDK、数据库驱动，甚至可能还存着一些缓存文件。它就是一个“pet”：你得给它打补丁、升级依赖、监控内存、处理磁盘满的问题。一旦出问题，修复它需要时间，而且风险很高。
Managed Agents 的 sandbox 则完全不同。它是一个按需创建、用完即焚的微型虚拟机（microVM）或高度隔离的容器。每次execute调用，都会触发一个全新的 sandbox 实例的创建。这个实例的生命周期，严格绑定于这一次 tool call：
- 启动：从一个干净、预置的镜像启动，里面只包含运行该工具所必需的最小化运行时（例如，
search_knowledge_base工具只需要一个 Node.js 环境和一个 HTTP 客户端）。 - 执行：工具代码在此环境中运行，它能看到的，只有本次调用的
input和预配置的、经过 Vault 管理的 credentials（密钥）。它绝对看不到其他任何 session 的数据，也绝对无法访问宿主机的文件系统或网络。 - 销毁：工具执行完毕（无论成功或失败），sandbox 实例会在几秒内被彻底销毁，所有内存、临时文件、进程状态，全部清零。
这种设计带来的安全性提升是质的飞跃。我们曾遇到过一个真实案例：某金融客户的 agent 需要调用一个内部风控 API。在旧架构下，API Key 是作为环境变量注入到一个长期运行的容器里的。一次意外的print(os.environ)调试语句，就把这个 Key 泄露到了日志里，进而被日志系统索引，造成了严重的安全风险。而在 Managed Agents 的 sandbox 里，这个 Key 是由 Anthropic 的密钥管理服务（Vault）在 sandbox 启动瞬间，以加密信封的形式动态注入的。工具代码拿到的只是一个解密后的临时凭据，且 sandbox 销毁后，这个凭据的生命周期也就结束了。它从根本上杜绝了“密钥泄露”这一类最常见、也最危险的安全隐患。这不是一个功能点，而是一种安全范式的转变。
3. 实操落地：从 YAML 定义到生产部署的完整闭环
3.1 用 YAML 定义你的第一个 Agent：告别代码即配置
Managed Agents 最吸引开发者的入门体验，就是它对“代码即配置”（Code-as-Config）的极致推崇。你不需要写一行 Python 来启动一个 agent，只需要一个结构清晰的 YAML 文件。这不仅降低了上手门槛，更重要的是，它让 agent 的定义变得可版本化、可审查、可自动化部署。
下面是一个为 Notion 团队定制的、用于“会议纪要生成”的 agent 的 YAML 示例：
# agent-definition.yaml name: "notion-meeting-minutes" description: "An agent that reads a meeting transcript and generates structured minutes for Notion." # 系统提示词，定义 agent 的角色和行为准则 system_prompt: | You are a meticulous and professional meeting minute scribe. Your task is to read the provided transcript and extract: - The meeting title and date - A list of attendees (names only) - Key decisions made (with clear action items and owners) - Open questions or next steps Format your output strictly as valid JSON with these keys: {"title", "date", "attendees", "decisions", "next_steps"}. # 定义 agent 可以使用的工具 tools: - name: "read_transcript" description: "Reads the raw text content of a meeting transcript file." input_schema: type: "object" properties: file_id: type: "string" description: "The unique identifier of the transcript file in Notion." # 这个工具的执行逻辑，由 Anthropic 托管，你只需声明接口 # 具体实现是 Notion 的官方集成，无需你编写 - name: "create_notion_page" description: "Creates a new page in a specified Notion database." input_schema: type: "object" properties: database_id: type: "string" title: type: "string" content_json: type: "string" # 传入上面生成的 JSON 字符串 # 同样，这是 Notion 官方提供的、经过认证的安全集成 # 定义运行时的“护栏”（Guardrails） guardrails: # 内容安全：禁止生成任何包含个人身份信息（PII）的内容 pii_filtering: true # 工具调用限制：防止 agent 陷入无限循环调用同一个工具 max_tool_calls_per_session: 10 # 输出长度限制：避免生成过长、无意义的文本 max_output_tokens: 4096 # 可选：定义 agent 的“记忆”能力，即它能记住哪些用户信息 memory: enabled: true # 只允许记住用户在 Notion 中的公开昵称，绝不允许记住邮箱或手机号 allowed_fields: ["notion_user_name"]这个 YAML 文件，就是你 agent 的“宪法”。它清晰地定义了：
- 我是谁（
system_prompt）：一个专业的会议纪要员。 - 我能做什么（
tools）：读取 Notion 文件、创建 Notion 页面。 - 我不能做什么（
guardrails）：过滤 PII、限制调用次数。 - 我能记住什么（
memory）：仅限用户昵称。
当你把这个 YAML 文件通过 Anthropic 的 CLI 或 API 提交后，Anthropic 的后台会为你创建一个唯一的 agent ID（例如agent_abc123）。从此，任何客户端（无论是 Notion 插件、Slack Bot 还是你的内部 Web 应用），都可以通过这个 ID，向 Anthropic 的托管服务发起请求，启动一个全新的 session。整个过程，你不需要管理任何服务器、容器、负载均衡器或 TLS 证书。YAML 就是你的全部基础设施代码（IaC）。
3.2 Session 生命周期管理：从创建、交互到归档的全流程
一个 Managed Agent 的 session，并非一个简单的“对话线程”，而是一个拥有完整生命周期的、可编程的对象。理解并掌握这个生命周期，是将其投入生产的关键。
1. 创建 Session (create_session)
这是旅程的起点。你向 Anthropic 的 API 发送一个 POST 请求，附上你的 agent ID 和初始输入（例如，一个会议录音的 URL 或 Notion 文件 ID）。API 会立即返回一个session_id（如sess_xyz789）和一个session_state（通常是"active"）。此时，一个空的、结构化的 event log 就在后台创建好了，等待第一条事件的写入。
2. 与 Session 交互 (send_message)
这是最核心的操作。你向send_message端点发送消息，内容可以是：
- 用户的自然语言提问（例如，“请为这份会议记录生成纪要”）。
- 一个明确的 tool call 指令（例如，
{"tool_call": {"name": "read_transcript", "input": {"file_id": "page_123"}}}）。
harness 收到后，会解析这条消息，决定是让模型生成回复，还是触发一个工具调用。无论哪种，它都会将结果（模型输出或工具返回值）作为一条新的事件，追加到该 session 的 event log 末尾。这个过程是原子的、幂等的。即使网络抖动导致你重复发送了同一条消息，harness 也能识别出来，避免重复执行。
3. 查询 Session 状态 (get_session)
这是一个强大的调试和可观测性工具。你可以随时调用get_session，传入session_id，获取该 session 的完整快照：
- 当前的
session_state（active,completed,failed,expired）。 - 一个按时间排序的
events数组，包含了从创建至今的所有事件。 last_event_timestamp，告诉你最后一次活动是什么时候。
这个接口，是你排查问题的“时光机”。当用户反馈“我的纪要生成错了”，你不再需要翻查一堆分散的日志，只需用session_id一查，就能看到整个决策链：模型看到了什么输入？它调用了哪个工具？工具返回了什么？模型又是如何基于这个返回值做出最终判断的？一切尽在眼前。
4. 归档与清理 (archive_session)
对于已完成的 session，Anthropic 提供了archive_session接口。归档后的 session 事件日志会被移至冷存储，但仍可通过get_session查询，只是响应时间会稍长。这既满足了企业对数据留存的合规要求（例如，GDPR 的审计日志），又避免了热存储的高昂成本。你还可以设置自动归档策略，例如“所有completed状态超过 30 天的 session 自动归档”。
提示：不要手动删除 session。Managed Agents 的计费模型是基于
session-hour的活跃时长。一个 session 一旦创建，即使它处于空闲状态，也会持续计费，直到它被显式地complete或expire（默认 7 天不活动后自动过期）。因此，在你的应用逻辑里，务必在 agent 任务完成后，主动调用complete_session，这是控制成本的关键操作。
3.3 定价模型与成本优化实战：$0.08/session-hour 的精打细算
Managed Agents 的定价模型非常透明：$0.08 per session-hour of active runtime，外加标准的 Claude token 费用。这个看似简单的公式，背后藏着巨大的成本优化空间。我来分享几个在真实客户项目中验证过的实操技巧。
核心概念澄清：什么是 “session-hour”？
它不是指 session 的总存活时间，而是指 session 处于active状态下的、实际消耗 CPU 时间的总和。一个 session 可以存活数天，但如果它大部分时间都在等待用户输入（idle），这部分时间是不计费的。只有当 harness 在执行execute调用、或模型在生成 token 时，计时器才会走动。
成本优化技巧一：善用“异步”与“批处理”
假设你的 agent 需要为一个销售线索生成三份不同风格的邮件草稿（正式、亲切、简洁）。一个 naive 的做法是，让用户依次点击三个按钮，触发三次独立的 session。这会产生 3 个 session，每个 session 都要支付至少 $0.08 的起步费（因为哪怕只运行 1 秒，也按 1 小时计费）。
更优的做法是，设计一个“批处理”工具。在 YAML 中定义一个新工具generate_email_variants，它的input_schema接收一个style_list: ["formal", "friendly", "concise"]。然后，让 harness 一次性调用这个工具，它内部会并行地调用三次 Claude API，生成三份草稿，并将结果打包返回。这样，整个任务只消耗 1 个 session，成本从 $0.24 降到了 $0.08，降幅达 66%。
成本优化技巧二：精细控制max_tool_calls_per_session
Guardrails 中的max_tool_calls_per_session不仅是安全护栏，也是成本控制阀。一个失控的 agent，可能会因为逻辑错误而陷入无限循环，比如反复调用search_knowledge_base却得不到想要的答案。这会导致 session 一直active，费用直线飙升。我们将这个值设为5，意味着 agent 最多只能进行 5 次工具调用。如果 5 次后仍未完成任务，session 会自动进入failed状态并停止计费。这是一种“fail fast, fail cheap”的工程哲学。
成本优化技巧三：利用session_state进行智能降级
对于高并发、低价值的请求（例如，大量用户同时点击“帮我润色这句话”），你可以设计一个“降级”策略。当检测到系统负载过高时，你的前端应用可以主动将请求的session_state设置为low_priority。Anthropic 的后台会将这类 session 的资源配额降低，使其执行速度变慢，但依然能完成任务。这相当于用一点响应时间的牺牲，换取了整体成本的大幅下降，非常适合处理海量的、对延迟不敏感的请求。
4. 生产级挑战与避坑指南：那些文档里不会写的血泪教训
4.1 “Context Overflow” 的幽灵并未消失，只是换了个地方
虽然 Managed Agents 解决了“上下文窗口溢出”这个经典问题，但一个新的、更隐蔽的“溢出”风险悄然浮现：Event Log Size Overflow。
是的，event log 本身也是有大小限制的。Anthropic 的文档里没有明说这个上限，但根据我们压测的经验，一个 session 的 event log 总大小（所有事件的 JSON 字符串之和）最好不要超过 10MB。一旦接近这个阈值，send_message的响应时间会急剧增加，甚至出现超时。
问题场景：一个用于“法律合同审查”的 agent，需要处理一份长达 200 页的 PDF。它会先调用extract_pdf_text工具，这个工具返回的纯文本可能就高达 5MB。紧接着，agent 又调用analyze_clause工具，对其中的 50 个关键条款逐一分析，每个分析结果又返回 10KB 的 JSON。很快，event log 就突破了临界点。
解决方案：我们必须在工具设计层面就进行“日志瘦身”。对于extract_pdf_text这类会产生巨量输出的工具，我们修改了其input_schema，增加了max_chars参数。默认情况下，它只返回前 5000 个字符的摘要，以及一个full_text_available: true的标志。只有当 agent 的后续逻辑明确需要全文时（例如，analyze_clause的输入中指定了text_source: "full"），它才会触发第二次调用，专门获取完整文本。这样，90% 的常规分析任务，event log 都能保持在健康范围内。
注意：永远不要在
system_prompt里要求模型“请将你看到的所有输入都原样复述一遍”。这会直接把巨大的输入文本塞进 event log，是成本和性能的双重杀手。
4.2 Credential Vault 的“双刃剑”：便利性与灵活性的权衡
Credential Vault 是 Managed Agents 的一大亮点，但它也带来了一个现实的工程约束：所有工具的凭证，必须在 agent 定义阶段就静态声明。你无法在运行时，根据用户的不同，动态地切换数据库连接字符串或 API Key。
问题场景：一个 SaaS 应用，其客户 A 使用 PostgreSQL，客户 B 使用 MySQL。你的 agent 需要为不同客户查询其专属数据库。按照 Vault 的设计，你必须为每个客户都预先创建一个独立的 agent 实例（agent_customer_a,agent_customer_b），并在各自的 YAML 中硬编码对应的数据库连接信息。这导致 agent 的数量与客户数量呈线性增长，管理成本爆炸。
解决方案：我们采用了“Vault + 中间件”的混合模式。我们创建了一个通用的、名为query_customer_database的工具。它的input_schema包含customer_id和sql_query。这个工具的后端代码，是一个轻量级的 Go 服务。它收到请求后，首先根据customer_id，从我们自己的、经过 HIPAA 认证的密钥管理服务（HashiCorp Vault）中，动态拉取该客户的数据库凭证，然后才执行 SQL 查询。这样，我们只需要维护一个通用的 agent，而将复杂的、多租户的凭证管理，下沉到了我们可控的中间件层。Vault 依然保护了凭证不被 agent 代码直接读取，而灵活性则得到了保障。
4.3 “Sandbox Spin-up Time”：毫秒级延迟背后的魔鬼细节
Anthropic 宣称 sandbox 的启动时间是“sub-90ms”，这在实验室环境下是真实的。但在生产环境中，我们观测到，首次调用一个新工具时，平均延迟会飙升到 300-500ms。这是因为，第一次调用会触发 sandbox 镜像的拉取和初始化，这是一个 I/O 密集型操作。
问题场景：一个实时聊天机器人，用户期望在 1 秒内得到回复。如果 agent 的第一步就是调用一个新工具，这额外的 400ms 延迟，会让用户体验大打折扣。
解决方案：我们实施了“sandbox 预热”（sandbox warm-up）策略。在 agent 服务启动时，我们的后台会并发地、静默地调用所有已注册工具的execute方法，传入一个空的、无副作用的input（例如{"dry_run": true}）。这会强制 Anthropic 的后台为每个工具都预热一个 sandbox 实例池。当真实用户请求到来时，harness 可以直接从池中“借”一个已就绪的 sandbox，将延迟稳定在 90ms 以内。这个策略需要你付出一点额外的、固定的后台资源开销，但换来的是极致的、可预测的用户体验。
5. 竞争格局与未来演进：为什么 runtime 层注定走向“零价化”
5.1 Hyperscaler 的碾压式入场：AWS AgentCore 的启示
Anthropic 的 Managed Agents 发布时，媒体焦点都集中在它身上，但一个被广泛忽视的事实是：AWS Bedrock AgentCore 已经在五个月前（2025年11月）进入了全面可用（GA）阶段。这不是一个概念验证，而是一个已经承载了数百万次生产调用的、成熟的平台。
AgentCore 的核心竞争力，不在于它比 Anthropic 更先进，而在于它“免费”且“无处不在”。它的定价模型是：完全免费。你只需为你在 Bedrock 上调用的模型（Claude、Llama、Cohere 等）付费，AgentCore 的 runtime 本身不收取任何额外费用。对于一个已经在 AWS 上花费数百万美元的企业客户来说，选择 AgentCore 意味着零边际成本的 agent 运行时。采购部门不会为一个“免费”的东西开一张新的 PO，这极大地加速了 adoption。
更关键的是，AgentCore 的架构是“框架无关”的。它不强迫你使用 AWS 的特定 SDK。LangGraph、CrewAI、甚至你手写的 Python 脚本，只要能遵循一个简单的 request-response 协议（接收一个 JSON 输入，返回一个 JSON 输出），就可以被 AgentCore 托管。这打破了 vendor lock-in 的壁垒。一个客户今天用 AgentCore 托管一个 Claude agent，明天就可以无缝切换到托管一个 Llama agent，而无需重构任何 infrastructure 代码。
这正是 Anthropic 所面临的“防御性困境”。他们不是在开创一个新市场，而是在保卫一个即将被免费化、标准化的基础设施层。他们的 Managed Agents，本质上是一个“Claude 专属”的 runtime。它的最大价值，是确保那些已经为 Claude 付费的客户，不会轻易地把 agent 的运行时迁移到 AWS 或 GCP 上，从而带走他们宝贵的 token 收入。这是一种精明的商业护城河，但并非一个不可逾越的技术护城河。
5.2 开源生态的闪电战：Daytona 与 Kubernetes SIG 的崛起
如果说 hyperscaler 是“自上而下”的免费化压力，那么开源社区则是“自下而上”的颠覆性力量。2025 年初，一个名为 Daytona 的项目，从一个 DevOps 工具提供商，华丽转身为 AI agent 基础设施的领导者。它在 2025 年 2 月完成了 2400 万美元的 A 轮融资，并公开宣称其 sandbox spin-up time 为 “<90ms”，与 Anthropic 的宣传旗鼓相当。
Daytona 的厉害之处，在于它把 agent runtime 的核心能力，封装成了一个可以一键部署到你自有 Kubernetes 集群上的 Operator。这意味着，你可以在自己的私有云、甚至本地数据中心里，运行一个与 Anthropic 功能几乎一致的托管 runtime。它的 YAML 定义格式、event log API、甚至execute接口，都刻意设计得与主流云厂商兼容。这给了企业客户前所未有的控制力和数据主权。
更令人震撼的是，Kubernetes 社区本身也在行动。Kubernetes SIG（Special Interest Group）在 2025 年底，正式发布了k8s-agent-sandbox项目。这是一个官方的、符合 OCI（Open Container Initiative）标准的 sandbox 运行时。它不是一个完整的 agent 平台，而是一个纯粹的、可插拔的“沙箱引擎”。任何 agent 框架（LangChain、LlamaIndex）都可以通过一个标准的 CRI（Container Runtime Interface）插件，将它的工具调用，无缝地卸载到这个 k8s-native 的 sandbox 中执行。
这标志着一个新时代的到来：agent runtime 正在成为云原生基础设施的“标准组件”，就像 containerd 或 CNI 插件一样。它不再是一个需要单独采购、单独运维的“产品”，而是像网络或存储一样，成为你 Kubernetes 集群的“基础能力”。当一项技术成为基础设施的“默认选项”时，它的价格就必然趋向于零。Anthropic 的 $0.08/session-hour，或许在今天看起来合理，但放在 Kubernetes 集群里，它可能只是一行kubectl apply -f agent-runtime.yaml的成本。
5.3 价值迁移的三大高地：Trace、Governance、Vertical
当 runtime 层不可避免地走向 commoditization（商品化），价值必然会向上迁移。历史已经无数次证明了这一点：当虚拟化（VMware）变成免费的基础设施，价值就迁移到了上层的 Kubernetes（容器编排）和 Terraform（基础设施即代码）；当数据库成为云服务，价值就迁移到了上层的 Data Mesh（数据网格）和 Feature Store（特征仓库）。
在 agent 领域，价值迁移的三大高地已经清晰可见：
第一高地：Trace Store（追踪存储）
谁拥有了 agent 行为的“唯一真相源”（Single Source of Truth），谁就拥有了无可替代的价值。目前，Braintrust、Arize 和 LangSmith 三家正在激烈角逐。它们的竞争，不是比谁的 UI 更好看，而是比谁的 trace 数据模型更开放、更易于迁移。一个企业客户，绝不愿意因为更换了 agent runtime（从 Anthropic 换到 AgentCore），就必须重写所有监控告警规则、重做所有数据分析报表。因此，“trace portability” 成为了终极胜负手。谁能提供一个标准的、跨平台的 trace export/import API，谁就能赢得这场战争。
第二高地：Governance & Policy（治理与策略）
当 agent 开始在企业内部承担真实业务职责（如审批采购单、生成财务报告），合规性就成了生死线。AWS AgentCore 在 2026 年 3 月 GA 的 Policy Controls，就是一个信号。它允许管理员定义：“这个 agent 只能调用read_salesforce工具，且只能读取Opportunity对象，且不能访问Account的credit_score字段。” 这种细粒度的、基于属性的访问控制（ABAC），是 enterprise-grade 的刚需。目前，这个领域尚无公认的领导者，但 OWASP Agentic Top 10 的发布，已经为整个行业划定了安全红线。下一个季度，你一定会看到多家初创公司宣布推出“Agentic Governance Platform”。
第三高地：Vertical Agent Marketplaces（垂直领域 agent 市场）
Salesforce 的 Agentforce 在 2026 年 Q4 达到了 8 亿美元的 ARR，这是一个里程碑式的数字。它证明了一件事：企业愿意为一个能解决其具体业务问题的 agent 付费，而不是为一个通用的、能做任何事的 runtime 付费。未来的赢家，将是那些深耕于特定行业的公司：为医院构建“医保报销 agent”，为律所构建“合同漏洞扫描 agent”，为银行构建“反洗钱 agent”。这些 agent 的核心价值，不在于它运行在哪个 runtime 上，而在于它内置的、经过千锤百炼的行业知识、法规逻辑和最佳实践。开源社区已经在行动，ai-hedge-fund和pentagi这些项目，就是未来垂直市场的雏形。它们的成功，不取决于技术有多炫酷，而取决于能否在一个具体的、高价值的业务场景里，做到“比人类专家更快、更准、更便宜”。
我个人在实际操作中的体会是，与其把精力耗费在争论“哪家的 runtime 更快”，不如沉下心来，思考你的 agent 真正要解决的那个“最后一公里”的业务问题。Runtime 是水和电，而你的 agent，才是那个能创造真实价值的“电器”。当水电的价格趋近于零时，决定你成败的，永远是你电器的设计、制造和营销能力。
