# Athanor：自维持的代理工作流编排器，用对抗规划重塑AI协作 > Athanor是Claude Code的插件，通过薄领导者架构和双模型对抗规划，实现自学习、自维持的智能工作流编排。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-04-08T14:15:42.000Z - 最近活动: 2026-04-08T14:23:03.466Z - 热度: 157.9 - 关键词: AI工作流, Claude Code插件, 对抗规划, 薄领导者架构, 自学习系统, 任务编排, 多代理协作 - 页面链接: https://www.zingnex.cn/forum/thread/athanor-ai - Canonical: https://www.zingnex.cn/forum/thread/athanor-ai - Markdown 来源: ingested_event --- # Athanor：自维持的代理工作流编排器\n\n在AI辅助编程工具日益普及的今天，如何构建一个真正智能、可持续进化的工作流系统？**Athanor**项目给出了一个令人耳目一新的答案。这个Claude Code插件并非简单堆砌功能，而是通过精巧的架构设计，让AI系统在使用过程中不断学习和成长。\n\n## 项目背景与核心理念\n\nAthanor的名字源自炼金术中的"贤者之炉"——一种传说中能够自我维持、永恒燃烧的熔炉。这个隐喻完美诠释了项目的核心追求：**构建一个能够随着使用而变得更智能的工作流编排系统**。\n\n传统AI工具往往面临两大困境：一是主会话上下文不断膨胀，导致性能衰减；二是规划质量受限于单一模型的能力边界。Athanor通过创新的"薄领导者架构"和"对抗式规划"机制，同时解决了这两个问题。\n\n## 架构设计：薄领导者与任务分发\n\nAthanor最核心的设计哲学是：**主会话（领导者）绝不直接执行工作**。领导者只负责三件事：\n\n1. **解析用户输入**——理解用户想要什么\n2. **分发任务给工作代理**——将工作派发给专门的子代理\n3. **收集结果简报**——汇总各代理的成果\n4. **向用户展示输出**——呈现最终结果\n\n这种设计确保了无论会话持续多久，领导者的上下文始终保持精简。所有实际工作都在独立的子代理中完成，每个代理都拥有干净的上下文环境。\n\n### 专用代理角色分工\n\nAthanor定义了七种专用代理，各司其职：\n\n| 代理名称 | 使用模型 | 核心职责 |\n|---------|---------|---------|\n| researcher | sonnet | 头脑风暴研究+魔鬼代言人视角 |\n| analyst | sonnet | 快速并行分析 |\n| planner | opus | 实施方案规划 |\n| critic | opus | 方案综合与评审 |\n| executor | sonnet | 代码执行与验证循环 |\n| learner | sonnet | 会话学习提取 |\n| cleaner | haiku | 记忆衰减与清理 |\n\n## 对抗式规划：双模型交叉评审\n\nAthanor最具创新性的设计是其**对抗式规划流程**。当需要制定复杂计划时，系统会启动两条独立的规划路径：\n\n```\n输入 ───┬──→ Planner A（标准方案）──→ Reviewer B评审 ──┐\n │ ├──→ Critic综合 → 最终方案\n └──→ Planner B（反向方案）──→ Reviewer A评审 ──┘\n```\n\n两个独立的规划器（Planner A和Planner B）分别生成方案，然后互相评审对方的工作，最后由Critic代理综合两个方案的优点，生成最终执行计划。这种"红蓝对抗"机制显著提升了规划质量，因为单一模型难以同时兼顾创新性和严谨性。\n\n## 五阶段工作流\n\nAthanor将整个工作流程划分为五个明确的阶段，形成一条清晰的决策链：\n\n1. **/athanor:discuss** —— 决策头脑风暴（"做什么？"）\n2. **/athanor:analyze** —— 并行快速分析（"在哪里做？"）\n3. **/athanor:plan** —— 跨模型对抗规划（"怎么做？"）\n4. **/athanor:work** —— 任务清单执行（"动手做"）\n\n前三个阶段都属于"规划模式"，此阶段不会修改任何文件。只有进入/athanor:work阶段后，系统才会开始实际执行。这种显式的模式分离有效防止了意外修改。\n\n## 自学习机制：经验积累与记忆管理\n\nAthanor最令人印象深刻的能力是其**自学习机制**。每次/athanor:work会话结束后：\n\n- **Learner代理**分析执行结果，提取结构化的经验教训\n- **Cleaner代理**应用记忆衰减策略（基于时间+访问次数）\n- **未来代理**自动读取相关的历史经验\n\n记忆采用双层模型管理：\n\n- **永久层**：架构决策、关键模式——永不删除\n- **工作层**：任务特定细节——自动清理\n\n这意味着随着使用时间的增长，Athanor会越来越"了解"你的项目和工作习惯，提供越来越精准的建议。\n\n## 执行模式：串行与并行\n\nAthanor支持两种任务执行模式：\n\n**串行执行（Solo模式）**：一次执行一个子任务，每个都在干净的上下文中运行。适合任务间有强依赖关系的场景。\n\n**并行执行（Team模式）**：基于依赖关系将子任务分组为"波次"，同一波次的任务并行执行，波次之间通过"发现中继"传递信息。\n\n```\n波次1: [任务1, 任务2] ← 并行执行，无依赖\n ↓ 发现中继\n波次2: [任务3] ← 依赖波次1\n ↓ 发现中继\n波次3: [任务4] ← 依赖波次2\n```\n\n## 会话持久化与文件组织\n\n所有阶段间的通信都通过`.athanor/sessions/{id}/`目录下的Markdown文件进行：\n\n```\n.athanor/\n├── sessions/\n│ └── 2026-04-08-001/\n│ ├── research-a.md ← 研究员发现（中间产物）\n│ ├── research-b.md ← 魔鬼代言人发现（中间产物）\n│ ├── discuss.md ← 头脑风暴综合\n│ ├── analyze.md ← 分析报告\n│ ├── plan-claude.md ← 方案A\n│ ├── plan-codex.md ← 方案B（反向）\n│ ├── review-of-claude.md ← 对方案A的评审\n│ ├── review-of-codex.md ← 对方案B的评审\n│ ├── plan.md ← 最终合并方案+子任务\n│ ├── decisions.md ← 决策日志\n│ ├── work-log.md ← 执行进度\n│ └── discoveries/ ← 代理发现\n└── lessons/ ← 习得的经验（自动管理）\n └── work-2026-04-08-001.md\n```\n\n这种文件化设计使得整个思考过程可追溯、可审计，也为后续的经验提取提供了结构化数据源。\n\n## 配置与扩展性\n\nAthanor通过项目根目录的`athanor.json`文件进行配置，支持丰富的自定义选项：\n\n- **codex.enabled**：是否启用Codex进行跨模型规划\n- **work.defaultMode**：默认执行模式（solo或team）\n- **work.ralphLoop.maxRetries**：每个子任务的最大验证重试次数\n- **work.circuitBreaker.consecutiveFailures**：熔断器触发前的连续失败次数\n- **team.waveSize**：每波次最大并行工作代理数\n- **memory.decayDays**：工作记忆保留期\n- **memory.promotionThreshold**：自动提升为永久记忆的访问次数阈值\n\n## 使用场景与价值\n\nAthanor特别适合以下场景：\n\n1. **复杂多步骤任务**：需要深思熟虑、多方案比较的工程决策\n2. **长期项目维护**：通过经验积累，让AI助手逐渐理解项目架构和约束\n3. **高质量代码审查**：对抗式规划天然适合发现潜在问题\n4. **团队协作**：清晰的阶段划分和文件化沟通便于多人协作\n\n## 总结与展望\n\nAthanor代表了AI辅助工具向"自维持系统"演进的重要尝试。它不仅仅是一个功能插件，更是一种关于如何让AI系统持续学习和进化的方法论。\n\n其核心价值在于：**通过架构设计而非模型能力提升来优化AI协作体验**。薄领导者架构解决了上下文膨胀问题，对抗式规划突破了单一模型的能力边界，自学习机制让系统具备持续进化的可能。\n\n对于追求高质量AI辅助的开发者而言，Athanor提供了一个值得深入探索的新范式。