AI Agent 的“操作系统时刻“：为什么你的 Agent 框架在下一个模型发布时就会过时？

在模型快速迭代的时代Agent 工程开发必须面对一个现实问题今天的模型写的 agent 框架明天还管用吗Anthropic 的回答是——大概率不管用。不是因为代码写得烂而是因为你的框架里编码了太多Claude 做不到什么的假设。而这些假设下一次模型升级就变成了死代码甚至安全漏洞。他们举了个具体的例子Claude Sonnet 4.5 在上下文接近上限时会出现上下文焦虑——提前结束任务。团队在 harness 里加了上下文重置来应对。但同一个 harness 跑在 Opus 4.5 上这个行为消失了——重置机制直接成了废代码。所以他们从操作系统的设计哲学里借了一个思路搭了一套叫Managed Agents的系统 。这篇文章的背景是什么想解决什么问题Agent 框架在每次模型升级都过时了。agent 框架的所有组件——harness大脑循环、sandbox执行环境、session事件日志——在传统设计里被塞进了同一个容器。这带来了三个具体痛点运维噩梦容器挂了会话丢失卡了人工救活开 shell 进去调试等于接触用户数据性能浪费每个 session 启动时都要预分配容器clone 仓库、安装依赖即使这个 session 根本不需要安全隐患Claude 生成的代码和 API token 在同一个容器里一次 prompt injection 就能偷走凭证文章的核心主张不要为今天的模型写补丁要为尚未被构想的程序设计接口。就像操作系统用read()/write()/process这些抽象取代了具体硬件依赖——抽象比硬件活得长。这个框架整体好在哪在动手拆解具体设计之前先看全貌。Managed Agents 把 agent 拆成三个虚拟化组件Session事件日志 → 持久化在外append-onlyHarness大脑循环 → 无状态崩溃后可从 session log 恢复Sandbox执行环境 → 按需分配被动隔离环境加上统一的工具入口execute(name, input) → string和独立的安全切面。基于文章的理念简单实现了一个 Python harness的项目框架harness/ ├── __init__.py ├── types.py # 共享类型Event, Session, ToolCall, ToolResult ├── session/ │ ├── __init__.py │ ├── interface.py # SessionStore ABC (emit/get/query events) │ ├── event.py # Event 导出 │ └── sqlite_store.py # SQLite 实现占位 ├── harness/ │ ├── __init__.py │ ├── interface.py # Harness ABC (run / wake) │ ├── loop.py # DefaultHarness调 LLM → 路由 tool → 写事件 │ ├── context.py # ContextBuildergetEvents 切片 上下文工程 │ └── recovery.py # RecoveryManagerwake(sessionId) 崩溃恢复 ├── sandbox/ │ ├── __init__.py │ ├── interface.py # Sandbox ABC (execute / provision / teardown) │ ├── provision.py # SandboxProvisioner延迟分配 │ └── docker_sandbox.py # Docker 实现占位 ├── tools/ │ ├── __init__.py │ ├── interface.py # Tool ABC (name / description / parameters / execute) │ ├── registry.py # ToolRegistryexecute(name, input) 路由 │ └── builtin/ │ ├── __init__.py │ ├── file.py # ReadFileTool / WriteFileTool │ └── bash.py # BashTool ├── security/ │ ├── __init__.py │ ├── vault.py # Vault凭证保险箱token 不到达 sandbox │ └── auth_bundle.py # AuthBundleGit token 用完即销毁 └── llm/ ├── __init__.py ├── interface.py # LLMClient ABC (chat) └── deepseek.py # DeepSeekClient 占位核心接口只有三个抽象# 一次 agent loop 的全过程 asyncdefagent_loop(session_id, task): # 1. 记录用户任务 await session.emit_event(session_id, task) while not_done: # 2. 取出最近的上下文不是全量 history await session.query_events(session_id, start-50) # 3. 调 LLM response await llm.chat(history) # 4. LLM 调工具 if response.tool_call: result await tools.execute(response.tool_name, response.tool_input) await session.emit_event(session_id, result) # 记录结果 else: break # 任务完成模块间依赖严格单向关键约束harness 不知道 sandbox 的存在sandbox 不知道 harness 的存在security 模块是横向切面harness 完全不需要 import。一次 agent loop 的数据流harness.run(session_id, task) → 调 LLM传入 task getEvents(session_id, 最近N条) → LLM 返回 response可能包含 tool_call → 有 tool_call → ToolRegistry.execute(name, input) 内部BashTool/FileTool 持有 Sandbox在其中执行 或 MCPTool 通过 Vault 代理调用外部 API → 无 tool_call → 纯文本响应 → emitEvent(session_id, event) 写入结果 → 回到第一步直到任务完成这个架构整体好在哪一句话每个组件可以独立替换且随时间推移不衰减。换 LLM provider 不用改 session 存储换 sandbox 实现Docker → K8s → 子进程不用改 harness 循环加新工具无需动核心循环安全保证不依赖模型能力上限。下面按创新程度从高到低拆解每个章节到底解决了什么问题。Meta-harness 设计哲学核心问题你设计的框架能活到下个模型吗这可能是全文最重要的一个观点但它不在某个具体的技术实现里而在设计理念。Anthropic 团队明确说他们从操作系统的历史里借了思路。操作系统为什么能活几十年因为它没有为某块具体的硬盘或内存写代码而是把硬件虚拟化成了通用抽象——read()不管你底层是 1970 年代的磁盘还是现代 SSD接口不变实现可以随便换。Managed Agents 对 agent 组件做了同样的事。他们定义了三个接口——Session、Harness、Sandbox——只规定形状不规定实现# session/interface.py —— 只规定事件怎么存、怎么取# 背后可以是 SQLite、Postgres、甚至文件系统classSessionStore(ABC): asyncdefemit_event(...) # append-only 写 asyncdefquery_events(...) # 按位置切片读 asyncdefget_session(...) # 获取元信息# sandbox/interface.py —— 只规定隔离执行环境的能力# 背后可以是 Docker 容器、子进程、K8s PodclassSandbox(ABC): asyncdefprovision(...) # 按需分配资源 asyncdefrun(...) # 执行命令 asyncdefteardown(...) # 销毁# harness/interface.py —— 只规定大脑循环的入口classHarness(ABC): asyncdefrun(session_id, task) # 新任务 asyncdefwake(session_id) # 崩溃恢复原文“We’re opinionated about the shape of these interfaces, not about what runs behind them.”小结不管你用什么数据库、什么容器技术、什么 LLM。但接口就长这样别乱改。这里的opinionated很关键——不是什么都不管那等于没设计而是在正确的层面施加约束。接口形状必须固定不然解耦无从谈起。但实现可以随便换不然框架活不过下个模型。这就是meta-harness的含义不是给今天的 Claude 写一个 harness而是给未来不知道会变成什么样的模型预备一套不会过时的接口。在代码里这个理念直接体现为DefaultHarness的构造函数全部依赖接口不依赖任何具体实现。会话 ≠ 上下文窗口核心问题context window 满了你是扔掉内容还是压缩内容扔错了怎么办这是全文最容易读错的一个设计。很多人以为 Managed Agents 用外部存储解决了 context window 不够用的问题——没有它没解决这个问题文章也没这么声称。它解决的是另一个更微妙的问题丢弃决策的不可逆性。LLM 的 context window 是有限的长任务一定会超出。传统做法是三种•压缩compaction让 LLM 把自己的上下文总结成摘要扔掉原文•记忆工具memory tool让 LLM 自己决定把什么写入文件•上下文裁剪context trimming删掉旧的 tool result、thinking block这三者有一个共同问题一旦扔掉就找不回来了。而问题是你很难预判未来的 turn 需要哪些历史 token。Managed Agents 的解法是把存储可靠性和上下文管理拆成两个职责Session存储层 → 保证事件不丢可随时按位置切片检索Harness管理层 → 负责压缩、裁剪、重组、cache 优化裁掉的内容不在 context window 里了但还在 session log 里。需要时getEvents()重新捞# harness/context.pyclass ContextBuilder: async def build(self, events, system_prompt) - list[dict]: # 事件列表 → LLM messages可压缩、可裁剪 async def rewind(self, session_id, before_index, count): # 回溯读取更早的事件 # 传统 compaction 做不到——原文已经丢了原文“We separated the concerns of recoverable context storage in the session and arbitrary context management in the harness because we can’t predict what specific context engineering will be required in future models.”小结我不知道未来模型需要什么样的上下文工程策略所以我只保证一件事——内容不丢。怎么裁、怎么压、怎么重组你可以在 harness 里随便换。安全边界的结构性修复核心问题你给 Claude 一个只读 token 就安全了吗如果 Claude 越来越聪明呢这是全文最让我印象深刻的设计。它不是通过权限 scope 收紧来防御因为 scope 收紧本质上是赌博——赌拿着受限 token 的 Claude 造不成伤害。原文“Narrow scoping encodes an assumption about what Claude can’t do with a limited token—and Claude is getting increasingly smart.”老架构Claude 生成的代码和 API token 在同一个容器里。一次 prompt injection 只需要诱导 Claude 执行cat /proc/self/environ就能偷走 token。更可怕的是偷到的 token 可以脱离当前 session另起一个完全不受限制的新 session。新架构让 token 物理上不存在于沙箱的任何可寻址空间。两种模式模式 1: Auth BundleGit 场景 外部用 token clone 仓库 → 写入 .git/config remote → token 立即销毁 沙箱里只有 git remote 配置没有明文 token模式 2: VaultMCP / API 场景 Claude → 调 search_emails → MCP 代理独立安全域 → 从 Vault 取 OAuth token → 调外部 API → 返回结果 全程 Claude 和 harness 看不到 token代码里直接体现了这个隔离# security/vault.pyclassVault: # 只能被 MCP 代理内部调用 # harness/loop.py 完全不 import security 模块 asyncdefretrieve(self, key: str) - str | None: ...# security/auth_bundle.pyclassAuthBundle: asyncdefclone_with_token(self, repo_url, token, workspace): # token 生命周期仅限于此函数调用 # 调用结束后 token 引用立即释放为什么这是结构性修复因为它不依赖Claude 找不到——物理隔离意味着找到了也没用因为它根本就不在那个内存空间里。这是一个随时间推移不衰减的安全保证。不管模型变多聪明拿不到就是拿不到。按需延迟分配 Sandbox核心问题你的用户只是想问一个问题为什么要等容器启动这是最直观的优化但背后的设计意图比快更深。老架构每个 session 启动时要预分配容器——clone 仓库、启动进程、拉取事件。全部跑完才能开始推理。这意味着每个 session 都交这笔税哪怕它永远不需要 sandbox。新架构容器被踢出关键路径。推理可以先开始sandbox 在 LLM 需要时再创建# sandbox/provision.pyclass SandboxProvisioner: async def provision(self, sandbox, resources): # 只在 LLM 第一次发起 execute() 时才创建容器 # 不是 session 启动时预分配# harness/loop.py —— harness 不直接持有 sandbox# 只有 BashTool / FileTool 等需要隔离执行的工具才持有 sandbox 引用# 如果整个 session 都没用到这些工具sandbox 根本不会被创建效果p50 TTFT 降了约 60%p95 降了超 90%。为什么 p95 降幅远大于 p50因为长尾场景大 repo clone、网络 jitter在老架构下全部堵在第一个 token 之前。去掉这些极端情况相当于把最差的用户体验拉平到了接近中位数的水平。更深层的设计意图这个优化之所以成立反过来证明了 Managed Agents 对自己定位的变化——不是每个任务都要跑代码的执行引擎而是大多数时候在思考偶尔需要动手的 agent 架构。如果每个 session 都要进 sandbox懒加载就没有意义。大脑和手的多对多关系核心问题为什么不能让多个大脑共享一双手为什么不能让大脑之间互相传递手这是文章里最操作系统化的设计——从单进程到多进程的跃迁。老架构一个容器 一个大脑 一双手耦合在一起。早期模型智力不够无法管理多个执行环境所以这不是瓶颈。但随着模型变强单容器反而成了瓶颈容器一挂所有手的状态全丢。新架构下每双手都是execute(name, input) → string接口的一个实现。手不知道背后是谁在控制它大脑不知道手是什么# tools/registry.pyclass ToolRegistry: async def execute(self, name: str, input: dict) - str: tool self._tools.get(name) return await tool.execute(input) # 背后可能是 BashTool持有 Docker 容器 # 也可能是 MCPTool持有 vault 凭证代理 # 也可能是任何自定义工具 # ToolRegistry 和 harness 都不关心原文“The harness doesn’t know whether the sandbox is a container, a phone, or a Pokémon emulator.”而且因为大脑和手不绑定大脑之间可以互相传递手——这为未来的多 agent 协作打开了空间但接口本身不需要为此做任何修改。总结Managed Agents 本质上是一篇关于设计Harness的文章。它回答的问题不是怎么让 agent 跑得更快而是怎么让今天的架构设计在明天的模型上依然成立。设计解决的核心问题随时间衰减Meta-harness 哲学框架能否活过下个模型否——接口固定实现可换Session ≠ 上下文窗口丢弃决策不可逆否——裁剪可回溯安全边界结构性修复prompt injection 窃取凭证否——物理隔离不赌模型能力延迟分配 Sandbox容器 setup 拖慢首 token否——懒加载是通用模式大脑与手多对多单容器瓶颈否——不绑定数量安全性不依赖模型的能力上限。这是全文最深层的焦虑——你编码的每一个Claude 做不到 X的假设都会在下一个模型发布时变成死代码甚至安全漏洞。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】