Agent Runtime 正在变成新的操作系统

引子

这一周如果只看表面，AI 编程圈像是在重复同一套热闹。

新的 skill，新的 agent，新的 memory 项目，新的工作流截图，新的“多模型协作”演示，几乎每天都在刷屏。乍看之下，这像是又一轮工具爆炸。但如果把最近几天的高信号 bookmarks 摊开，你会发现真正发生的事，并不是“又多了几个 Agent 框架”，而是行业正在快速收敛到同一个问题上：

Agent 之后真正要竞争的，不再是 prompt 写得多巧，也不只是单次任务做得多像人，而是谁能把任务运行时、状态管理、工具接口和协作机制做成一个长期稳定的系统层。

换句话说，下一阶段的核心问题已经变成：

• 任务怎样跨多个上下文窗口持续推进
• 状态怎样外置，而不是永远塞在 prompt 里
• 工具、沙箱、凭证和执行环境怎样解耦
• 多个 agent、多个模型、多个执行端怎样协同
• 当模型能力继续变化时，什么应该保持稳定，什么应该被随时替换

这已经不是传统意义上的提示工程了，而是运行时设计。

我的判断也很直接：未来 12 到 24 个月里，最有壁垒的 AI Agent 公司，不会只是把模型包装得更顺手，而是会把 Agent runtime 做得越来越像一个新的操作系统。

不是 Linux 那种完整 OS，而是一层新的 agent substrate：它负责状态、任务、能力、权限、恢复、审计和协作，上层模型和工作流则可以不断变化。

为什么我认为竞争正在从 Prompt 层下沉

最近这批高信号 bookmarks 里，有三条非常一致的暗线。

第一条暗线，隐性上下文正在被抽成显性对象

这波 DESIGN.md 的流行很能说明问题。

它的价值不是“又一个 UI prompt 模板”，而是把设计语言外置成了一个机器可读、可持续引用的设计约束文件。过去你只能对 agent 说“像 Apple 一点”“像 Stripe 一点”，现在你开始把品牌调性、组件语言、颜色、排版、交互偏好写成一个独立对象，让模型反复读取。

同一类事情也发生在 Graphify 这类工具上。它们不是试图让模型凭空更聪明，而是在把代码库结构、依赖关系、设计决策和上下文线索沉淀成一个可查询的知识图谱对象。这样模型每次进入任务时，不再是从零读仓库，而是在已有状态面上定位、检索和恢复。

这两件事看上去分属“设计”和“代码理解”，但底层逻辑完全一样：把原本隐含在 prompt 里的上下文，抽成长期存在、可复用、可查询的工件。

第二条暗线，大家终于开始承认 context 不是 memory

最近社区里围绕 mem0、mempalace、shared memory、agentic memory 的热度，其实不是某个单一产品的胜利，而是一个共识开始形成：

聊天记录不是 durable state，上下文窗口也不是 memory。

很多人过去都默认，模型“记住一点之前的对话”就算有记忆了。但一旦任务跨多个 context window、跨多天、跨多个 agent、甚至跨不同模型，这种假设就会迅速失效。

于是社区开始认真建设另一层东西：

• 事件日志
• 检索层
• 用户 profile
• 工件索引
• 进度记录
• 共享记忆面

我对这类项目的看法并不浪漫。短期内这里会有大量叙事超前、营销过猛的产品，很多“魔法记忆”最后拆开看，无非还是向量检索、规则归档、事件流和少量结构化 profile 的组合。但方向本身是成立的，因为它解决的是真问题：如果没有外部状态层，Agent 很难真的跨 session、跨任务、跨角色工作。

第三条暗线，agent-to-agent 协作正在脱离人工复制粘贴

像 smux、tmux-bridge、claude_code_bridge 这种社区项目，表面看只是终端极客的小工具，但它们其实很重要。它们证明了一件事：开发者已经不满足于“我先问 Claude，再把结果贴给 Codex，再把补丁贴回去”。

他们开始需要的是：

• 一个 agent 做主控和拆解
• 一个 agent 去查资料或跑实验
• 一个 agent 做 adversarial review
• 一个 agent 专门做 QA 或验收
• 多个 agent 在不同 pane、不同 session、不同执行环境里协同

也就是说，大家开始从“单代理出结果”切换到“多代理如何交接、复盘、共享状态和分工”。这不是噱头，而是复杂任务自然会逼出来的系统需求。

Anthropic 把这条路线讲得最清楚

这几周如果只看一家公司的工程博客，Anthropic 基本已经把这条路线公开摊开了。

1）Managed Agents：真正重要的是 session、harness、sandbox 的分离

在《Scaling Managed Agents: Decoupling the brain from the hands》里，Anthropic 给出了一个非常成熟的抽象：

• session，append-only 的事件日志，也就是可恢复状态
• harness，推理和调度循环，也就是 orchestration layer
• sandbox，执行环境，也就是具体做事的“手”

整篇文章最重要的一句话，其实不是产品介绍，而是：

The session is not Claude’s context window.

这句话几乎把今天大部分 Agent 系统的核心误区点破了。上下文窗口只是执行现场，不是长期状态；compaction 也不是 durable memory；历史不是“有没有摘要一下”，而是有没有被保存成可恢复、可查询、可回放的执行事实流。

Anthropic 进一步把 harness 从 container 里拿出来，让它通过统一接口 execute(name, input) -> string 去调用工具和沙箱。这个改动带来的，不只是代码重构层面的优雅，而是三种非常硬的系统收益：

第一，恢复性更强。harness 崩掉，不等于整个 session 消失，因为状态已经留在 session log 里。

第二，安全边界更清晰。凭证不再直接暴露在 sandbox 里，而是经由 vault 和代理层间接访问，安全不再建立在“模型应该想不到攻击路径”这种脆弱假设上。

第三，性能更好。不是每个 session 一开始都要把完整容器和执行环境预热起来。Anthropic 在文中给出的数据很醒目：这种架构下，p50 TTFT 降低大约 60%，p95 降低超过 90%。这说明很多延迟并不是推理本身，而是执行环境被错误地预耦合到了入口。

更值得注意的是 Anthropic 对自己这套系统的定位。他们并没有把某一版 harness 当成终局，而是在刻意做一个 meta-harness，也就是围绕 Claude 设计稳定接口，而不是围绕今天的具体实现去做一套会快速过时的壳。

这已经很接近操作系统思路了。操作系统长期存在，不是因为某个 app 固定不变，而是因为它把状态、设备、进程、权限这些抽象稳定了下来。

2）Effective Harnesses：跨 context window 的连续性，不能靠模型记性

另一篇《Effective harnesses for long-running agents》把问题讲得更接地气。

Anthropic 观察到，长任务最根本的矛盾是：agent 只能在离散 session 里工作，但复杂任务又必然跨多个 context window。结果通常会出现两个失败模式。

第一种失败，是一次做太多，做到一半 context 爆掉，留下一个半成品，下一轮 session 只能靠猜。

第二种失败，是做了一点进展以后，后续 session 看到表面上“像样了”，就误判任务已经完成。

他们最后的解法很像一支交接纪律很强的软件团队：

• initializer agent 先搭环境
• coding agent 每次只推进一个小步
• 用 claude-progress.txt、feature requirements、git history 等结构化工件做交接
• 强制让每次新 session 都从清晰状态出发，而不是靠模型回忆“上一个自己做过什么”

这件事的真正意义，不是又多了一个 harness 技巧，而是说明了一条很硬的工程事实：

跨上下文窗口的连续性，不能只依赖模型本身，必须依赖外部工件层。

3）Harness Design：多代理不是花活，而是职责拆分

《Harness design for long-running application development》则把事情推进到了另一层。

Anthropic 在那篇文章里不再满足于“一个 agent 加更多 prompt”，而是明确拆出了 planner、generator、evaluator 三种角色。这里最值得重视的，不是“三个 agent 看起来更高级”，而是它承认了一个长期被低估的问题：

同一个 agent 同时负责生成和验收，通常是不可靠的。

模型对自己生成的东西天然偏宽容，这种问题在设计、美学、复杂交互、端到端体验和 QA 场景里尤其明显。

所以多代理的真正价值，不是为了制造热闹，而是为了把不同职责拆开：

• planner 负责扩 scope 和规划
• generator 负责实现
• evaluator 负责更苛刻地验证

一旦你接受这一点，很多今天社区里流行的“多模型协作”“第二意见”“对抗性审查”，其实都不再是花哨玩法，而是在补系统里原本应该存在的角色分层。

OpenAI、LangGraph、Google 其实也在往同一个方向走

如果只有 Anthropic 在讲这些，还可以说这是它自己的产品哲学。但现在不是一家在这么做。

1）OpenAI：Responses API 正在把 runtime 原语下沉到 API 里

OpenAI 最近的 Responses API 文档里，有几个信号非常关键：

• background mode，长任务可以异步跑，客户端可以轮询，也可以断线后恢复流
• store: true，状态化上下文开始成为原生能力，而不只是开发者自己维护消息数组
• agentic loop，一个 response 内可以连续调用多个工具
• remote MCP servers，工具不再只是本地函数，而是远程接入的能力面

这几个点放在一起看，已经不是“模型 API 加了几个参数”，而是在把很多原本属于 agent framework 的事情，下沉为更基础的 runtime 原语。

换句话说，OpenAI 也在往同一个方向靠：它提供的不只是一个会回答问题的模型，而是一种更接近任务运行时的交互面。

2）LangGraph：生产级 Agent 的核心不是 while loop，而是 durability

LangGraph 的官方文章《Building LangGraph: Designing an Agent Runtime from first principles》里，最重要的词几乎都和 durability 有关：

• control
• checkpointing
• human-in-the-loop
• task queue
• structured execution

它真正试图回答的问题也不是“怎么把一个 agent 跑起来”，而是“怎么让 agent 在生产环境里出错、中断、等待、审批、恢复之后依然成立”。

这里和 Anthropic 最像的一点在于，双方其实都在承认：

生产级 agent 的核心，不是让模型把 while loop 续下去，而是让任务在中途失败、等待人类、等待资源、切换机器后还能继续成立。

这已经是工作流引擎和执行系统的范畴，而不是 prompt 框架的范畴。

3）Google A2A：工具协议之外，开始出现代理间协议

Google 的 A2A 更说明另一件事。MCP 解决的是“agent 如何接入工具和上下文”，而 A2A 解决的则更像是“agent 如何和 agent 协作”。

A2A 提供的几个关键词很典型：

• Agent Card 做 capability discovery
• task object 有生命周期
• 长任务过程中可以同步状态
• artifact 作为结果对象流动

Google 甚至明确把 A2A 定位成对 MCP 的补充。这说明行业已经开始意识到：仅仅有工具接口还不够，未来还会需要一层专门处理 agent-to-agent 通信、发现和协作的协议层。

真正正在收敛的，是四层架构

如果把最近这些信号压缩一下，我认为行业实际上正在收敛到一个四层结构。

第一层：可恢复状态层

这一层负责保存事实，而不是保存措辞。

它的典型对象包括：

• session event log
• checkpoints
• progress files
• feature requirements
• task boards
• memory records
• graph index

它解决的问题是，任务如何续上，失败如何恢复，历史如何回放。

第二层：orchestration / harness 层

这一层负责调度，而不是持有一切。

它关心的是：

• 哪一步现在做
• 哪些信息应该进入上下文
• 哪个 agent 做什么角色
• 什么时候重置、压缩、回放、重试
• 人类应该在哪一步介入

这一层未来会变化得很快，所以真正好的系统，不会把 harness 和状态层、工具层死死绑在一起。

第三层：capability / sandbox 层

这一层就是“手”。

它包括：

• 沙箱
• 浏览器
• shell
• IDE
• 远程 MCP
• 第三方 API
• 企业内部系统

这一层的关键，不只是功能多，而是边界清晰、权限可控、可观测、可隔离，并且能够被多个 brain 共享。

第四层：inter-agent protocol 层

这一层负责让多个脑和多个手在更大的系统里协作。

它包括：

• capability discovery
• task lifecycle
• artifact passing
• shared memory surface
• bridge / pane messaging
• human approval and review hooks

很多人现在还把这一层看成“高级玩法”，但我更倾向于认为，它会越来越基础。因为只要任务复杂度继续上升，单 agent 模式迟早会逼出更强的协作需求。

哪些东西会被快速商品化，哪些会留下来

我自己的判断是，只做 prompt 包装和单轮 skill 封装的产品，会越来越快地商品化。

原因并不复杂。随着模型能力继续上升，很多今天看起来很聪明的脚手架，明天就会变成累赘。Anthropic 自己其实反复强调了这一点，不要把“暂时性的模型缺陷”固化成“永久性的系统结构”。

真正更难被替代的，是下面这些能力：

1. Durable state：任务能不能跨 session、跨天、跨故障继续
2. Secure capability brokering：凭证、资源、环境能不能安全代理调用
3. Observability：你能不能知道 agent 到底做了什么、卡在哪、为什么失败
4. Human-in-the-loop：人类能不能在正确的位置审批、纠偏、重跑
5. Interoperability：不同 agent、不同模型、不同执行端能不能真的协同
6. Artifact discipline：系统是否天然鼓励把隐性上下文变成显性工件

反过来说，如果一个产品的核心价值只是“帮你写更复杂的 prompt”，那它的护城河大概率会越来越浅。

我最看重的三个判断

判断一，Agent runtime 会越来越像微型操作系统

这里的“像操作系统”，不是说每个 Agent 平台都会变成 Linux，而是说它们会越来越像 OS 一样，围绕几类长期稳定的抽象来设计系统：

• 状态
• 任务
• 工具
• 权限
• 消息
• 中断与恢复

上层 agent 怎么写可以不断变化，但只要这些抽象稳定，生态就能积累，工具才能复用，协作协议才能真正成立。

判断二，未来真正的主战场不是“单个超级 agent”，而是“多脑多手”

单 agent 当然不会消失，尤其在简单任务里。

但任务一旦变复杂，就会自然走向角色分工：planner、builder、researcher、reviewer、tester、evaluator。Anthropic 已经在工程文章里把这件事演示出来了，Google A2A 则是在试图给它补协议层。

所以未来的关键，不只是模型够不够强，而是系统能不能让多个强模型高效协作。

判断三，memory 会变成必要基础设施，但一定先经历一轮泡沫

这点我几乎可以确定。

接下来一定会有一大批产品继续宣称“让 Agent 永远记住你”“170 tokens recall everything”“从此不再忘记任何事情”。

真正能留下来的，最后看的一定不是营销，而是几件很朴素的事：

• 事件记录是否可靠
• 检索是否真的有用
• 作用域是否清晰
• 过期和冲突如何处理
• 权限和隐私边界是否明确
• 这些记忆能否真实提升任务执行，而不是只是在数据库里堆垃圾

这条路线的边界和反例

这条路线值得押注，但也不是没有风险。

1）最大的风险是过度工程化

很多团队一看到这些概念，就很容易一上来堆满：多 agent、memory、protocol、sandbox、queue、graph、approval flow。

结果是模型还没成为瓶颈，系统自己先成了瓶颈。

所以 Anthropic 一直强调“从最简单可行方案开始，再按需要增加复杂度”，这点我认为非常对。不是每个任务都需要 Agent OS 级别的复杂性。

2）另一个风险是把今天的模型弱点写成明天的技术债

如果你把“模型今天不会规划”“模型今天容易忘记”“模型今天容易误判完成”直接固化成一套特别重的 DAG、特别刚性的流程，一旦模型变强，这些结构反而会成为负担。

也就是说，今天很多被吹成“架构创新”的东西，明天可能只是过度补丁。

3）还有一个现实边界，协议很多，真正互通很少

MCP、A2A、各种 bridge、各种 skill 格式，短期内一定会很热闹。但真正的互操作不会一夜之间完成。

所以未来一段时间，我们更可能看到的是局部互通、局部标准化，而不是一个已经完全统一的 Agent 协议世界。

如果你现在在做 Agent，最值得优先做什么

如果是我现在从零设计一个 Agent 产品或内部工作流，我会优先押五件事。

1）先把 session 设计成真实对象

不要把 session 当成聊天记录表。

应该把它设计成可查询、可恢复、可回放、可切片的执行事实流。

2）强制系统产出工件

让 agent 在任务过程中不断留下：

• spec
• task list
• progress log
• test report
• evaluation note
• design guideline
• graph report

工件越稳定，跨 session 连续性越强。

3）让 orchestration 成为可替换层

你未来一定会换模型、换检索策略、换工具路由方式。

所以不要让 harness 持有太多不可迁移的假设。能替换，才不会在下一轮模型升级时变成整套返工。

4）把安全建立在结构上，而不是建立在“模型应该想不到”上

凭证不要裸露给 sandbox，高风险动作要通过更窄的代理层、审批层或 vault 去完成。安全必须建立在结构上，而不是建立在对模型能力不足的侥幸上。

5）尽早考虑多代理协作接口

哪怕你今天还没有真的上线多 agent，也要提前想清楚：

• 任务怎么交接
• 结果怎么引用
• 状态怎么共享
• 谁负责验收
• 人类怎样插手

这些问题不会消失，只会越来越早地出现。

结语

如果只看表面，最近这一波 Agent 圈像是在重复过去两年的故事，无非是更多 skill、更多 prompt、更多“自动化工作流”。

但如果看深一点，会发现真正正在收敛的东西非常少，而且非常硬：外部状态、可恢复执行、能力接口、安全代理、结构化工件、多代理协作。

这也是为什么我越来越相信，未来 AI 编程和 Agent 产品的真正竞争，不会发生在“谁更像一个会聊天的模型”，而会发生在“谁更像一个稳得住、接得住复杂任务的新系统层”。

上层模型会继续变，角色会继续变，工作流会继续变。

但只要底层的状态、接口和协作协议开始稳定，Agent 才会真正从一次性的演示，变成可以长期运行、持续交付、被团队信任的生产系统。

等到那一天，大家争的就不再是谁更像聊天机器人，而是谁更像下一代操作系统。

---

参考链接

• Anthropic, Harness design for long-running application development https://www.anthropic.com/engineering/harness-design-long-running-apps
• Anthropic, Effective harnesses for long-running agents https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Anthropic, Scaling Managed Agents: Decoupling the brain from the hands https://www.anthropic.com/engineering/managed-agents
• OpenAI, Background mode https://developers.openai.com/api/docs/guides/background
• OpenAI, Migrate to the Responses API / Using tools https://developers.openai.com/api/docs/guides/migrate-to-responses
• LangChain, Building LangGraph: Designing an Agent Runtime from first principles https://blog.langchain.com/building-langgraph/
• Google Developers Blog, Announcing the Agent2Agent Protocol (A2A) https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
• GitHub, VoltAgent/awesome-design-md https://github.com/VoltAgent/awesome-design-md
• GitHub, safishamsi/graphify https://github.com/safishamsi/graphify/
• GitHub, ShawnPana/smux https://github.com/ShawnPana/smux/
• GitHub, bfly123/claude_code_bridge https://github.com/bfly123/claude_code_bridge
• GitHub, mem0ai/mem0 https://github.com/mem0ai/mem0