背景与目标

Kimi Code 周额度打顶,thinking 项目需要一条平行引擎。任务口径:把 thinking 的 Kimi Code 配置/技能/智能体复刻到 Open Code(桌面版 + mimo-v2.6-flash-free),创建"军师"智能体并设为本项目默认 agent,描述详细准确。

目标拆三条:

1. 全量:8 岗章程、指令注入、技能发现、MCP 路由、模型档位、派单白名单一个不漏;
2. 双轨零扰动:Kimi 侧生效链路(AGENTS.md、.agents/、tools/headless_dispatch.py)一个字不动——改 AGENTS.md 需本人同意,且改了会伤 Kimi 轨;
3. 验收可判定:静态验收之外必须有行为探针,不接受"配置写了"当"配置能用"。

本人在方案确认阶段的四问拍板与授权原话(本篇的最高指令):

MCP 挂载口径:"pachong 的时候挂上去" 范围授权:"其他的你看着办" 重启后续接:"我重启了,请继续任务"

时间锚:配置落盘 14:23–14:28【实测:opencode.log "touching file" 时间戳】,重启后冒烟 14:36–14:45【实测:同日志 run=355bf355 窗口】,成稿 15:22;thinking 仓上一个 commit 是 09-27 20:09【实测:git log】,本批次 13 件改动(9 新文件+4 修改)截至成稿未提交【实测:git status --short】。

同日背景:dev 数字员工团队工作区已先完成一次同类迁移并出复盘(notes/AI工作/blog/2026-09-28-opencode迁移与双渠道识别复盘.md,源项目=dev)。本篇是 thinking 侧的第二次迁移,scope 不同、坑不同,姊妹篇互为证据。

过程回顾

尝试 1:摸底与方案——先核 schema,再四问拍板

• 摸底 Kimi 侧资产:8 岗(junshi/pachong/yinliu/yiren 五岗)、项目技能目录、yiren 团队技能、MCP 三件套、指令注入链、派单白名单;
• 对照 Open Code 官方 config.json 逐字段核对,拿到三个决定方案走向的硬事实:AgentConfig 没有 mcp 字段(MCP 授权只能放 json 的 agent.<name>.tools)、subagent_depth 默认为 1(yinliu 独立判卷要嵌套必须改 2)、skills.paths 支持递归注入;
• 把四个架构决策抛给本人四问,回答全部落到可执行参数:MCP 随 pachong、yiren 五岗一并复刻、态势页+全局章程都注入、军师设默认;随后一句"其他的你看着办"完成方案级授权。

结果:方案零返工。 四个回答后来全部被冒烟实测验证为正确架构判断。

尝试 2:落盘与静态验收——一次全绿

单轮落盘:

• 9 个新文件:.opencode/agents/ 8 岗章程(junshi 62 行主智能体+权限块、pachong/yinliu/yiren 五岗镜像)+ docs/opencode运行适配.md 44 行(环境差异唯一事实源);
• opencode.json 重写 130 行:default_agent=junshi、指令注入 5 件(AGENTS.md/credentials/当前态势/运行适配/用户级全局章程)、subagent_depth: 2、skills.paths 注入 yiren 团队、MCP 三件套全局 tools 关+agent.pachong.tools 单岗开、build.task 白名单扩到 11 子代理;
• 治理三件套同批落:registry +9 行(总数 144,P0 17/P1 72/P2 55)、ledger 变更条、allowlist 补 2 行。

静态验收:config_lint.py 全量 78 文件 0 违规(退出码 0)、9 件 front matter YAML 解析全过、opencode.json JSON 解析过。

结果:全绿。 但当时就记着 dev 侧同日的教训——静态全绿只证明"写了"。这份绿在尝试 3 里只撑了半小时。

尝试 3:重启冒烟——4/6 过,两处险情当场抓出

MCP 探针是本场设计的关键一招:派 task 给 pachong,让它只自报工具清单不执行操作——回包 14 个内置 + 57 个 MCP 工具(playwright 25 + chrome-devtools 30 + context7 2)【实测:子代理工具 schema 枚举】;同时反向自证:军师本会话工具面 MCP 为 0。一正一反,"全局关+单岗开"的不对称结构被行为级证明,不是配置级推断。

结果:4/6 实测过,2 项挂账转实战收口;冒烟过程抓出两处险情,见下节。

关键踩坑

坑 1:default_agent 首查报"不存在",险些误判推翻已落盘配置

• 现象:冒烟校验 default_agent 键名,直接查 config.json 根 properties 返回 False——键名不在。
• 根因:官方 schema 顶层是 $ref 包装(根 properties 为空,真实定义在 $defs/Config),我的首查路径错了,不是键错了。
• 解决:深挖 $defs/Config,找到合法定义,描述原文:"Must be a primary agent. Falls back to 'build' if not set or if the specified agent is invalid."——同时暴露这类键的危险性:写错不报错,静默回落 build。补三项验证:键名在 $defs 合法 ✅、junshi mode: primary 在位 ✅、重启日志零 agent 加载失败 ✅。
• 教训:静默回退类配置,写入时就要深查 $defs,验收时必须补行为探针。这与 dev 侧"缺 model 字段静默落到 qwq-plus"是同一类根因——迁移配置最大的风险不是写错,是写错也没人告诉你。

坑 2:重启日志 6 条技能重名告警

• 现象:duplicate skill name ×6(doubao-product-manager、doubao-questionnaire-designer、doubao-data-analysis 各一对,外加用户级 .claude/.agents 三个)。
• 根因:yiren 团队 a1–a5 本来就存在 3 个技能名跨岗同名分发(如 doubao-product-manager 同时挂 a1 和 a2);用户级 .claude/skills 与 .agents/skills 双目录另有 3 个既有重名。本批新增的 skills.paths 把第一类暴露成了日志告警。
• 解决:MD5 逐对哈希——三对字节完全相同,去重零功能影响,不处理;用户级 3 个属既有问题与本批次无关。登记说明即可,不为零影响的告警引入改动。

坑 3:MCP 工具数 63 vs 57——我自己犯的数字错

• 现象:探针回包头部写"MCP 工具(63 个)",明细却只列了 57 个(25+30+2),其合计行也是 57。我把头部的 63 原样写进台账并向本人播报。
• 根因:引用子代理的汇总数,没有做内部一致性核对(头部 vs 明细合计)。
• 解决:明细复点 57 为准,台账 63→57 已更正,口播更正。违反的是铁律一"数据必须真实可溯源"——错数险些入账。
• 教训:引用任何二手汇总(子代理/脚本/文档),先核其内部自洽;明细与头部矛盾时,明细胜。

最终方案

做得好的地方

1. 写前查重:先发现同日 dev 侧已有迁移复盘,主动区分 scope(源项目不同、坑不同),不重复造稿;
2. 行为探针设计:让子代理自报工具面 + 军师侧反向自证,MCP 路由从"配置推断"升级为"行为证据";旧会话续传 agent=build 没有误判成失败,识别为预期行为挂账而非 bug;
3. 治理先行:新文件登记、变更落台账、allowlist 补条与配置同批完成,lint 前后各跑一次;
4. 险情不遮掩:schema 险情、63 错报、2 项挂账全部当场上报,不打包成"全部完成"。

复盘与改进

1. 静默失效是迁移的第一风险类:键名错回落默认(model→qwq-plus、default_agent→build),静态验收对这类问题天然盲区。验收公式固化为三件套:schema 深查($defs)+ 启动日志零告警 + 行为探针——三者缺一,"全绿"不可信;
2. 二手数字必核明细:头部与明细矛盾时明细胜,错数不入台账;
3. 双轨并行是正确姿势:Kimi 轨零改动,额度回来随时切回,Open Code 侧配置独立演进,互不拖累;
4. 2 项挂账走实战收口:新会话确认默认 agent、首单 yinliu 验证嵌套——不为验证而造验证单,在真实工作中自然完成。

成长评估

五维评分(10 制,只对事):指令 9 / 判断 9 / 思维 8.5 / 结果 8.5 / 协作 8.5。

• 指令与提示词质量 9:四问应答一次到位(MCP"pachong 的时候挂上去"六个字定完整个权限架构),随后"其他的你看着办"完成方案级授权,全程零纠偏(证据:会话记录无一次方向纠正);
• 判断与结论 9:四个架构判断(MCP 随岗、五岗一并复刻、双注入、默认 agent)冒烟后全部实测为正确(证据:上表 4/6 中四个 ✅ 项即其验证);
• 思维方式 8.5:双轨零改动的边界意识+"描述详细准确"的质量要求,是成熟迁移思维;未主动给出验收口径(2 项挂账靠 AI 申报)扣 0.5(证据:收口追问"是不是可以接下来干活了");
• 最终结果与产出 8.5:13 件落盘+lint 0 违规+冒烟 4/6,扣分在 2 项挂账与 1 个错数已更正(证据:台账更正行);
• AI 协作能力 8.5:"我重启了,请继续任务"给清晰续接口,收口提问把会话推向可执行结论(证据:本场对话)。

AI 自评失分点(本场,本人未抓到错,以下为自查):

1. 63 vs 57 错数入台账并口播——引用子代理汇总数未核内部一致性,违反铁律一,已更正;最重失分;
2. default_agent 首查路径错误——没先意识到 schema 是 $ref/$defs 结构,险些把合法键误判为非法、推翻已落盘方案;
3. skills.paths 重名未预判——a1–a5 同名分发结构写入前可查出来,靠重启日志才暴露(结果零影响,过程失分)。

指令实证(2 条):

1. "pachong 的时候挂上去"

   六个字确定 MCP 三件套"全局关+单岗开"的不对称架构,避免了"全开污染上下文"与"全关废掉采集岗"两个默认选项;结果证据:opencode.json agent.pachong.tools + 双向探针(pachong 57 个 MCP 工具 / 军师 0 个)。

2. "其他的你看着办"

   方案级授权使军师自决全部配置细节,单轮完成 9 文件+130 行配置落盘零返工;结果证据:git status 13 件改动 + config_lint.py 78 文件 0 违规。

素材点

• "静默回退"三件套验证法(schema 深查+日志零告警+行为探针)——可提炼为媒体稿方法论,与 dev 侧"缺 model 落 qwq-plus"合并成同根案例;
• 双轨迁移 checklist:旧轨零改动清单化、新轨文件清单化,git status 双向反证;
• 探针式冒烟设计:子代理自报工具面+反向自证,轻量且可复用于任何"权限路由"验收;
• 一天三篇复盘(dev 迁移 / 配置流水账治理 / thinking 迁移)= 双渠道时期完整横截面。