“中央餐厅”比喻的核心是：主厨一开始会亲自做所有菜，直到记忆力饱和，才把成熟的菜系教给徒弟。
- 一家小餐厅刚开业，只有主厨一个人。他能同时记住所有顾客的口味和正在做的菜。
- 随着生意变大，桌子越来越多，主厨发现自己的脑子不够用了——再同时记下所有菜的做法和老顾客的偏好，他就要开始忘东西了。
- 他通常的做法（记忆压缩）是草草记个大概，但这会丢掉很多细节。而在这个架构里，他选择把川菜的所有标准、做法、熟客偏好，完整地教给一个新来的川菜帮厨。从此，川菜的相关事情，他只消知道“川菜帮厨会处理好”，以及“川菜做好了的味道是什么样的”。
- 他的脑子重新有了空间，可以接待新顾客，也可以继续精进对别的菜系的品味。
这个比喻直接映射到 LLM Agent 的上下文窗口限制问题：
- 主厨的脑子 ≈ Agent 的可用上下文窗口（有限的 token 容量）
- 做菜 ≈ 执行任务
- 菜系 ≈ 已掌握的能力模块
- 招徒弟 ≈ 将整块能力连同记忆完整转移给子 Agent，而不是做有损压缩
绝大多数 Agent 在上下文达到限制时，会触发记忆压缩——对历史信息做摘要、截断旧消息、或将信息存入外部向量库。但这不可避免会丢失细节和决策上下文，导致后续任务质量下降。
许多分层 Agent 框架从任务一开始就进行分解，把工作分配给子 Agent。这要求任务本身足够复杂，且需要预先知道如何分解。但对于逐渐堆积起来的上下文过载问题，这种静态分工并不适用。
HyperAgents 的元 Agent 通过写代码补丁来“培训”任务 Agent。它关注的是 Agent 能力的迭代提升，而不是上下文压力驱动的责任移交。
本架构要解决的问题，不是“如何让 Agent 一开始就高效协作”，而是“当一个独自工作的 Agent 快要被记忆超载压垮时，如何通过招聘继承的方式优雅地卸载上下文，同时不丢失能力”。
主厨最初是一个完整的 Agent，独立处理用户请求。这个过程会一直持续，直到上下文窗口达到某个阈值（如使用率 > 80%），触发招聘决策。
此时，主厨需要决定：
- 把哪部分能力分离出去？ 通常是已经完成且相对独立的能力模块（比如已搭建好的“用户注册框架”），而不是当前正在进行的任务。
- 招聘什么样的帮厨？ 根据这个模块的性质，定义一个帮厨角色（如“用户注册模块维护师”）。
- 继承什么？ 主厨关于这个模块的全部记忆、评价标准、相关经验教训，一次性复制给新帮厨。
帮厨生成后，主厨的上下文中与该模块相关的细节可以安全移除，只保留一条指向帮厨的“调度引用”及对该模块的高层评价标准。上下文空间显著释放。
这是招聘时的具体操作，也是本架构最关键的设计点。
新帮厨初始化时：
- 继承主厨当前的系统提示词模板（基本价值取向、输出规范、质量意识）
- 继承主厨记忆中关于该模块的完整上下文（该模块的设计思路、已完成部分、相关用户偏好）
- 继承该模块的评价标准字典（知道什么是“做得好”）
然后注入专项 prompt（如“你是负责 XXX 模块的专属帮厨，你接管以下已完成工作……你的产出将按这些标准被评价”）。
这一机制确保帮厨不是从零开始，而是带着主厨在这个模块上的全部认知上岗——信息损失为零（相对于主厨的记忆），而主厨本人则释放了该部分的记忆负担。
主厨在移交能力后，依然要对接下来的工作负责。他通过接收帮厨的结果、打分、记录教训，能让自己的“品味”持续进化：
- 评分越来越精准
- 学会了“在什么情况下需要招新人，什么情况下老帮厨就够了”
- 形成了可跨模块迁移的调度和验收经验
- 主厨（代码架构师）开始独立工作，处理用户的第一个请求：“搭建项目基础设施”。
- 接下来几个请求：搭建用户模块、搭建订单模块。主厨自己完成，上下文窗口逐渐填满。
- 当用户提出新请求，且主厨检测到上下文即将溢出时，系统触发招聘决策。
- 主厨判断：用户模块已经相对完善，可以剥离。于是招聘“用户模块帮厨”，将关于用户模块的全部记忆、代码规范、测试标准完整移交。
- 用户模块帮厨接管该模块的后续维护和扩展。主厨上下文中清除相关细节，只保留“帮厨 A 负责用户模块，代码需符合标准 S”。
- 之后用户再提出与用户模块相关的需求，主厨直接委托给帮厨 A，接收结果后评审，并根据结果更新自己的品味。
- 维护一个上下文使用率监控器
- 当使用率超过阈值，触发
evaluate_offload_candidates()来选择待剥离的能力模块 - 调用
recruit_sub_agent(module)生成帮厨并执行能力继承 - 之后的相关请求通过
delegate_to(sub_agent, task)处理
- 存储每个能力模块的完整上下文（在剥离前）
- 剥离后，该模块的详细记忆被标记为“已移交”，主厨记忆区只保留聚合引用
export_module_context(module_name) -> ModuleContext：从主厨记忆中提取一个模块的全部信息inherit_and_spawn(module_context) -> SubAgent：用继承来的上下文创建帮厨
| 现有方案 | 应对上下文过载的方法 | 本架构的不同 |
|---|---|---|
| 记忆压缩（常见） | 摘要、截断、向量检索 | 本架构完整移交，不丢失细节 |
| ROMA | 从开始就拆分任务，分散上下文 | 本架构由单一 Agent 先做到饱和再移交 |
| HyperAgents | 通过补丁修改子 Agent 能力 | 本架构用完整的上下文移交实现责任转移 |
| MATPO | 模型级 RL 训练角色 | 本架构在 Agent 系统层面操作，无需训练 |
这是一个个人设计原型，目前停留在架构定义和概念验证阶段。接下来的计划：
- 模拟一个上下文逐渐填满的过程，在一个具体领域（如代码编写）中验证招聘触发和能力继承的可行性
- 与“到达上限后直接压缩”的做法做对比实验，评估信息保留度
- 探索与 OpenClaw/Hermes 等自成长 Agent 的实际集成方式
这个项目的核心假设是：对 Agent 来说，最好的记忆管理不是压缩，而是在该放手的时候，把一个完整的自己复制出去。