管理者模式的实践案例

书籍翻译为什么必须用管理者模式？

• 任务特性: 翻译一本技术书籍不只是语言转换，还要保证专业术语全书一致、语境准确、整体阅读流畅;
• 术语一致性要求: 大量术语反复出现且可能有多种约定俗成的说法，例如第一章把 agent 译为"智能体"，后面就不能改成"代理";
• 单 Agent 的上下文问题: 全书术语表、已翻译章节、当前段落、翻译思考过程、工具调用结果不断累积，几百页技术书籍加中间产物很容易超出上下文窗口;
• 长上下文的额外危害: Agent 容易"迷失"——忘记之前的术语约定，到第九章用了与第二章不一致的译法；审校阶段重复检查浪费资源；注意力分散而产生幻觉，"记起"实际上并不存在的术语规则;

书籍翻译的角色如何分工？

Agent	输入	产出	上下文特征
Glossary Agent	全书内容	结构化术语对照表（JSON/CSV：英文术语、中文翻译、词性、使用语境）	只看术语提取所需内容，完成后销毁释放资源
Translation Agent	当前章节、术语对照表、翻译指南（目标读者水平、语言风格）	译文章节文件（如 chapter1_zh.md）	每个实例在独立上下文中工作，互不干扰；可并行或串行启动多实例
Proofreading Agent	所有译文与术语表	审校报告	需访问全文但只关注一致性检查
Manager Agent	任务描述、执行计划、调用记录、进度状态、文件索引	最终交付与发回修订的决策	不保存完整翻译内容，只维护文件索引

• Manager 的成本控制: 根据审校报告可以把特定章节发回 Translation Agent 修订;
• 关键优势: 上下文隔离——每个 Agent 都在精简、专注的上下文中工作，效率更高、出错可能性更低，不会因信息过载而分散注意力;
• 与文件系统的配合: 产物经共享空间交换、路径即接口，见 Agent 的虚拟文件系统;

灵台如何把管理者模式产品化？

• 定位: 一个本地运行、以文件为本的长期 Agent 居所，三种角色构成完整实现;
• 主器灵（main agent）: 与用户对话的常驻中枢，掌管计划与记忆，把工作派生给其他角色，对应 Manager Agent 的位置;
• 分神（daemon）: 为一件嘈杂而有界的工作分出的短时并行工作者，完成后即弃，只把结论带回主器灵，对应"子 Agent 返回结构化摘要而非全量轨迹"与并行协调形态;
• 分身（avatar）: 拥有自己的记忆、邮箱与职责的持久专门化队友，用于值得跨多次会话保留的专业分工;
• 知识: 每个器灵私有的持久记忆文件;
• 技能: 所有器灵共享的 Markdown 手册;
• 凝蜕（molt）: 上下文窗口将满时，器灵给自己写一份总结，带着持久记忆在干净上下文中继续工作，对应上下文压缩;
• 可替换性: 底层模型可以替换而器灵犹在;
• 核心口号: "器灵即其文件"——身份、记忆与能力都以普通文件形式存放在项目目录中;

管理者如何把工作流写成代码？

• 动机: 顺序与并行形态里 Manager 始终待在循环中，每派发一个子任务都要模型做一次决策，上下文随调用次数增长;
• 替代做法: 管理者先把 Agent 工作流写成一段代码，再交给确定性的运行时去执行;
• 实例: Claude Code 内置的 Workflow 工具给 Agent 提供 agent()、parallel()、pipeline() 几个原语;
• 约定: 每个 agent() 是一个拥有独立上下文的子 Agent，schema 约定它只返回结构化结论而不是完整轨迹;
• 示例代码（为一篇技术稿件核实七组事实：每组先调研，再逐条独立核实，最后统一汇总）:

const results = await pipeline(
  DIMENSIONS, // 七个待核实的方向
  (d) => agent(research(d), { schema: FINDINGS }), // 阶段一：调研
  (r) =>
    parallel(
      r.findings.map(
        (f) => () =>
          // 阶段二：逐条独立核实
          agent(verify(f), { schema: VERDICT }),
      ),
    ),
);
await agent(writeProvenance(results.flat())); // 汇总：等齐所有结果

• 效果: 编排决策从每轮模型推理变成外层的图结构，上下文增长与调用次数解耦;