Agent需要它的Node.js时刻
2026-06-07
阅读需要13分钟
我们不需要更多 Agent Demo，我们需要 Agent Infrastructure。
我认为，我们现在仍然缺少真正属于 agent 的基础设施层。
不是另一个 SDK。
不是另一个模型 API 的包装器。
也不是另一个看起来能火一周、但很快就无法扩展的 demo。
我说的是那种真正能让 agent 变得可迁移、可组合、可观测、可定制，并且能够作为长期运行的软件系统真正发挥作用的基础设施层。
我认为，当前的 agent 生态还没有真正构建出这一层。
这也是我开始构建 Praxis 的原因。
让我慢慢解释。
*从 LLM 到真实工作
2022 年底，GPT-3.5 的发布让世界第一次清楚地看到：LLM 不再只是躺在大型 AI 实验室里的研究产物。
它们开始进入真实工作。
Transformer 不再只是为了论文和 benchmark 烧预算的机器。通过后训练、指令微调、RLHF、工具使用，以及后来更复杂的对齐方式，它开始展现出一种更重要的能力：
实际工程能力。
从 2023 年开始，我开始关注 LangChain、LangGraph，以及早期那一波 agent framework。
当时的想法很简单，甚至有点天真：
LLM 不应该只是生成语言。
它应该完成工作。
它应该能够调用工具、管理状态、处理上下文、和 API 交互，并最终像 agent 一样行动。
这个方向错了吗？
没有。
方向是对的。
但我不认为早期那一波“agent”浪潮是真正的革命。
当时大多数东西仍然建立在简单 tool call、轻量级编排，以及对模型调用的浅层抽象之上。它们想象的是这样一个世界：只要给 LLM 包上一些工具，再套一个 graph，软件工作就能突然变得自主。
这还不够。
那更像是未来的一张草图，而不是未来真正的地基。
*Cursor 让转变感真实可见
真正改变开发者对 AI 体感的东西，不是 LangChain。
不是 RAG。
不是知识库。
不是提示词工程。
对开发者来说，真正让这种变化变得具体的产品，是 Cursor。
我自己就是一名开发者。2024 年上半年，我还在琢磨如何更好地使用 Copilot 的 tab 补全。
然后我第一次用了 Cursor。
那一刻，抽象层变了。
在 Cursor 之前，AI coding 更像是一种辅助。
在 Cursor 之后，它开始像是一种新的开发环境。
当时，Sonnet 3.5 站在 coding 能力的前沿。它很贵，缓存机制也还不成熟，经济性非常痛苦。但它的能力已经真实到足以让开发者愿意围绕它重组自己的工作流。
人们开始用模型生成结构化代码，然后把这些代码放在本地机器、沙箱或者 VM 里运行。
更多代码数据进入训练循环。
模型变得更擅长生成代码。
开发者变得更依赖模型。
这种依赖又产生了更多使用、更多轨迹、更多反馈，以及更多高质量数据。
然后 coding agent 再次变强。
这才是关键循环。
重点不只是“LLM 会写代码”。
真正重要的是，coding 成为了最早让模型能力、用户行为、产品工作流和数据生成互相强化的领域之一。
这也是为什么 coding 会成为 agent 的第一个严肃应用层。
这是必然的吗？
我不认为是。
当时 GPT 仍然在努力提升通用对话能力，并探索 o1 这种 chain-of-thought 方向的新推理方法。
Gemini 在一段时间内，在代码生成上仍然显得不稳定。
而 Anthropic 很早就发现了开发者市场。
Sonnet 3.5 在 coding 上有明显潜力，于是 Anthropic 开始沿着这个方向用力推进。
这种商业驱动非常重要。
我知道很多人喜欢把“纯技术”和商业分开谈，但事实很简单：
钱会流向那些有用到足以让人付费的东西。
这并不会让技术本身变得不真实。
事实上，如果没有这种商业压力，我们大概率不会看到今天 coding model、coding agent 和开发者工具如此快速地进步。
*当 Demo 被误认为基础设施时，泡沫就开始了
回看 2025 和 2026，我认为 agent 生态也有点过度沉迷于 demo 了。
很多项目在 GitHub、视频或者发布帖里看起来都很惊艳。
OpenClaw、Hermes，以及很多类似项目，都有同一个问题：
它们展示了什么是可能的，但不一定展示了什么是可维护的。
demo 证明的是模型可以做成某件事一次。
system 证明的是开发者可以反复在它之上构建。
这两件事完全不同。
在我看来，这就是泡沫开始的地方。
不是因为 agent 是假的。
agent 不是假的。
泡沫开始于我们把 demo 误认为基础设施。
要理解缺失的东西，我们可以往回看。
在 2000 年代早期，软件开发也有类似的问题。
开发者在构建各种各样的应用，但底层基础并不成熟。
每个项目都要和平台搏斗。
操作系统不同。
浏览器不同。
硬件不同。
部署很痛苦。
兼容性很痛苦。
在成熟的框架和 runtime 出现之前，即使是简单应用，开发者也必须自己构建太多外围机械结构。
然后生态开始变化。
Node.js 让 JavaScript 在浏览器之外拥有了严肃 runtime。
React 改变了人们对 UI 组合的理解。
Electron 让跨平台桌面应用变得更容易交付。
后来，Next.js 这样的框架让全栈 web 开发变得更快、更结构化。
这些技术完美吗？
不完美。
它们在每个细节上都是神圣而开创性的吗？
也不是。
但它们解决了真实问题。
它们给了开发者一个地基。
这才是历史重点。
真正的突破不是每个开发者突然都变聪明了。
真正的突破是 infra 变好了。
当 infra 帮开发者处理更多底层工作，开发者就能在应用层跑得更快。
他们不再需要为每个项目重复重建同一套地基。
这正是今天 agent development 缺少的东西。
agent 需要自己的 Node.js 时刻。
agent 需要自己的 React 时刻。
agent 需要自己的 runtime 时刻。
*Agent 不是Harness工程+调用，它是软件系统工程
现在，如果你想构建一个严肃的 agent 系统，你会被迫自己拼装太多基础部件。
假设你想做一个类似 Codex 的东西，并且假设 Codex 还不存在。
你需要什么？
你需要一个执行核心。
你需要沙箱。
你需要上下文管理。
你需要 tool call。
你需要 session 治理。
你需要缓存管理。
你需要适配 OpenAI、Anthropic、Gemini、DeepSeek、本地模型，以及未来出现的各种模型供应商。
你需要 MCP 支持。
你需要插件系统。
你需要 skill。
你需要 policy。
你需要事件流。
你需要日志。
你需要记忆。
你需要压缩。
你需要 workspace 管理。
你需要安全边界。
你需要可观测性。
你需要前端抽象。
你需要 runtime。
这不是一小块工作。
而且其中大部分都不应该是 application code。
它们应该是 infra。
今天，很多厂商对这个问题的回答是发布 SDK。
Claude SDK。
OpenAI Agent SDK。
Cursor 相关的 SDK。
OpenCode 式的抽象。
各种 framework wrapper。
这些东西有用，但我不认为它们足够。
原因很简单：
它们仍然太贴近平台，而不够贴近 agent 的底层基质。
它们帮助你使用一个产品。
但它们不一定帮助你拥有一个系统。
而 ownership 很重要。
如果你的 agent 深度绑定在某一家模型供应商的 SDK 上，那么当另一家供应商变得更强时，你怎么办？
如果 Gemini 在某类任务上变得更强，你怎么办？
如果 GPT 在另一类任务上更强，你怎么办？
如果本地模型已经足够处理敏感内部任务，你怎么办？
如果你的缓存策略需要改变，你怎么办？
如果你的工具层从 5 个工具增长到 500 个工具，你怎么办？
如果你的 agent 今天要跑在 Linux，明天要适配 macOS，下个月又要进入远程 workspace，你怎么办？
如果你想从 chat interface 转向 workflow interface，再转向 multi-agent system，再转向 plugin marketplace，你怎么办？
如果地基不可迁移，那么你并不真正拥有一个 agent system。
你拥有的只是一个 product integration。
这是我非常在意的区别。
agent 不只是 prompt。
它不只是 tool call loop。
它也不只是 graph。
它更接近一种 application。
而 application 需要真正的 infrastructure。
这就是我开始构建 Praxis 的原因。
*为什么我开始构建 Praxis
Praxis 是我对 agent harness 缺失基础设施层的一次定义和实现尝试。
我不是因为想喊口号式地和 LangChain 竞争才开始做它。
我开始做，是因为我不断遇到同一个问题：
没有一套足够完整、可定制、可迁移的地基，可以用来构建严肃的 agent system。
LangChain 在历史上很重要。
它帮助很多人理解了 LLM 可以连接工具、记忆、检索和 workflow。
但我不认为未来的 agent stack 可以主要建立在 wrapper 式抽象之上。
下一层必须更接近 runtime、policy、context、execution、observability 和 portability。
它必须更像一个系统基质。
Praxis 就是对这个基质的一次尝试。
目标不只是做“一个 agent framework”。
目标是让 agent system 更容易构建、迁移、继承、检查、优化和定制。
一个严肃的 agent harness 不应该因为开发者想更换模型供应商就崩掉。
它不应该因为工具层增长就需要重写整个架构。
它也不应该强迫每个开发者手动重新发明 context mapping、cache strategy、sandbox boundary、session layout、skill loading、event recording 和 multi-agent communication。
这些都应该是一等组件。
*越无聊的Infrastructure,越是杠杆所在
在我看来，agent 的最小可用基础设施层应该包括：
多平台沙箱层；
通用且可扩展的 MCP 层；
稳定的 skill 组件系统；
长期记忆模块；
模型供应商无关的调用机制；
policy 组件；
缓存分析和优化；
多 agent 通信；
压缩机制；
上下文分块映射；
可覆写的 base prompt；
事件控制；
timeline 记录；
workspace 治理；
session 管理；
project 划分；
插件加载；
runtime 定制；
以及足够面向前端的抽象，让应用更容易构建。
这听起来很多，因为它本来就很多。
但这正是重点。
今天 agent development 之所以困难，是因为太多 infra 职责泄漏到了 application code 里。
开发者不应该只是为了验证一个想法，就从零开始解决所有这些问题。
如果有人想构建一个读取邮件并草拟博客的小 automation，地基应该已经在那里。
如果有人想挂载几百个工具和 skill，上下文不应该污染到无法控制。
如果有人想构建几千个 agent，并让它们在持久 workflow 中承担细粒度职责，runtime 应该能够表达这种结构。
如果有人想实验缓存经济性，他不应该手动一块一块调整 prefix context。
如果有人想用多个模型承载同一个语义意图，就应该有一个抽象层可以在供应商之间映射这种意图。
如果有人想构建一个真正理解自己 workflow 的 harness，他应该能够定制整套栈，而不只是定制 prompt。
这就是我想要的系统。
这也是为什么我在 Praxis 之上构建 Raxode。
Raxode 不是终点。
它是一个证明。
如果 Praxis 是真实的，那么 Raxode 就不应该只是一个一次性的应用。
它应该是一个 harness，用来证明这个 framework 能承载什么。
更重要的是，其他开发者应该能够用 Praxis 构建出比 Raxode 更好的东西。
这才是真正的测试。
一个 framework 不是靠自己的 demo 证明的。
它是靠别人能在它之上构建出原作者没有想象过的东西来证明的。
我还处在很早期。
Praxis 还不完整。
我基本上是在独自构建它。
目前它使用 GPL。等架构足够成熟后，我大概率会把它转向 MIT 或 Apache。
我不会假装它现在已经是答案。
但我确实认为这个方向是必要的。
因为当前 agent 世界存在迁移性问题。
存在可组合性问题。
存在上下文污染问题。
存在记忆问题。
存在缓存经济性问题。
存在供应商锁定问题。
存在 runtime 问题。
还存在一个问题：太多人在构建惊艳的 demo，太少人在构建那些无聊但能在真实使用中活下来的基础设施。
*模型重要, harness 更重要, 但更好的harness最重要
Codex 很优秀，但它深度绑定于 GPT 的后训练和产品循环。
Claude Code 很优秀，而我怀疑 Claude 在 coding 上之所以进步这么快，其中一个原因是 Claude Code 产生了对后训练非常有价值的数据。
从这个角度看，DeepSeek 规划更深入的 coding product 也很合理：高质量 coding 轨迹远比在低质量数据上反复打磨更有价值。
每个人都需要好数据。
但如果 base model 的能力持续提升，并且如果一组相对较小的 base tools，比如 20 到 25 个设计良好的 primitives，就能覆盖大部分有用的 computer work，那么下一个瓶颈可能不再是原始模型智能。
瓶颈可能是那个让模型可靠使用这些能力的系统。
API 使用。
Bash。
文件系统。
浏览器。
多模态感知。
记忆。
policy。
上下文。
工具。
workspace。
日志。
反馈。
模型很重要。
但 harness 也很重要。
更强的模型放在弱 harness 里，仍然是脆弱的。
好的 harness 能把模型能力转化为可重复的工作。
这就是我在意的缺口。
也许这是一种新范式。
也许这只是下一个显而易见的层。
无论如何，我认为 agent infra 必须变成开发者真正可以在其上构建的东西。
不只是调用。
不只是租用。
不只是集成。
而是在其上构建。
定制。
替换部件。
扩展。
观测。
迁移。
拥有。
这就是我希望 Praxis 成为的东西。
一个用于构建 agent harness 的 framework 和 runtime。
一个基质，让 sandbox、tool、context、memory、policy、cache、skill、model、session、event 和 multi-agent coordination 不再是分散的 hack，而是连贯的组件。
一个系统，让开发者想要速度时可以声明式开始，想要控制时可以下沉到底层。
一个系统，让 agent 不再被困在某一个 provider、某一个 UI、某一个 SDK 或某一种产品哲学里。
一个系统，让旧 agent 可以迁移，而不是每次都从零重写。
一个系统，让新的 agent idea 可以快速验证，而不是每次都重建整套地基。
我不知道 Praxis 会不会成为答案。
我知道可能有几百家大公司也在思考类似的问题。
我知道我很小。
我也知道我可能在很多实现细节上都是错的。
但我也知道一件事：
agent 世界需要真正的 infra 层。
而且总得有人去做。
如果 Praxis 能让 agent 真正成为有用软件系统的那个时刻，稍微提前一点点，那它就值得被构建。
哪怕它只是朝向真理走出的一小步。