Agent Infra 毫无疑问是当前 VC 投资的热点，我自己其实也在下注，但是可能和普通 VC 不一样的点是，我是一个 Infra 的用户和开发者，今天从这个视角来分析一下，当我们在聊 Agent infra 的时候，我们到底在聊什么。（没错，这个标题就是在致敬 Raymond Carver，他的 What We Talk About When We Talk About Love 是我心目中最好的短篇小说集合之一，不过这篇文章的内容真的是一点关系都没有。。。。哈哈哈）

首先区别广义的 AI Infra，无论是 Pre Train 和 Post Train RL 和 Inference Infra，这些都不是本文讨论的范围，而且我对这些 Infra 没啥兴趣，因为大多都是为广义上的训练服务（不管是 Pretrain 还是 RL），而且模型训练大多是一次性的工作，很多脚手架只能是针对一次或一代模型使用，而 Inference Infra 的同质化程度又太高，在产品层面能玩的不太多。今天我们看到 Agent 开始接管越来越多的工作以后，我认为在 Agent 层面还会出现一个全新的 Infra 层，比 Inference Infra 更靠上，作为一个 Runtime 层支持 Agent 和 Agents 的工作。

先快速对齐一下今天大家大致默认的 Agent 架构形态：

一个典型的 Agent 系统，通常包含以下几个组件：

LLM / Reasoning Core

负责理解上下文、生成计划（Plan）、决定下一步行动（Action）。

Planner / Executor

将一个复杂目标拆解为多个步骤，并逐步执行。

Tools / Skills

外部能力的封装，例如：调用 API、执行代码、访问数据库、浏览网页。

Memory / Context Store

用于保存中间状态、历史行为、长期偏好等。

Env（往往是隐式的）

执行 Action 所依赖的真实世界或虚拟世界。

这些组件在一个 Loop （Agentic Loop）的驱动下持续迭代工作，这就是今天几乎所有 Agent 的大体架构。

当前这个架构有一些问题：

顺序执行和简单协作，是复杂任务的天然瓶颈

这个问题我在之前的文章中提过。

哪怕 Plan 制定得非常完美，大多数 Agent 的执行模型依然是：一步 → 等结果 → 再一步

这是一个高度顺序化的执行模型（哪怕是一些 Agent 已经开始采用 Sub Agent 分发任务的模式，但是仍然在一个很小的规模下），其问题非常明显：

行动之间依赖极强，几乎无法并行

任意一步失败都会阻塞整体路径

在探索型任务中效率极低

我有个强烈的直觉：对于真正复杂的任务来说，探索（或者说大规模的探索和实验）是必不可少的。

举个例子，我在 Coding Agent 的工作流优化方向上，我的目标是让 Coding Agent 能够尽可能长时间地在无人工干扰的情况下工作。但是你又不能让它干无意义的事情，因此，一个很重要的手段就是让 Agent 在各种可能性之间不停地尝试、总结并持续改进。如果这种探索型的尝试的效率低，整体的效率和质量就不太行。

Agent 与 Agent 协作机制的局限

我们已经看到很多 Agent 通信协议、协作框架、Multi-Agent 方案，MCP 和 A2A 都是例子，但是都不太成功。目前的 Agent 协作，更像是几个 Agent 勉强能对话，但这种程度离我想要的“协同”还差得很远。我当然知道现在有人在推 A2A 这类方向。理念大家都懂，也都觉得对。

Agent 之间可以互相协作，可以互相委派任务，可以互相汇报进展。问题在于，协议本身离真正可用的系统还差一层很关键的东西。A2A 更像是在告诉你“应该这样做”，但它没有把“怎么在平台上把它做出来”这件事讲清楚，当然了目前也没有一个好用的平台。

长程任务带来的环境劣化

还有一个我认为有一个特别重要、但目前被严重低估的问题：

如果你不能提供一些原子的、无副作用的 Action，那么在执行复杂任务的过程中，环境一定会随着执行不断变差。

这个问题在简单 Demo 中不明显，但在任何长链路、复杂编排、多步骤探索的任务中，几乎是必然发生的。

因为当前大多数当前复杂任务涉及的 Action，实际上都具有强副作用（Side Effect）当你执行第一个 Action 时，环境已经被“污染”了，

当你执行第二、第三、第四个 Action 时，状态开始相互叠加，错误无法被彻底清理，失败路径与成功路径纠缠在一起，于是最终的结果是 Agent 已经不知道当前环境到底处在什么状态。这时候，哪怕你的 Planer 再聪明、推理能力再强，Agent 也只能在一个不断恶化的环境中做选择。

这个问题在 Coding Agent 上已经非常明显了。

只要你把它们放进一个真实的大型代码仓库，很快就会遇到熟悉的情况：工作区被迅速搞乱。生成一堆 Markdown、用不同风格加日志、引入临时代码却忘了清理，多个 Sub-agent 在同一个工作区反复覆盖彼此的修改。

这就是一个典型的环境劣化问题。

工程师们其实已经在用一种很朴素的方式局部解决它：Git Worktree。

为每个 Sub-agent 创建独立的 Worktree，让它在一个最小隔离的代码环境里完成任务，最终只通过 diff 或 PR 回收结果。本质上，这是在用最低成本为 Action 提供一个可隔离、可丢弃的执行环境。

这个方式已经非常接近答案，只是它既没法规模化，也没法泛化。

缺乏完成到物理世界“最后一公里”的能力

从表面上看，现在的 Agent 能力已经很强了。但是面临一些没有明显 API 的工作，仍然力不从心，你试着让 Agent 去完成一件对现实世界产生实际影响的事情，比如下单、支付、预订酒店，整个体验就会突然变得非常脆弱。

Skill 是一个很好的抽象，我非常喜欢，在很多纯软件场景里，它已经足够好用了，但只要事情开始碰到物理世界，skill 这个抽象的边界就会变得非常明显。现实世界充满了隐式状态。登录态、权限、风控、页面变化、临时校验、失败重试，这些东西在人类眼里都很熟悉，但它们很少被系统性地封装成一个干净的执行模型。结果就是，Agent 每往前走一步，都会在环境里留下痕迹，而这些痕迹又会反过来影响后面的计划。

我觉得下一步，很快 Skill 的定义能够突破软件和开发场景，变成：“买菜 Skill” “买咖啡 Skill”，这样真正的类似 Cluade Cowork 产品才能发挥更大的价值。

一些可能的解法

Skill + Env = Box

其实上面提到的种种问题，我有种似曾相识的感觉，这个在过去 10年 DevOps 和云计算领域其实有很类似的问题，因为那个时候是从单机服务跨向更大规模的分布式架构的时间点。

早期的软件系统同样跑不稳，同样难以复现问题，同样依赖大量隐式环境状态。单机上的问题总是好解决，但是一旦扩展到 1000 台机器，状态爆炸的问题就变得很致命。

当时在早期大家也经常把注意力放在“人”的问题上：是不是流程不够规范，是不是操作不够小心，是不是文档没写清楚。但慢慢地大家才意识到，问题并不在于工程师有没有按步骤来，而在于系统本身没有给人一个稳定的执行基础。

后来发生的事情我们都很熟了。容器、不可变基础设施、IaC、声明式配置，这些东西并没有让软件变得更聪明，但它们让环境变得更可控了。失败变成了一次可以被复现的失败，部署变成了一次可以被重复（幂等）的操作。

我现在看 Agent Infra 的很多困境，感觉非常接近当年的状态。Agent 并不是真的不知道该做什么，它只是被迫在一个不稳定、不可预测的执行环境里反复尝试。

于是第一个建议就是，Skill 应该和环境绑定在一起，提供一种新的抽象，也许叫做 Box（我随便起个名字）？Box 不暴露执行细节，不应该有任何依赖，没有任何副作用，它提供的是：Skill 指导下的 Action + 可复现、可丢弃的执行环境。

Box 解决的是单环境内的执行质量。Box 因为以 Skill 为描述，所以天然是可以被继承和叠加的。我举个简单的例子，比如“帮我去买咖啡”这么一个简单的任务，其实可以分解成几个原子 Skill 的结合：

基础 Skill：启动浏览器 -> Box1
第二个 Skill：登录我的账号 -> Box2
第三个 Skill：下单买咖啡 -> Box3
这几个叠加的 Skill 会形成一个叫做买咖啡的 Box，甚至前两个 Box 其实可以被 Cached。 Claude 只需要写一行代码:
box3 = box1 + box2
box3.spawn().buy_coffee('latte')
box3 买完咖啡后就销毁，于是就能稳定完成买咖啡的任务，而不会对当前你的本地环境造成污染。
区别于 Docker ，box 提供的环境是纯的，更轻量的，不会暴露任何技术细节，一切与上层沟通的接口都是语义化的。
我觉得这个思路能够解决当今 Coding Agent 的“最后一公里”问题。它不仅仅能用来编程，还能够填补通过代码对现实世界产生真实影响的这个 Gap。尤其是在与现实世界产生交互的动作里，类似上面“帮我买杯咖啡”或者“帮我查询并预订某地最便宜的酒店”这种操作，指望有 API 是不现实的。而 Box 的封装就是把物理世界代码化的尝试。当我们大量这样的 Box Function 后，对物理世界编程其实就是当今 Agent 最擅长的事情了。
其实社区里一些最前沿的创业团队已经出现了类似的尝试，例如 https://github.com/boxlite-ai/boxlite 和 https://github.com/vm0-ai/vm0 都是个典型的例子。

Agents 的 "Kubernetes"？

如果每一个 Action 都被包进一个可复现、可丢弃的执行单元（Box）里，那么系统接下来最自然的需求就是：谁来创建这些单元，谁来调度它们，谁来监控它们的状态，谁来决定失败之后是重试、放弃，还是换一条路径。

答案也是从云计算里来，大规模的容器调度的事实标准是 K8s，那么给 Agents 用的 K8s 会是什么样子呢？

我认为是独立于模型的一套基础设施服务：

1. Context Manager：由分布式数据库和分布式文件系统构成，数据库提供的结构化上下文的共享和管理（如对话历史等），用于构建的 prompt。分布式文件系统提供 co-working space，配合 agent 的本地工作区使用。

2. Branching：Branching 成为一等能力，这里的 Branching，和传统意义上的 Git Worktree 和分支已经不完全是一回事了。它更像是一种系统级能力，用来描述任务执行过程中的不同可能性。你可以为同一个目标同时展开多条路径，让不同的 Agent 或同一个 Agent 在不同环境里各自推进。它们共享目标，但不共享副作用。这个 Branching 由数据库（管理元信息）和支持分支的文件系统提供底层能力。

3. 网络内的 Messaging Hub / Communication Service：这个能力会被嵌入在每个 Box runtime 中成为系统假设的一部分。提供类似这样的能力：

box1.send_message(box2, 'hello')

和

box1.publish_event('buy_coffee_success'); box2.on_event('buy_coffee_success', on_success)

3. Scheduler + Lifecycle Manager：它做的事情很朴素：每一个任务被拆成很多可执行单元之后，系统要负责把它们分发到哪里跑、并发度怎么控制、失败怎么处理、超时怎么处理、什么时候该取消、什么时候该重试。容器世界里这些都是 K8s 的日常，Agent 世界里现在大多还在框架层硬写逻辑，结果就是每家都在重复造轮子，而且稳定性差异非常大。

4. Box runtime：上面提到过，我就不赘述了。

写到这里差不多了，其实我觉得当下不太需要再强调模型会变得多聪明。真正决定 Agent 能否承担复杂任务的，更多取决于执行是否可控，失败是否廉价，环境是否可替换，以及协作是否有基础设施兜底。

Agent Infra 的很多问题，并不是第一次出现。它们已经在其他领域被反复遇到过，也被部分解决过。现在需要做的，是把我这些经验重新组织起来，放到 Agent 这个新的上下文（Runtime）层里。

文章来源：我世界的源码