前几天面试，和一位做中间件出身的面试官就 Agent 相关的问题聊了很久收获很多。面试本身的八股问题可以说是没有，更多的是面试官愿意和我交流，未来的 Agent 何为用户提供服务需要什么样的系统架构。回头复盘，同时也是受到面试官的启发，我将自己的思路整理成了两条串起来的主线：框架是怎么演进的，运行时环境又是怎么演进的。
框架主线：从「编排工作流」到「模型 + 工具」
LangChain 最开始其实是一个 workflow 形态的东西：在端到端的流程里编排一个工作流，AI 在其中起一部分作用。这个概念在当时是成立、也合理的。因为 LLM 的能力还没有那么强，需要一个固定的流程来控制整个 job 的输出结果是可用的。“如何约束 LLM 输出 JSON”、“如何处理幻觉”、“Prompt Engineering” 等问题都是两年前的显学，本质是因为模型推理没有达到生产所必需的智能。这种智能不是输出一些文本和没有正确答案的内容的“聊天智能”，而是“工作的智能”、“生产的智能”。GPT 的第一形态是 ChatBot，Agent 是自然发展的需要。
但随着模型能力往上走，「先定义好一条工作流」这个前提本身开始站不住了。于是有了 LangGraph——它把底层执行换成了一个有向无环图（DAG），图上有一堆执行节点，用编码的方式决定「这个节点之后该走哪个节点」，也就是一个路由函数。框架的设计者们提出了了一套关于 Node、Edge、State 的概念，认为在生产环境中还是需要有复杂的预先编排与处理，同时通过更加自然的 event publish 模式来输出底层 Runtime Framework 的运行时事件以供应用开发者消费。可等到 Agent 真正发展起来，Node 的定义是多余的，一切都关于 LLM 和 Tool。于是 LangGraph 的封装版本 DeepAgents：它把结构收敛成两类节点——一个 model node 负责和模型交互，一个 tool node 负责工具调用，middleware 负责处理模型和工具的中间环节。走到这一步，其实是在承认一件事：
简单自然的演化胜过了预先定义的理念。
与此同时，另一条技术路线从最开始就走得很克制，比如 Pi（earendil-works/pi）：它的核心同样是「模型 + 工具」——一个带工具调用和状态管理的 Agent runtime。但它的交互被做成了 Publish / Listener 的事件模型：agent 生命周期、每一轮 turn、每一条 message、每一次工具执行，都作为 AgentEvent 事件发布出去，任何代码都可以 subscribe 订阅；同时 beforeToolCall / afterToolCall 这类 middleware 钩子给了 Plugin、Extension 消费和改写这些事件的入口。因为「消费事件」这件事谁都可以做，扩展就变得非常自然、非常轻。
这两条路线，一条从「编排」一路做减法减到「模型 + 工具」，一条从一开始就是「模型 + 工具」。殊途同归。
从 Plugin / Extension 的角度看
如果再从 Plugin / Extension 的角度横向比一下，LangGraph、Pi、DeepSeek Harness 这三家的设计理念其实各不相同，开放程度依次变高。
-
LangGraph 的扩展方式是「往图里加节点」：Node / Edge / State 这套范式是固定的，开发者要做的扩展是定义自己的节点、边、状态，然后交给图执行器去跑。它的开放是「在既定结构里填空」，但结构本身换不掉。
-
Pi 又往前走了一步：它把运行过程拆成一串事件（
AgentEvent，覆盖 agent / turn / message / tool 各生命周期），并提供subscribe和beforeToolCall/afterToolCall这类 middleware 钩子。扩展不再是「填节点」，而是「订阅事件、在工具调用前后插手」，扩展点从结构变成了事件流。 -
DeepSeek Harness（
dsh） 则把「一切都是插件」推到了极致：它基于 Cordis（设计见 A Programming Paradigm for Spatiotemporal Composability），模型适配器、工具注册表、会话日志、甚至 agent loop 本身都是插件，都能从配置里替换；没有需要去 patch 的特权核心——任何插件都是「挂载在其它插件旁边」，注册是一种会在卸载时自动回卷的 effect。扩展不再局限于「找钩子」，而是「换掉任意一块」。
三者从「结构化的图」，到「事件流 + 钩子」，再到「一切都是可替换的插件」，开放程度一路升高，也对应着各自对「模型 + 工具」这个本质的抽象深度不一样。
运行时主线：从进程到 microVM 沙箱
framework 的设计理念在做减法，但是 Runtime 的理念却一直在做加法。这里的 Runtime 我讲的并不是 framework 中执行引擎或者底层框架的意思，而是 Agent 真正运行所处的外部环境。
最开始的运行环境就是一个进程，大多是嵌入在一个 Web 服务器中。这个路线对于 Agent 有非常强的控制能力，因为所有的 Tool 调用都是应用开发者主动提供的。模型输出的是指令，需要应用层去做执行。控制能力强也就意味着：工具能力本身要花大量开发，没法复用。每加一个符号，就得写代码去实现那个符号真正能干什么。
另一个路线的思路是：我们已经有软件开发所必需的一切——“文件系统”。那干脆把运行环境直接放进个人电脑里（Windows、Linux 都行），工具抽象简化成三件事——read、write、bash。能读写和操作，这个简单的抽象却有极强的生命力，Claude Code 这一波「跑在个人电脑里的 agent」就是这么来的。但问题也随之而来：这样的路线对安全、隔离的掌控是不够的。模型天然存在不安全性——它可能意识不到执行某条命令、某个脚本的危害，把工作目录删了、把数据弄丢了，事后才「抱歉，我不该这么做」。Claude Code 等 Agent 也有自己的解决方案，比如人工审批、小模型分类 Auto Approve 等等……但是这个根本性的问题没有办法解决，我们一边尝到了文件系统的甜头，一边又意识到它有明确的不足。
Manus：把 Agent 装进云端个人电脑
以我个人的视角来看，Manus 确实是走在时代的前沿。用 Web 版的 ChatGPT 或者其它 AI 应用时，能明显意识到这个 session 的背后是一个可以执行操作的环境——它能执行代码、做 PPT。而这正是 Manus 最初的设计理念：一个云端的个人电脑里，住着一个 Agent。和 Hermes、OpenClaw 这些常驻 Agent 不同，Manus 显然不可能给每个用户分配一台真正的主机，所以他们选择了虚拟化技术。
Manus 把这台「云端个人电脑」叫做 Manus Sandbox——每个任务分配一台完全隔离的云虚拟机，各自独立、互不影响、可以并行执行，具备完整的网络、文件系统、浏览器和各种软件工具能力。隔离上走的是 Zero Trust：一个沙箱里的任何操作（哪怕拿到 root、改系统文件、格式化磁盘）都只影响这个沙箱自己，不会波及 Manus 服务或其它任务。生命周期是「按需创建 → 空闲休眠 → 到期回收」：休眠/唤醒之间文件保持不变，回收后再按需重建，并自动恢复 artifacts、上传的附件和 Slides/WebDev 等重要文件，中间产物和临时文件则不保留。
真正把这套东西撑起来的，是背后的虚拟化平台。具体到实现，就是 Firecracker 这类基于 KVM 的 microVM：每个沙箱一个极小的虚拟机，启动快、开销低，却保留了硬件虚拟化级别的强隔离。这正是前面运行时主线里说的那个方向——不是给每个用户一台真主机，而是用虚拟化把「一台完整电脑」的能力切给每一个 Agent。
我眼中的未来
把 harness 只当成 framework，能争的只是设计理念；但 harness 的本质是 Agent 的运行时，它必然深入到底层系统。虚拟化、工作空间保存/拉起、细粒度安全，是单个 Agent 的基座；调度与扩容，是应用规模的基座。这两层是工程能力、是入场券，会随标准化而贬值；Agent 应用真正的壁垒，在深入行业——那里会随数据和 know-how 复利。因为我们最终是要解决现实世界的真正问题，而非只是用一个 fancy 的 demo 自我安慰。
参考
磊叔（我的面试官）和我讨论了许多的问题，他们聚焦的是能源电力的智能制造，推荐关注：磊叔的技术博客