《扩展托管代理：将大脑与双手分离》

Lafully

360人浏览 · 2026-04-14 20:20:02

Lafully · 2026-04-14 20:20:02 发布

《扩展托管代理：将大脑与双手分离》深度笔记

一、核心命题：框架的"苦涩教训"

文章开篇即提出一个关键洞察：框架（harness）中编码的假设会随着模型改进而过时。这呼应了Rich Sutton的"苦涩教训"（Bitter Lesson）——我们不应将人类知识固化到系统中，而应构建能随计算能力扩展的通用方法。

具体案例：

Claude Sonnet 4.5 表现出"上下文焦虑"（context anxiety）——感知到上下文限制临近时提前结束任务
团队通过添加上下文重置功能解决
但同一框架用于 Claude Opus 4.5 时，该行为消失，重置功能成为"死重"（dead weight）

这一经验促使Anthropic构建Managed Agents——通过稳定的接口而非具体的实现来运行长期代理任务。

二、历史类比：操作系统的设计智慧

作者将Managed Agents的设计哲学与操作系统类比：

操作系统	Managed Agents
硬件 → 进程、文件等抽象	代理组件 → 会话、框架、沙箱
`read()` 命令无需关心底层是1970年代磁盘还是现代SSD	接口无需关心具体实现
顶层抽象稳定，底层实现自由变化	接口持久，实现可替换

核心抽象三层架构：

Session（会话）：仅追加的事件日志，记录一切发生之事
Harness（框架）：调用Claude并路由工具调用的循环
Sandbox（沙箱）：代码执行与文件编辑环境

三、从"宠物"到"牲畜"：解耦的必然性

3.1 初始设计的困境：单体容器

早期将所有组件置于单一容器：

会话、框架、沙箱共享环境
文件编辑直接系统调用，无服务边界

"宠物vs牲畜"问题：

服务器成为宠物（pet）：命名、手工维护、不可丢失
容器故障 = 会话丢失
容器无响应 = 必须人工恢复

调试噩梦：

唯一窗口：WebSocket事件流
无法定位故障来源（框架bug / 数据包丢失 / 容器离线）
需进入容器shell调试，但容器含用户数据 → 实质上无法调试

3.2 客户需求的冲突

客户希望Claude连接其VPC资源时：

必须网络对等（peering），或
在客户环境运行框架

框架的隐含假设成为扩展障碍

四、解耦架构：大脑、双手与记忆分离

4.1 核心解耦策略

组件	比喻	职责	接口
Brain	大脑	Claude + 框架逻辑	调用工具
Hands	双手	沙箱/工具执行	`execute(name, input) → string`
Session	记忆	持久化事件日志	`getSession(id)`, `emitEvent(id, event)`

4.2 框架离开容器

关键转变：框架通过标准工具调用与容器交互

execute(name, input) → string

效果：

容器变为牲畜：可随意替换
容器死亡 → 框架捕获为工具调用错误 → 返回Claude → Claude决定重试
新容器通过 provision({resources}) 标准配方初始化

4.3 框架故障恢复

wake(sessionId)      → 重启新框架
getSession(id)       → 获取事件日志
emitEvent(id, event) → 持久化记录

关键：会话日志在框架外部，框架无状态，可任意重启

五、安全边界：凭证与执行的隔离

5.1 耦合设计的安全隐患

不可信代码与凭证同容器运行
提示注入只需说服Claude读取自身环境
攻击者获取令牌 → spawn无限制会话

缓解措施的局限：缩小令牌范围隐含"Claude用受限令牌不能做什么"的假设——但Claude越来越聪明

5.2 结构性解决方案

模式一：凭证与资源绑定

Git：仓库访问令牌在沙箱初始化时克隆，接入本地git remote
沙箱内 push/pull 无需代理接触令牌

模式二：外部保险库 + 代理

MCP工具：OAuth令牌存安全保险库
Claude → 专用代理 → 代理用会话关联令牌从保险库取凭证 → 调用外部服务
框架全程不感知凭证

六、会话 ≠ 上下文窗口：可恢复的外部记忆

6.1 长期任务的上下文挑战

标准方法（压缩、内存工具、上下文修剪）的共性：不可逆的取舍决策

难以预知未来需要哪些token
压缩后消息从上下文窗口移除，仅当存储时可恢复

6.2 会话作为外部上下文对象

Managed Agents方案：

上下文持久存储于会话日志（非沙箱/REPL内）
接口 getEvents() 支持灵活查询：
- 从上次读取位置继续
- 回溯特定时刻前的事件
- 重读特定操作前的上下文

分层设计：

层级	职责	理由
Session	可恢复的持久存储	保证耐用性和可查询性
Harness	任意上下文管理（组织、缓存优化、上下文工程）	未来需求不可预测

七、性能突破：多大脑、多手的弹性扩展

7.1 “多大脑”：TTFT优化

解耦前的问题：

每大脑需一容器
推理前必须完成：克隆仓库、启动进程、获取事件
即使不访问沙箱的会话也支付完整容器成本

关键指标：TTFT（Time To First Token）

用户感受最强烈的延迟

解耦后：

容器仅当需要时通过工具调用配置
无需容器的会话可立即开始推理
p50 TTFT ↓ 60%，p95 TTFT ↓ 90%+

7.2 “多手”：认知复杂度的转移

早期单容器限制：

模型无法推理多执行环境
单容器故障 = 所有"手"的状态丢失

解耦后：

每只手 = 工具 execute(name, input) → string
框架无需知道沙箱是容器/手机/宝可梦模拟器
大脑可互相传递手（handoff）

八、元框架设计哲学

8.1 核心原则

“对Claude周围的接口有明确设想，对具体实现无预设”

有明确设想（opinionated about interfaces）：

操控状态的能力（会话）
执行计算的能力（沙箱）
扩展到多大脑、多手的能力

无预设（unopinionated about implementations）：

大脑/手的数量
大脑/手的位置

8.2 与Claude生态的关系

组件	角色	Managed Agents支持
Claude Code	通用框架	✓
任务专用框架	垂直领域优化	✓
未来未知框架	—	接口兼容

九、关键术语与概念

术语	含义
Harness（框架）	调用LLM并路由工具调用的控制循环
Context anxiety（上下文焦虑）	模型感知上下文限制临近时的提前终止行为
Pets vs Cattle	基础设施隐喻：宠物需单独维护，牲畜可批量替换
TTFT	Time To First Token，首token响应时间
MCP	Model Context Protocol，Anthropic推出的工具集成标准
Session log	仅追加的完整事件记录，代理的"外部记忆"