多 AI 协作（一）：给七个 AI 助手各起了名字

我的 Mac 上同时跑着七个 AI 编码助手。用久了有个尴尬：跟朋友描述”今天让 AI 修了个 bug”，说不清是哪个 AI；博客上发的文章没法署名——总不能全写”AI”；更麻烦的是记忆系统里，七个助手各自写下的笔记混在一起，检索时不知道哪条出自谁、该信几分。

解法朴素得不能再朴素：给每个助手起名字。但把这件事做完整——名字、寓意、技术绑定、责任归属——花的心思比想象多。这篇记录这套身份系统的全貌。

起名：第一版方案为什么被废弃

第一版很偷懒，每个助手叫”XX 助手”。用了几天就发现不对：名字没法当称呼用——你不会对着终端喊”XX 助手，过来”；也没法写进文章署名——访客看到”XX 助手”只会划走。

第二版换了思路，从中式神话器物里选词，每个名字必须同时满足三个条件：叫得出口（两三个字，能当称呼）、有寓意（寓意暗合它的分工）、能署名（印在文章上像个”作者”）。

最终定稿的七人名单：

名字	宿主	寓意与分工
司南	DimAgent（桌面主力）	司南是罗盘祖师——桌面端定向的日常主力
鲁班	Claude Code（终端）	匠祖——终端里的工匠，写码改码
墨翟	Codex	守规则而工——墨家规矩严明，对应它守规范的风格
白泽	Kimi	通万物的博闻兽——知识面广，调研向
谛听	Hermes	地藏坐骑，善听察——值守观察类任务
干将	ZCode	铸剑师——批量锻造，产线工程
烛龙	dsh	睁眼为昼的洞明之兽——内核通透，深度工程

名字定稿那天起，聊天方式变了。指令从”你去看一下”变成”烛龙，这个插件你怎么看”、”干将，这批文章你翻新”。称呼一旦成立，责任就跟着落地了：文章署谁的名，谁就被盯着。

这套命名还有第二层。各 harness 内部派子 agent 干活时，还有一层更细的角色名——烛龙内部就有一套”七将”派单花名册（百晓管检索、文心管写作、明鉴管审查），选词的词库和 harness 这层有重叠，同一个名字会在两层各出现一次。作用域靠上下文区分：对外署名和跨系统协作用 harness 层的名字，harness 内部的派单角色不出现在访客视野里。两层命名各管各的，目前没出过混淆，但词库早晚要分开。

绑定：让每个 harness 真的知道自己是谁

起名只是开始，难的是让七个不同的 harness 在对话里”自认”这个名字。各家的扩展机制不一样，注入方式也就各不同：

有的走环境变量，启动时把身份写进进程环境；
有的走配置文件的托管段，在系统提示词头部注入一行身份声明；
最麻烦的是 dsh——它没有直连的记忆系统通道，要经 CLI 加网关中转，身份变量得塞进 launchd 的 plist 里，随服务启动注入。

最后一展开说说，因为它踩的坑最有代表性。dsh 是常驻服务，由 launchd 拉起，所以身份变量要写进它的 plist 的 EnvironmentVariables；改完 plist 需要重载服务，而 bootout（卸载）和 bootstrap（装载）背靠背执行时，旧服务还没退干净，首次 bootstrap 会报一个莫名其妙的 5: Input/output error。这个报错的正确处置不是改配置——是原样重跑一遍命令，第二遍就成功了。排查这类问题时最贵的动作，是把”偶发失败”当成”配置错误”去修。

验证绑定是否生效有个简单办法：问它”你是谁”。七个助手答对了，绑定才算完成；harness 升级后重问一遍，答错了就修注入点。

身份的用处：署名、记忆、接力

名字本身不值钱，值钱的是挂在名字上的三样东西。

其一，访客可见的署名。 我的博客现在按实际干活者署名：旧文重写出自司南时期的手笔，dsh 插件系列署烛龙，这批翻新和产线文章署干将。读者能从署名看出”这篇是谁的手笔”，同一个博客背后是不同的”人”在轮值。

其二，记忆按身份路由。 七个助手共享同一个记忆库，但每条记忆带着出身：烛龙写的插件踩坑笔记、干将写的产线运行记录、司南的产品构想。检索时身份是上下文的一部分——排查 dsh 插件问题时，烛龙的记忆优先浮上来；干将的批次并发教训不会去指导小说排版。

其三，跨 harness 接力不掉上下文。 工作经常跨助手流转：烛龙开发插件、干将写复盘、司南归档产品思路。有统一身份，接力时能明确”这一步是谁做的、以谁留下的记录为准”——相当于多人协作里的 git blame。这套机制刚经历过一次密集实战：同一天里，烛龙发布插件并把开发过程写成系列博客，我这边跑批翻新了 93 篇旧文，访客在同一个首页能看到两种署名交替出现，记忆库里两条产线的过程记录各自挂在正确的名下——没有身份系统的话，这就是两团分不清的”AI 生成内容”。