Agent on 姚玉亮的网络日志

对话编排层重构：从 Go 业务编排迁移到 Python LangGraph

Wed, 02 Sep 2026 20:00:00 +0800

一条报数指令暴露的问题

炼丹炉（Alchemy Furnace，我的开源项目）的群聊里，我发过这样一条指令：

1

@全体成员 全体都有！报数！

预期很明确：A、B、C、D 四个道人按顺序报 1、2、3、4。实际跑起来，它被当成了闲聊：有时只让一个人接话，有时人设和记忆指令还能把硬指令覆盖掉，报数报成了自由发挥。

这不是一个偶发 bug，是一类问题的缩影：当编排逻辑长在业务代码里，“确定性指令"和"开放对话"就没有边界。群聊调度全部写在 Go 网关里，意图分类、发言人选择、轮次策略和业务逻辑缠在一起，每加一个编排能力都要改 Go、编译、发布，而编排恰恰是整个产品里变化最快的部分。

于是我做了这次架构迁移：把提示词构建、群聊调度和模型调用编排，整体从 Go 迁到 Python LangGraph，形成「Go 负责数据与 CRUD，Python 负责智能编排」的分层。

Go 在变成 Agent 框架

迁移前炼丹炉是双后端：Go 网关（Gin）+ Python 引擎（FastAPI）。这个结构本身没问题，问题在于群聊上线后，Go 里长出了第三种性质的职责。

一轮群聊对话，Go 实际在做三件事：

数据：会话、消息、道人、金丹、记忆、模型的存储与 CRUD，凭据加密，这是 Go 的本行
协议：对前端的 SSE 流、内部服务调用，是稳定的契约面
智能编排：意图分类、发言人选择、提示词拼装、模型调用、轮次与收敛策略，这部分高频变化、需要快速实验

第三类和前两类完全不是一种东西。编排层需要的是图结构、状态机、检查点、可恢复执行、结构化输出校验，这些 LangGraph 生态里全是现成的，Go 里全要手写。让一个后端语言慢慢长成一个 Agent 框架，才是最贵的路线。

分层：Go 管什么，Python 管什么

迁移后的职责边界：

职责	归属
认证、请求校验、凭据加密存储	Go
会话/消息/道人/金丹/记忆/模型的存储与 CRUD	Go
正式消息落库（只在 `assistant_final` 之后，按 run_id 幂等）	Go
内部事件 → 前端 SSE 的翻译	Go
单聊/群聊路由	Python LangGraph
指令分类、确定性路由	Python
Supervisor 计划、发言人调度、收敛	Python
提示词构建、模型调用、重试	Python
记忆检索策略与记忆提案	Python 提案 → Go 校验落库

说白了：Go 不再选择发言人、不再分类对话意图、不再拼 prompt，也不再管轮次策略。前端仍然只调 Go、只消费 Go 的 SSE。对前端来说契约没变，变的是 SSE 背后的调度从 Go 挪进了图里。

边界里我最在意的一条：凭据不进图状态。API key、解密后的凭据走 LangGraph 的 context_schema（RuntimeContext：模型网关、凭据、调试开关、取消旗标），与图状态彻底分离：它们绝不进入图状态、SQLite checkpoint、对外事件和日志。图状态里只有快照：历史、道人、金丹、记忆、模型引用，都是 Go 在发起一轮 run 时传进来的不可变快照。

图架构：一张会话图，一张可复用的道人图

整个编排是四层图，顶层一张会话图：

flowchart TD
 A["ConversationGraph（一次用户轮入口）"] --> B["hydrate_context"] --> C["route_session"]
 C --> D["SingleChatGraph"] --> D1["DaoistGraph（复用子图）"]
 C --> E["GroupChatGraph"] --> F["classify_directive"]
 F --> G["deterministic_router（确定性指令）"]
 F --> H["supervisor（开放讨论出计划）"]
 G --> I["dispatch_daoists"]
 H --> I
 I --> J["DaoistGraph × N"]
 I --> K["convergence 收敛"]
 K --> L["propose_memory 记忆提案 → Go 校验落库"]

关键设计是 DaoistGraph 作为可复用子图：单聊直接调它，群聊每个发言人各自子运行一张。单聊和每个群成员走的是同一条 prompt 构建 + 模型调用管线：选定记忆、编译人设与金丹行为、调模型、校验响应、流出事件。这一条保证了"行为可解释”：单聊什么效果，群聊里同一个道人就是什么效果，不存在两套 prompt 逻辑。

群聊图里的路由是有讲究的：classify_directive 先分类这一轮用户输入，确定性指令走 deterministic_router 直接成计划，开放讨论才走 supervisor 让模型出计划，这就是下一节的内容。

混合导演：该调模型的调模型，不该调的绝不调

群聊调度我用的是混合导演策略，核心就一句：确定性的事情用代码，创造性的事情用模型。

确定性指令永不委托模型。直接 @某个成员、@全体成员、报数、停止/继续，这些必须在代码里走死路径。报数的实现是：路由器为每个成员构造一个不可变任务，里面写死序号；人设、记忆、闲聊风格规则只能影响语气，不能改数字、不能漏人、不能加戏、不能改顺序。报数这种事交给模型去"理解"，就是开头那个 bug 的根源。

开放讨论交给 Supervisor。这一轮该谁说话、按什么顺序、每人拿到什么任务、发言预算多少、要不要收束，由会话默认模型（非人设，不扮演任何道人）产出一份结构化计划。Supervisor 不可见、不写用户可见的文本，只出计划。它失败或产出无效计划时，确定性回退到被明确 @ 的成员或主成员，导演的错误不传染整轮。

这样分工还有个实际的好处：明确的群指令不花 Supervisor 的模型调用，单聊用被选中道人自己配置的模型。钱花在真正需要智能的地方。

可恢复执行：中断在发言人边界，续跑按差集

这是整个迁移里技术含量最高的部分，也是最值得抄的部分。

每个用户轮有全局唯一的 run_id，每条终稿回复有唯一 reply_id，Go 按这两个 ID 做落库幂等。LangGraph 侧用本地异步 SQLite checkpointer 做检查点。用户点停止、前端断连、进程重启，都要能恢复，而且恢复时不能重复已完成发言人的发言。

做法是把恢复粒度设计在发言人边界：dispatch 节点按计划逐个发言人在子图里跑，每个发言人之前先 await asyncio.sleep(0) 让出事件循环再查取消旗标：取消请求只能落在 await 点，这样中断恰好落在发言人之间的缝隙里，不会截断一条发到一半的回复。

续跑靠差集裁决。顶层检查点只携带「计划 + 已完成回复」，恢复重放时：

计划已存在 → 不重新规划、不重发 plan_created 事件
已完成的发言人 → 跳过，只在剩余差集上继续

其中藏着一个容易踩的坑，代码里的路由顺序：

1
2
3
4
5
6
7


def _route_after_router(state) -> Literal["dispatch", "supervisor", "end"]:
 if state.get("speaking_plan"):
 return "dispatch" # 续跑重放：计划已在，按差集续，不重规划
 kind = state["directive"]["kind"]
 if kind == "open":
 return "supervisor" # 首轮开放讨论：默认模型出计划
 return "end" # 停止/继续：控制指令，不产计划

这个判断顺序不能反。如果先看 kind，开放讨论在续跑重放时会误入 supervisor 再调一次模型；先看计划有无，重放才直接走 dispatch 按差集续跑。可恢复执行的全部难度就在这种毫厘之间：状态里每多带一个通道、路由里每换一个判断顺序，恢复语义就完全不同。

失败语义同样是发言人粒度：单个道人失败只跳过该发言人，不阻塞剩余计划成员；道人图内部对模型错误做最多 2 次机械重试；Supervisor 失败走确定性回退。三层兜底，任何一层的失败都不会把整轮炸掉。

迁移不是重写：feature flag + 一条真实的提交序列

迁移策略是增量推进，但结局只有一种实现：feature flag orchestration_engine=legacy|langgraph 是临时迁移控制，不是长期双引擎产品设置。验证通过后默认 LangGraph，短回滚窗口过后删掉 legacy。

真实提交序列（节选自仓库主干）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


docs: design LangGraph conversation orchestration ← 321 行设计文档
docs: plan LangGraph orchestration migration ← 873 行实施计划
build(python): add LangGraph runtime dependencies
feat(orchestration): define state and event contracts ← 状态/事件契约先行
feat(orchestration): add provider-aware model gateway
feat(orchestration): evolve speaking plan to ordered task items
feat(orchestration): route explicit group directives
feat(orchestration): add reusable Daoist graph
feat(orchestration): add hybrid group director
feat(orchestration): add resumable conversation graph
feat(orchestration): expose internal streaming API
feat(chat): persist orchestration runs idempotently

节奏是契约先行：状态、事件、模型网关先于任何图节点落地；图是一层一层长出来的（道人图 → 确定性路由 → 混合导演 → 可恢复）。整个编排包最终约 1900 行 Python，14 个文件。

验收有一条硬场景，就是开头那条报数：四个成员各回自己的序号，人设只能加语气，不能改数、不能漏人、不能加戏。这条过不了，迁移就不算完。

复盘

分层不是按语言划的，是按职责性质划的。数据是稳定的，编排是高频变化的。把变化最快的职责放进迭代最快的生态：LangGraph 的图结构、checkpointer、子图、结构化输出校验都是现成的，Go 里全要手写。
图的节点边界就是恢复边界。LangGraph 的检查点落在节点边界，所以节点怎么切，决定能从哪里恢复。想要发言人粒度的恢复，就得把调度切成发言人粒度的节点。
确定性与概率性分离，是 Agent 系统的地基。能写成代码的绝不调模型；需要模型的环节（Supervisor）只出可校验的结构化计划，失败可回退。开头那个报数 bug，本质就是没有这层分离。
契约先行让两端各自演进。11 个类型化事件 + run_id 幂等 + 快照式输入，Go 和 Python 之间只有契约没有纠缠；Go 仍然是数据的事实源，Python 在快照上做编排，记忆用提案-校验的方式回流。

这次重构真正的收益在后面：工具调用、人工审批中断（permission_required 事件已在契约里预留）、长任务规划、更复杂的多 Agent 协作，这些以后都是"在图里加节点"，不再需要动 Go。架构分层的意义不是当下的优雅，是把未来的变化留在了便宜的地方。

封面图：Creativity103 / Flickr · CC BY 2.0

Claude Code 的 Workflow 功能：6 任务分 4 波，多 Agent 并行开发三端功能

Thu, 27 Aug 2026 22:30:00 +0800

一个 141 行的脚本，指挥一群 AI 干活

炼丹炉（Alchemy Furnace，我的开源项目）最近在做一个大功能：女娲蒸馏的范围收紧 + Skill 导出。它横跨三个端（Next.js 前端、Go 网关、Python 引擎），拆出来 6 个开发任务，有依赖、有先后、还要并行。

我用的方案是 Claude Code 的 Workflow 功能：写一个 141 行的 mjs 脚本，把 6 个任务分成 4 个波次，每波派多个 AI Agent 并行干活。脚本开头长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


export const meta = {
 name: 'nuwa-scope-skill-export',
 description: '按计划实现女娲炼丹范围收紧 + Skill 导出（6 Task 分波并行）',
 phases: [
 { title: 'Wave A: 并行底座', detail: 'Task1 前端入口 + Task2 Python 链路 + Task3 Skill 渲染器' },
 { title: 'Wave B: 服务端接合', detail: 'Task2b Go/前端错误透传 + Task4 导出接口' },
 { title: 'Wave C: 前端导出 UI', detail: 'Task5 详情导出对话框' },
 { title: 'Wave D: 端到端验收', detail: 'Task6 全量回归与修复' },
 ],
}

Workflow 的编排原语就几个：agent() 派一个 Agent 做一件事，parallel() 并行跑一组，pipeline() 流水线，phase() 分阶段。流程是确定性的（脚本写死的），干活是并行的（agent 同时跑）：确定性编排 + 并行吞吐，这就是 Workflow 和"让 AI 自由发挥"最大的区别。

分波设计：依赖关系决定顺序

6 个任务不是一把梭全并行，它们之间有依赖。分波的核心原则：同一波内的任务互不依赖且文件隔离，波与波之间靠产物衔接。

Wave A 三个任务互不依赖：前端改入口、Python 改链路、Python 写渲染器，改动文件完全不重叠，并行跑。Wave B 接合服务端：错误透传要读 Task2 的产物（Python 结构化错误），导出接口要调 Task3 的渲染器，等 A 波完成再动。C、D 依此类推。

多 Agent 协调的六个细节

分波只是骨架，真正让 6 个 Agent 不打架的是这些细节：

COMMON 纪律注入。每个 Agent 的 prompt 都是 COMMON + TASK + 终止条件 三段拼起来的。COMMON 里写死硬约束：TDD 先红后绿、只改自己任务列出的文件、提交格式 type(scope): 中文描述、绝不 git add -A、绝不提交 docs/superpowers/ 和 specs/ 等元文档、i18n 必须中英双语、测试命令、凭据保密。纪律写进 prompt 而不是靠自觉，6 个 Agent 才不会互相污染。
文件隔离 + 以磁盘为准。每个任务只允许碰自己的文件，但并发任务可能改到同一文件，所以约束里有一条：“编辑前先 Read 磁盘最新内容，不要基于记忆”。并行和踩脚之间的平衡，靠这条纪律兜底。
依赖确认靠 git log。Wave B/C 的任务 prompt 里写着：“先 git log 确认依赖任务已完成，并读它的接口签名再动手”。Agent 之间不通信，通过提交记录对齐。
终止条件。每个任务都附一段 A3：文件不存在或结构差异巨大、关键依赖无法确认、测试连续 3 次修复失败，立即停止并报告，不许硬撑。这防止 Agent 在不确定的情况下编造"成功"。
TDD 是硬约束。每个任务第一步都是"写失败测试 → 跑红 → 最小实现 → 跑绿"。6 个 Agent 并行写代码，质量一致性靠测试框架兜底。
进度可视化。每波完成打一条 log()：task1=ok task2=FAILED，失败的任务肉眼可见，可以在下一波前人工干预。

三端是怎么被协调的

这个功能本身横跨三端，Workflow 的波次刚好和端的分工对齐：

端	技术栈	对应的任务
前端	Next.js	Task1 收紧女娲入口、Task5 导出对话框
Go 网关	Gin + GORM	Task2b 错误透传、Task4 导出接口
Python 引擎	FastAPI	Task2 蒸馏链路、Task3 Skill 渲染器

有意思的是 Python 端同时有 Task2 和 Task3 两个并行 Agent：它们文件不同（链路 vs 渲染器）所以不冲突，但同端并行也要求 prompt 里把边界写得特别清楚：“不要碰 backend/go/ 与 frontend/ 的 UI 文件——那些由另一任务负责”。

复盘：Workflow 教给我的

复杂功能先拆波再并行，依赖决定顺序。先画出任务依赖图，互不依赖的并行，有依赖的排波次。比"一个 Agent 从头做到尾"快得多，比"全并行"稳得多。
纪律要写进 prompt，不是靠提醒。提交纪律、文件边界、TDD、终止条件，每一条都防止一种 Agent 翻车方式。
终止条件比任务本身重要。允许 Agent 说"我卡住了"，比让它硬编一个成功报告安全一个量级。
上下文隔离是并行的前提。每个 Agent 只拿自己的任务片段，看不到其他任务的 prompt：专注 + 不越界。

这个脚本不是银弹：它适合任务边界清晰、文件可隔离、有测试兜底的场景。如果任务互相纠缠，先拆任务再谈并行。项目、计划文档和完整脚本都在 GitHub 上，Wave A 的并行底座写法可以直接抄。

封面图：richard_clyborne / Flickr · CC BY 2.0

智能体工作流编排：从知识库问答到多步任务

Tue, 02 Jun 2026 10:30:00 +0800

单轮 RAG 接不住了

知识库问答服务上线初期只有一条链路：用户提问 → 检索 → 拼 Prompt → 调 LLM → 返回答案。简单可控，但很快被顶到了天花板。

有人问"帮我查一下上个月引用量最高的三篇文献，对比它们的方法，再导出成 Word"。这一句话里藏着检索、排序、对比分析、文档生成四步，单轮 RAG 根本接不住。

我当时的判断是两头都不能走极端：全交给 ReAct 让模型自由发挥，可控性和成本都扛不住；全硬编码成固定 DAG，又失去了灵活性。最后落在一个折中上：工作流骨架 + Agent 节点。

一张图，两类节点

我把任务拆成两类节点：

确定性节点：检索、SQL 查询、文件解析、导出，这些用代码写死，输入输出明确
Agent 节点：需要推理、选择、总结的环节，交给 LLM 决定下一步

节点之间用有向图描述，允许条件分支和循环，运行时由一个轻量编排器驱动。每一步的状态写进统一的 WorkflowState，节点之间不直接耦合。

核心结构就这么多：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


type WorkflowState struct {
 Query string
 Documents []Document
 Draft string
 Artifact string
 Trace []StepRecord
 mu sync.Mutex
}

type Node interface {
 Name() string
 Run(ctx context.Context, st *WorkflowState) error
}

type Orchestrator struct {
 nodes map[string]Node
 edges map[string][]Edge // from -> edges
}

type Edge struct {
 To string
 Cond func(st *WorkflowState) bool // nil 表示无条件
}

func (o *Orchestrator) Run(ctx context.Context, start string, st *WorkflowState) error {
 queue := []string{start}
 visited := map[string]int{}
 for len(queue) > 0 {
 name := queue[0]
 queue = queue[1:]
 if visited[name] >= 5 { // 防止死循环
 return fmt.Errorf("node %s exceeded max retries", name)
 }
 visited[name]++
 if err := o.nodes[name].Run(ctx, st); err != nil {
 return err
 }
 for _, e := range o.edges[name] {
 if e.Cond == nil || e.Cond(st) {
 queue = append(queue, e.To)
 }
 }
 }
 return nil
}

Agent 节点内部走 ReAct 循环：模型输出思考 + 工具调用，执行工具后把结果喂回去，直到给出最终答案或触发步数上限。工具调用走 MCP，上一篇讲过。拿"查文献→对比→导出"来说，检索和导出是确定性节点，中间的对比分析交给 Agent 节点。

四个坑

第一个坑，state 越攒越肥。一开始我们把所有中间结果都塞进 WorkflowState，跑到后面堆满文档全文和历史消息，token 直接爆炸。后来立了规矩：节点只输出下一阶段需要的最小字段，长文本进对象存储，state 里只留 ID 和摘要。

第二个坑，循环没有刹车。LLM 偶尔会陷入"反复检索但不给出答案"的死循环。现在每个节点有最大重试次数，整图有总步数和总 token 预算，超限直接中断，返回当前最优结果，而不是无限烧钱。

第三个坑，没有 trace 就是瞎子。多步工作流出问题，不查 trace 根本说不清哪一步偏了。我们在每个节点进入/退出时写结构化日志（节点名、输入摘要、输出摘要、耗时、token 数），用 trace_id 串起来，在 Jaeger 里能看完整的节点瀑布图。代码里的 StepRecord 就是干这个的。

第四个不算坑，算一条划边界的原则：流程稳定、容错要求高的（支付、对账、数据同步）用确定性 DAG，甚至上 Temporal；探索性、开放式的任务（调研、写作、分析）用 Agent 节点。两者可以混在一张图里，但关键路径上的不可恢复操作，别让 Agent 碰。

后来

回头看，从单轮 RAG 走到多步工作流，是把"模型一次想清楚"换成了"系统分步兜底"：确定性节点负责可靠，Agent 节点负责灵活，编排器把两者粘起来，顺便守住成本和循环上限。

下一步我们在试把常用工作流做成模板，让业务方自己拖拽配置，不用每次都找后端写代码。

封面图：ell brown / Flickr · CC BY 2.0

合成提示词缓存：性格变化时的自动重建策略

Tue, 31 Mar 2026 10:30:00 +0800

每次对话都重新炼丹，太贵了

alchemy-furnace 里，每个分身（Agent）对话都要用它的合成 system prompt。这份 prompt 不是写死的，是炼出来的：跑一遍融合算子，先让 LLM 生成新的身份句，再让另一次 LLM 调用裁决冲突。也就是说，光"准备 prompt"这一步就是两次 LLM 调用，好几秒，几千 token。

而分身的人格在两次金丹更新之间是稳定的。每次对话都重算一遍，钱和延迟都花在重复劳动上。

那就加缓存。可缓存立刻带来那个经典难题：金丹会改，融合参数会调，算子会升级，缓存什么时候失效？失效太激进，等于没缓存；失效不及时，就出灵异 bug：我明明改了人设，Agent 还是老样子。

这篇讲我怎么处理这个矛盾。

让内容自己决定缓存

先说结论：失效判断不靠主动删除，靠内容寻址。

缓存的 value 是渲染好的合成 system prompt，外加工具定义和元数据。key 的主体是上一篇讲的 lineage_hash：它由父母金丹的 content_hash、算子名、算子版本、融合参数共同决定。任何一项变了，hash 就变，自然落到新 key 上，旧缓存根本没机会被错误命中。

key 长这样：

1

furnace:synth:{lineage_hash}

value 是一个 JSON：

1
2
3
4
5
6
7


{
 "system_prompt": "渲染后的完整 prompt",
 "tools": ["mcp.search", "mcp.calc"],
 "lineage_hash": "9f8e...",
 "built_at": "2026-03-30T10:12:33+08:00",
 "op_version": "v2"
}

缓存放 Redis，TTL 设 7 天。但因为 key 随内容走，实际很少等到 TTL：内容不变就一直命中，内容一变就写新 key，旧 key 靠 TTL 自然回收，不用写任何删除逻辑。

这里有个前提，也是整个设计里我最满意的一步：金丹更新是 versioned 的，不是原地改。一个分身引用的是 (elixir_id, version, content_hash)，金丹作者改人设，生成的是新版本，分身的 lineage_hash 随之变化，下次对话自动触发重建。“原地更新导致缓存判断复杂"这类问题，从根上就不存在了。

网关先查，引擎兜底

Go 网关在对话入口先查缓存，未命中才请求 Python 引擎：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


func (s *AgentService) BuildSystemPrompt(
 ctx context.Context, agent *Agent,
) (string, []string, error) {
 lineageHash := agent.LineageHash
 key := "furnace:synth:" + lineageHash

 // 1. 查 Redis
 if cached, err := s.rdb.Get(ctx, key).Result(); err == nil {
 var c PromptCache
 json.Unmarshal([]byte(cached), &c)
 metrics.CacheHit.Inc()
 return c.SystemPrompt, c.Tools, nil
 }

 // 2. 未命中，加载金丹，请求 Python 引擎合成
 elixirs, err := s.elixirRepo.LoadByAgent(ctx, agent.ID)
 if err != nil {
 return "", nil, err
 }
 result, err := s.furnaceCli.Synthesize(ctx, SynthesizeReq{
 Elixirs: elixirs,
 Operator: agent.Operator,
 Params: agent.FusionParams,
 OpVer: OP_VERSION,
 })
 if err != nil {
 return "", nil, err
 }

 // 3. 写缓存（SetNX 防并发重复写）
 payload, _ := json.Marshal(PromptCache{
 SystemPrompt: result.SystemPrompt,
 Tools: result.Tools,
 BuiltAt: time.Now(),
 })
 s.rdb.SetNX(ctx, key, payload, 7*24*time.Hour)

 return result.SystemPrompt, result.Tools, nil
}

Python 引擎侧，Synthesize 内部也有一层针对子调用的 LLM 结果缓存（比如身份句生成），key 更细：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


async def synthesize_identity(a: dict, b: dict) -> str:
 key = f"furnace:id:{a['content_hash']}:{b['content_hash']}:{OP_VERSION}"
 if cached := await redis.get(key):
 return cached

 prompt = IDENTITY_META_PROMPT.format(
 identity_a=a["identity"], identity_b=b["identity"],
 expertise_a=a["expertise"], expertise_b=b["expertise"],
 )
 result = await llm_client.complete(
 provider="deepseek",
 system=FURNACE_META_PROMPT,
 user=prompt,
 temperature=0.4, # 身份句用低温度求稳定
 )
 await redis.set(key, result, ex=7*24*3600)
 return result

身份句的 temperature 压到了 0.4，比融合的 0.7 低一截。因为它是命名、概括类的任务，低温度结果更稳，缓存命中也更稳：同一对输入反复炼出同一句话，缓存才有意义。

踩到的坑

第一个是缓存击穿。热门分身的缓存恰好过期那一瞬，大量请求同时未命中，全打到 Python 引擎和 LLM 上。用 singleflight（Go 侧）加 Redis SetNX 做双保险：同一时刻、同一个 lineage_hash，只放一个请求真正去合成，其余等结果。这跟我在统一认证中心里做 JWT 刷新防雪崩是同一个套路。

第二个是算子升级。OP_VERSION 是缓存 key 的一部分，改了算子逻辑（换渲染模板、加字段）就必须递增版本号，否则旧 prompt 会被错误复用。我把它做成引擎启动时的常量，改了算子忘改版本，code review 一眼能看出来。也考虑过对算子代码本身算 hash，但那会让无关的注释改动也触发全量失效，权衡之后用了显式版本号。

第三个是金丹软删除。作者删了金丹，可分身还在引用它。我不做物理删除，只标记 deleted_at；加载时发现金丹被删，直接报"分身依赖的金丹已下架”，而不是拿残缺的金丹重新合成，那样产出的人格跟缓存里的完全对不上，用户只会觉得莫名其妙。

第四个是要不要预热。加了个简单策略：分身创建或更新后，网关异步发一个预热请求，把 prompt 先算好写进缓存，用户第一次对话就不卡顿。预热失败不阻塞主流程，对话时按需重建就是了。

第五个是演示模式。DEMO_MODE 下数据全在内存，缓存也退化成内存 map，进程重启就清空。听起来像 bug，其实是期望行为：演示环境本来就不需要持久化。

后来

回头看，这套缓存做的事情就一件：把"失效判断"从主动删除变成内容寻址。金丹版本化、算子版本化、参数入 hash，内容一变 key 就变，旧值自然淘汰；配合 singleflight 防击穿、低温度稳定子任务、异步预热，“每次对话都炼丹"就变成了"只有人格真正变化时才炼丹”。

对用户的体感差异很直接：分身对话的首 token 延迟，基本退化成一次普通 LLM 调用，而不是一次完整的融合流程。

封面图：alexkerhead / Flickr · CC BY 2.0

多金丹融合：Promptbreeder 风格的变异算子与血统追溯

Mon, 16 Mar 2026 10:30:00 +0800

「请综合一下」是个坏主意

单个金丹是静态人格，但炼丹炉真正有意思的地方在"炼"：把多个金丹扔进炉子，产出一个兼具各方特质的新人格。我最初的实现很朴素，把几个金丹渲染成 prompt 拼在一起，让 LLM “综合一下”。结果非常糟糕：模型倾向于简单拼接，“你既是 A 又是 B 又是 C”，输出人格左右横跳；每次结果都不一样，没法复现，也说不清新人格到底继承了谁的什么特质。

我需要的是一套有结构的融合算子，而不是一句"请综合一下"。Promptbreeder 用进化算法搜索 prompt 的思路给了我启发：把融合看作一代进化，用 crossover 交换特质、用 mutation 产生变异，并且给每个产物记录血统（lineage）。

三类算子

我实现了三类核心算子：

Crossover（交叉）：取两个金丹，按字段维度交换、混合。语气维度（tone）取加权平均；原则（principles）按 priority 去重合并；示例（few_shots）各取若干；硬冲突字段（constraints）交给 LLM 裁决并记录理由。
Mutation（变异）：在一个金丹基础上做小幅扰动，强化某一维度的语气、替换一条 principle 的措辞、增删一条 constraint。变异幅度可控（mutation_rate），用来在已有满意人格附近做探索。
Ensemble（集成）：不合成单一 prompt，而是生成一个"委员会"人格，遇到问题先判断该由哪种专长主导，再调用对应子人格的风格回答。这个算子对专长差异大的金丹组合更稳。

每个融合任务的输出除了 system prompt，还有一份 lineage：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{
 "agent_id": "agt_xxx",
 "operator": "crossover",
 "parents": [
 {"elixir_id": 101, "version": 3, "hash": "a1b2..."},
 {"elixir_id": 205, "version": 1, "hash": "c3d4..."}
 ],
 "resolution_notes": [
 {"field": "max_length", "chose": "来自金丹A，因 priority 更高"},
 {"field": "humor", "chose": "加权平均 0.35"}
 ],
 "params": {"temperature": 0.7, "provider": "deepseek", "op_version": "v2"},
 "lineage_hash": "9f8e..."
}

lineage_hash 是对 parents 的 hash、算子名、参数、算子版本做的 sha256，唯一标识这次"血统组合"。相同输入相同参数重跑会命中缓存（下一篇讲），也能用来判断两个分身是否同源。

crossover：语气加权，原则去重

Crossover 算子（Python 引擎侧）的核心逻辑：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


import random, statistics

def crossover_operator(elixirs: list[dict], rate: float = 0.5) -> str:
 assert len(elixirs) >= 2
 a, b = elixirs[0], elixirs[1]

 # 语气：加权平均（priority 高的权重大）
 wa = a.get("priority", 100)
 wb = b.get("priority", 100)
 total = wa + wb
 tone = {}
 for k in ("formality", "conciseness", "humor", "empathy"):
 va = a.get("tone", {}).get(k, 0.5)
 vb = b.get("tone", {}).get(k, 0.5)
 tone[k] = round((va * wa + vb * wb) / total, 2)

 # 原则：按 priority 排序去重合并
 principles = dedup_merge(
 a.get("principles", []),
 b.get("principles", []),
 )

 # 示例：各取一半
 few_shots = (a.get("few_shots", [])[:2] +
 b.get("few_shots", [])[:2])

 # 硬冲突：交给 LLM 裁决（这里简化为取 priority 高者）
 constraints, notes = resolve_constraints(a, b)

 child = {
 "identity": synthesize_identity(a, b), # LLM 生成新身份句
 "expertise": list({*a["expertise"], *b["expertise"]}),
 "tone": tone,
 "principles": principles,
 "constraints": constraints,
 "few_shots": few_shots,
 "tools": list({*a.get("tools", []), *b.get("tools", [])}),
 }
 return render_elixir(child)

mutation：小步扰动

Mutation 算子，只动一个金丹：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


def mutate_operator(elixir: dict, rate: float = 0.3) -> str:
 child = copy.deepcopy(elixir)
 # 随机扰动一个语气维度
 if random.random() < rate and child.get("tone"):
 key = random.choice(list(child["tone"].keys()))
 delta = random.uniform(-0.2, 0.2)
 child["tone"][key] = round(
 min(1.0, max(0.0, child["tone"][key] + delta)), 2)

 # 随机替换一条 principle 的措辞（交给 LLM 改写）
 if random.random() < rate and child.get("principles"):
 idx = random.randrange(len(child["principles"]))
 child["principles"][idx] = llm_rewrite_principle(
 child["principles"][idx])

 child["version"] = child.get("version", 1) + 1
 return render_elixir(child)

血统在任务完成时落账

血统记录在任务完成时统一构建：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


def build_lineage(elixirs, operator, params, notes):
 parents = [{"elixir_id": e["id"], "version": e["version"],
 "hash": e["content_hash"]} for e in elixirs]
 payload = {
 "parents": parents, "operator": operator,
 "params": params, "op_version": OP_VERSION,
 }
 lineage_hash = hashlib.sha256(
 json.dumps(payload, sort_keys=True).encode()).hexdigest()
 return {**payload, "resolution_notes": notes,
 "lineage_hash": lineage_hash}

四个坑

交叉不是简单拼接。第一版我直接把两个金丹的 principles 列表 concat，结果 prompt 里出现自相矛盾的两条原则。后来加上 dedup_merge：先用 embedding 相似度去重（数据集管理服务里做向量化那套直接复用），再让 LLM 对剩余冲突逐条裁决。去重这一步很关键，两个"意思一样但措辞不同"的原则就靠它合并掉。

变异太大也会跑偏。mutation_rate 设到 0.5 以上时，产物几乎认不出祖先。我默认用 0.2~0.3，每次变异只动一到两个字段，保住"可辨识的连续性"。这跟遗传算法里探索与利用的权衡是一回事。

Ensemble 有代价。委员会人格每次回答要先做一次路由判断（“这个问题该谁主导”），多一次 LLM 调用，延迟和成本都更高。所以它只在金丹专长差异度（expertise 的 Jaccard 距离）超过阈值时作为默认算子，否则用 crossover。

血统要防篡改。lineage 是用户判断"这个分身靠不靠谱"的依据，所以 lineage_hash 连同产物一起落库，Go 网关读取时校验 hash，防止有人手动改 parents 冒充血统。

后来

多金丹融合的关键是用结构化算子控制组合过程，用血统记录保证可解释、可复现。有了这套机制，炼丹就从开盲盒变成了一个可以迭代、可以追溯的工程过程。下一篇讲怎么基于血统做合成提示词缓存。

封面图：Flocci Nivis / Wikimedia Commons · CC BY 4.0

结构化技能包：把 Agent 人格特质封装为可复用模块

Sat, 28 Feb 2026 10:30:00 +0800

十几份 prompt 改不动了

在知识库问答服务项目里，我们最初给企业客户定制 Agent，就是改一段 system prompt：开头写"你是一个 XX 助手"，中间堆语气要求，结尾补几条禁忌。维护起来非常痛苦：客户 A 要"学术严谨"，客户 B 要"活泼亲切"，两份 prompt 八成内容重复，改一处公共措辞要同步十几份。更糟的是，prompt 写长之后，模型对后半段指令的遵循度明显下降，“必须用 markdown 表格回答"和"回答控制在三句话"这种约束经常被忽略。

做 alchemy-furnace 时我决定从根上换个思路：不把人格写成一段散文，而是拆成结构化字段，每个字段职责明确，最终 prompt 由程序拼装。这就是金丹（Elixir）技能包。

人格拆成一组字段

一个金丹是一份版本化的结构化文档，核心字段包括：

identity：身份设定，一句话（“你是一位资深 Go 后端工程师”）。
expertise：专长标签数组，用于检索和融合权重（["Go","分布式","RAG"]）。
tone：语气维度的结构化打分（formality: 0.8, conciseness: 0.6, humor: 0.2），而不是"既专业又亲切"这种模糊描述。
principles：行为原则列表，每条是一句可执行指令（“回答前先判断问题属于哪一层：协议/框架/业务”）。
constraints：硬约束（max_length、forbidden_topics、must_use_markdown）。
few_shots：示例对话数组，结构化存 input/output，而不是埋在正文里。
tools：允许调用的工具白名单（对应 MCP / function calling）。
priority 与 conflicts_with：融合时的优先级和冲突声明。
version 与 content_hash：版本和内容指纹，用于缓存和血统。

这个结构的关键在于，它既是给 LLM 看的（可渲染成 prompt），也是给程序看的（可校验、可 diff、可融合）。渲染逻辑由引擎统一控制，用户只填字段，不直接写整段 prompt。

渲染归引擎，用户只填字段

Go 侧的结构体和 GORM 模型（简化版）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


type Elixir struct {
 ID int64 `gorm:"primaryKey;autoIncrement:false" json:"id"` // snowflake
 Name string `gorm:"size:128;not null" json:"name"`
 Version int `gorm:"not null;default:1" json:"version"`
 Identity string `gorm:"type:text" json:"identity"`
 Expertise StringSlice `gorm:"type:json" json:"expertise"`
 Tone ToneSpec `gorm:"type:json" json:"tone"`
 Principles StringSlice `gorm:"type:json" json:"principles"`
 Constraints Constraints `gorm:"type:json" json:"constraints"`
 FewShots []FewShot `gorm:"type:json" json:"few_shots"`
 Tools StringSlice `gorm:"type:json" json:"tools"`
 Priority int `gorm:"default:100" json:"priority"`
 ConflictsWith StringSlice `gorm:"type:json" json:"conflicts_with"`
 ContentHash string `gorm:"size:64" json:"content_hash"`
 CreatedAt time.Time `json:"created_at"`
}

type ToneSpec struct {
 Formality float64 `json:"formality"` // 0~1
 Conciseness float64 `json:"conciseness"`
 Humor float64 `json:"humor"`
 Empathy float64 `json:"empathy"`
}

渲染成 prompt 的函数放在 Python 引擎侧，因为这块会随模型表现频繁调：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


def render_elixir(e: dict) -> str:
 parts = [f"# 身份\n{e['identity']}"]

 if e.get("expertise"):
 parts.append("# 专长\n" + "、".join(e["expertise"]))

 tone = e.get("tone", {})
 tone_line = []
 if tone.get("formality", 0) >= 0.7: tone_line.append("措辞正式严谨")
 if tone.get("conciseness", 0) >= 0.7: tone_line.append("回答简洁，避免铺垫")
 if tone.get("humor", 0) >= 0.5: tone_line.append("可适度幽默")
 if tone_line:
 parts.append("# 语气\n" + "；".join(tone_line))

 if e.get("principles"):
 parts.append("# 行为原则\n" +
 "\n".join(f"- {p}" for p in e["principles"]))

 c = e.get("constraints", {})
 if c:
 cons = []
 if c.get("max_length"): cons.append(f"回答不超过 {c['max_length']} 字")
 if c.get("must_use_markdown"): cons.append("使用 Markdown 排版")
 for t in c.get("forbidden_topics", []):
 cons.append(f"禁止讨论：{t}")
 if cons:
 parts.append("# 硬性约束\n" + "\n".join(f"- {x}" for x in cons))

 if e.get("few_shots"):
 shots = ["# 示例"]
 for i, fs in enumerate(e["few_shots"], 1):
 shots.append(f"## 示例 {i}\n用户：{fs['input']}\n助手：{fs['output']}")
 parts.append("\n".join(shots))

 return "\n\n".join(parts)

content_hash 在入库时计算，用 sha256 对规范化后的 JSON 取摘要。任何字段改动都会让 hash 变化，这是后面缓存失效和血统追溯的基础。

四个权衡

字段过多会吓退用户。第一版我设计了二十多个字段，结果自己填都嫌烦。后来把字段分成必填（identity、expertise、principles）和可选（tone、few_shots、tools），前端编辑器用折叠面板：普通用户只看必填三项，高级用户再展开 tone 滑块和 few-shot 编辑器。

结构化会损失表现力。有些人格特质确实很难用字段表达，比如"那种老北京茶馆里提笼架鸟的松弛感”。我的折中是保留一个 style_notes 自由文本字段，但明确标注它权重低于结构化字段、仅作补充，渲染时放在最后。让模型既吃结构化的硬指令，又留一点自由发挥的空间。

few-shot 存哪里。示例对话可能很长，全塞 MySQL 的 JSON 字段会让行膨胀。短示例直接存库；长附件（比如整段对话日志）存 S3，Elixir 里只留 few_shot_refs 引用，渲染前由引擎批量拉取。这跟我在数据治理服务里做 S3 预签名上传是同一套思路。

版本与克隆。金丹一旦被某个分身引用就不可原地修改，改动要新建 version，旧分身继续引用旧版本。否则就会出现"我没改 prompt，怎么 Agent 性格变了"的灵异问题。

后来

把人格从一段大 prompt 重构成结构化技能包，等于把提示词工程拉回了软件工程：字段就是接口，渲染是内部实现，版本和 hash 负责可复现。复用、diff、融合、缓存这些在散文 prompt 上几乎做不了的事，到这里都变自然了。金丹这一层立住了，多金丹融合才有可靠的输入。

封面图：karen horton / Flickr · CC BY 2.0

炼丹炉 alchemy-furnace：多人格融合 Agent 系统设计

Wed, 28 Jan 2026 10:30:00 +0800

在 system prompt 里堆人设，撑不住

做知识库问答服务的时候我发现一个现象：用户并不满足于跟一个"通用助手"对话，他们想要更具体的东西，比如一个既懂学术写作、又会写 Go、还带点毒舌的混合体。直接的思路是在 system prompt 里塞几段人设。我试过，效果很不稳定：不同人格的指令会互相打架，模型经常只"记住"最后一段。

我想要的是一个能把多个人格像炼丹一样"熔"在一起的系统：每个人格是结构化的、可复用的；融合过程可追溯、可演化；最终产物本身也是一个能独立调用的 Agent。alchemy-furnace（炼丹炉）就是干这个的，开源在 github.com/yusanwen-code/alchemy-furnace。

金丹、丹炉、分身

整体分三层，领域对象直接用炼丹的隐喻命名：

金丹（Elixir）：一个结构化技能包，封装一个人格的全部特质，身份、语气、专长、约束、示例对话、禁用词都在里面。它是融合的最小单位。
丹炉（Furnace）：融合引擎，接收一组金丹，按策略生成一个新的合成人格。合成过程借鉴 Promptbreeder 的变异算子，支持 crossover、mutation 和 lineage 追溯。
金丹分身（Agent）：融合产物，持有一份合成后的 system prompt 和一组工具定义，通过 OpenAI 兼容协议对外提供对话。

技术栈我做了明确切分：Go（Gin + GORM）做网关和业务编排，Python（FastAPI）做合成与 LLM 调用，Next.js 做前端。为什么这么切，后面单独一篇讲。

数据模型上，金丹、融合任务、合成产物是独立实体。融合任务会记下 parent_elixir_ids、mutation_operators、lineage_hash，任何一个合成人格都能回溯到它的"祖先"。

Go 网关侧的关键入口大致是这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


// FusionController 触发一次炼丹
type FusionController struct {
 fusionSvc FusionService
 furnaceCli FurnaceClient // Python 合成引擎
}

func (c *FusionController) Fuse(ctx *gin.Context) {
 var req FusionRequest
 if err := ctx.ShouldBindJSON(&req); err != nil {
 ctx.JSON(400, gin.H{"error": err.Error()})
 return
 }

 // 1. 加载金丹（技能包）
 elixirs, err := c.fusionSvc.LoadElixirs(ctx, req.ElixirIDs)
 if err != nil {
 ctx.JSON(404, gin.H{"error": "elixir not found"})
 return
 }

 // 2. 提交到 Python 丹炉
 job, err := c.furnaceCli.Submit(ctx, FurnaceJob{
 Elixirs: elixirs,
 Strategy: req.Strategy, // crossover / mutate / ensemble
 Provider: req.Provider, // deepseek/qwen/zhipu/kimi/...
 Temperature: req.Temperature,
 LineageParent: req.ParentAgentID,
 })
 if err != nil {
 ctx.JSON(502, gin.H{"error": "furnace unreachable"})
 return
 }

 // 3. 异步落库，前端 SSE 订阅进度
 ctx.JSON(202, gin.H{"job_id": job.ID, "status": "queued"})
}

元指令：让模型当设计师，不当演员

Python 侧的合成引擎是核心。一个融合任务的骨架如下（FastAPI + 异步）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


from fastapi import FastAPI, BackgroundTasks
from pydantic import BaseModel
import asyncio, uuid, hashlib

app = FastAPI()
_jobs: dict[str, "FusionJob"] = {}

class FurnaceJob(BaseModel):
 elixirs: list[dict]
 strategy: str
 provider: str
 temperature: float = 0.8
 lineage_parent: str | None = None

@app.post("/v1/furnace/fuse")
async def submit_fusion(job: FurnaceJob, bg: BackgroundTasks):
 job_id = str(uuid.uuid4())
 _jobs[job_id] = FusionJob(id=job_id, status="queued")
 bg.add_task(run_fusion, job_id, job)
 return {"job_id": job_id}

async def run_fusion(job_id: str, job: FurnaceJob):
 state = _jobs[job_id]
 try:
 state.status = "synthesizing"
 # 根据策略选择算子
 if job.strategy == "crossover":
 prompt = crossover_operator(job.elixirs)
 elif job.strategy == "mutate":
 prompt = mutate_operator(job.elixirs[0])
 else:
 prompt = ensemble_operator(job.elixirs)

 state.status = "calling_llm"
 synthesized = await llm_client.complete(
 provider=job.provider,
 system=FURNACE_META_PROMPT,
 user=prompt,
 temperature=job.temperature,
 )

 lineage = build_lineage(job.elixirs, job.strategy, synthesized)
 state.result = {"system_prompt": synthesized, "lineage": lineage}
 state.status = "done"
 except Exception as e:
 state.status = "failed"
 state.error = str(e)

这里的 FURNACE_META_PROMPT 是丹炉本身的元指令，它告诉 LLM：“你不是在扮演任何一个人格，你是在把这些人格特质融合成一个新的、内在一致的人格。“这段提示词是整个系统里最关键的一段。直接让模型"扮演混合体”，它会精神分裂；让它以人格设计师的第三人称视角去合成，输出要稳定得多。

三个坑

第一个坑是人格冲突。一个金丹要求"回答必须简短”，另一个要求"给出完整推导"，crossover 之后模型会左右横跳。后来我在金丹结构里加了 priority 和 conflicts_with 字段，融合前先做一次冲突检测：硬冲突直接拒绝并提示用户，软冲突交给 LLM 在合成阶段显式裁决，理由写进 resolution_notes。

第二个坑是融合结果不可复现。同一个组合跑两次，出来的人格可能差别很大。现在我把 temperature、provider、model_version、算子版本、输入金丹的 content_hash 全部记进 lineage，lineage_hash = sha256(...)。要复现就用同样参数重跑；碰到满意的结果，更好的办法是把它固化成新的金丹，而不是每次重新融。

第三个算权衡：要不要把合成逻辑放进 Go。Go 调 LLM 完全可行，但 Promptbreeder 那一套算子迭代快、实验性强，Python 生态（pydantic、各类 prompt 工具、后续可能接 LangGraph）更顺手。所以最后是 Go 做稳定的业务网关，Python 做易变的智能层，两边走内网 HTTP + 签名调用。

后来

回过头看，炼丹炉解决的核心问题是：把"人设 prompt"从一段不可维护的文本，升级为可组合、可演化、可追溯的结构化资产。这套抽象跑通之后，技能包复用、多金丹融合、缓存重建才有了落脚的地方。后面几篇我会分别展开三段式架构、技能包结构、变异算子、缓存和多供应商接入。