原型稿(非交付物):分钟级速出,仅供把味定选题;事实/原话/细节可供素材卡参考,结构不继承。
我给自己的 AI 军师团队建了一套配置治理统计机制:扫描全机 814 份会话日志,区分真实调用和工具清单噪声,给每个技能/MCP 算出"该不该退役"的判据——第一天就抓出 4 个白挂、5 个冤案,和一个断档一个月没人发现的事故。
上午我对军师说了一句话:「我认为你搞配置的能力还是很差。」昨天它改数字人团队配置,描述写得我不满意。它认账,说去做个调研。结果这一天的折腾,变成了一次完整的 AI Agent 配置治理实战——从建 SOP、写统计工具,到挖出断档事故,全程 9 个 commit。这篇把过程和方法都摊开,代码和判据可直接抄。
被骂之后:先搞清楚"配置能力差"到底差在哪
军师做的第一件事不是辩解,是派了两个子代理分头取证。
一路去 GitHub 查 agent 配置领域的现状(数据全部为 2026-09-06 gh api 实时查询):AGENTS.md 开放标准已被 60,000+ 项目采用,Codex、Copilot、Cursor、Gemini 全读取;anthropics/skills 仓库一年不到冲到 174,610 star,SKILL.md 正成为跨工具的"能力包"格式。行业共识已经收敛成两层:指令文件管纪律,技能包管能力。
另一路审计我自己的仓库,抓出 8 条短板,最扎心的三条:
- 章程里只有纪律没有方法论——写了"军师负责岗位设计、yaml 配置",全文没有一条"怎么写好一个配置";
- 官方现成的方法论(design-agent/design-task 两个技能,1204 行)就躺在技能目录里,全仓库零引用;
- 我自己定的"新规则只在翻车后添加"原则,被前一天的改造系统性违反——从外部文档整章翻译预写了 6 组规则,全部未验证。
结论:不是不懂规范,是从"要配一个 agent"到"配置合格投产"之间没有生产工序。发布物有 145 行的 SOP,配置生产一个字没有。
配置 SOP:五道工序,每道都有机器可判的闸
当天立档 docs/agent-config-sop.md,核心五道:
| 工序 | 闸口 |
|---|---|
| 定岗位 | 禁止凭空写 role/goal/backstory,必先查官方方法论+生产级样例仓+本仓先例,三处都无可参考才从零写 |
| 写配置 | 7 项打勾清单:role 是否领域+级别、goal 是否可检验、backstory 是否零口号、guardrail 是否显式挂载…… |
| 小剂量入库 | 外部材料蒸馏铁律:单次入库未验证规则 ≤3 条,触发列填不出翻车编号就不入库,⏳ 超 14 天未验证自动点名 |
| 双轨检查 | 事实有第二处拷贝时,要么声明唯一来源其余改指针,要么当场同步 |
| 投产验收 | 装配审计 + 语义层抽查(观测口径/引用可见性/硬闸 scope) + 真跑留证 |
每道工序的判据都是机器可判定的,不写"尽量""认真"这种词——这是我们自己写法规范里的硬要求。
814 份会话日志:统计口径的三个坑,每个都导致误判
接着建统计机制。目标是回答"技能什么时候该退役",数据源是 Kimi Code 的会话日志(wire.jsonl,每行是一条 JSON 记录,单行可达 15 万字符)。真跑:814 个文件,3.6 秒扫完。过程里踩了三个口径坑,每个都足以让结论反转:
坑一:schema 清单污染。 每个会话的请求载荷里嵌着完整的工具 schema 清单,每个 MCP 工具名因此"出现"一次。如果按字符串出现次数统计,所有工具都"被用过"。真实调用只存在于 type=="tool.call" 的记录里——必须先解析记录结构,过滤清单类记录,再计数。
坑二:注入式技能误伤。 首跑报告:8 个技能"零调用"。但取证发现其中 5 个是冤枉的——它们按设计根本不走 Skill 工具调用:有的全文注入子代理提示词(dispatch 记录里有痕迹),有的由 CrewAI 产线的 yaml inject_files 常驻注入,有的走 Bash 直接调脚本。只统计 Skill 工具调用,对注入式技能必然误报。
坑三:提及≠使用。 修完坑二又发现新问题:调查当天我的派单任务书里提到了这些技能名,"引用次数"全被今天的调查自己污染了。最终判退役要靠需求侧证据——技能的正文特征句是否在历史会话里出现过、它对应的需求是否真实存在过——而不是提及次数。
修正后的判据:退役候选 = Skill 调用与注入引用双零 ≥60 天,且无 CrewAI 常驻注入,且需求侧证据零命中。
零调用≠该退役:4 个真白挂与 5 个冤案
用修正后的判据过一遍,23 个技能 + 5 个 MCP server 的裁定分三类:
5 个冤案(保留):爬虫、测试、整理三个作战手册全是注入式使用,首跑统计差点全错杀。
4 个真白挂(当天退役):ask-docs 技能、deploy-to-vercel 技能、web-design-guidelines 技能、crewai-docs MCP——正文特征句全机零命中,需求分别被本地手册和产线覆盖,或从未存在。退役不是物理删除:移入 _archive/,台账备案,需求复发可查回。
2 个附带真信号:其中一个是,我挂了 6 天的 crewai-docs MCP 零真实调用——装的时候凭感觉,统计第一天就现形。另外 GitHub MCP、SQLite MCP 两个"热门候选"被裁定不装:gh api 和 sqlite 脚本现在跑得好好的,能力零增量,还多占工具预算(实测工具数超过 30-50 个,模型的工具选择准确率开始劣化)。装不装,以后让统计说话。
我也被当场抓包:一个拍脑袋的配置错误
下午本人检查我的 MCP 归置方案,直接开骂:「军师,你这智商有大问题了……我天天搞逆向啊?其他有几个项目搞逆向的?」
他说得对。我把 IDA Pro 的 MCP server(逆向工程专用)留在用户级全局配置,理由是"逆向是跨场景需求"——全机只有一个项目搞逆向,还是当天刚建的。我没核实项目实况就下了结论,正好违反当天早上刚立的 SOP 工序四。当日纠正:挪到该项目的项目级配置,台账记了归因。
这条写进博客是因为它比任何方法论都值钱:配置结论必须有事实依据,谁违反谁认账,AI 也一样。
断档一个月:最重要的发现不是统计出来的
傍晚的取证撞出了今天最严重的问题。我有个"信息整理"技能,负责扫微信、钉钉群消息里的指令类来文(@我、限期上报、整改),自动生成待办。它的分析产物停在 7 月 31 日——断档一个多月,无人发现。
根因取证结论:恶性断档,不是良性替代。 这个职能总共只活过 2 天(7-30 上线首跑、7-31 第二次),之后我晚上的口令固定成"复盘一下"全走另一个技能,它既没有自动触发机制,也不在任何检查清单的监控范围内——三重悬空。而"群消息指令监控"这个职能本身,一个多月无人接管。
处置当天落地:来文扫描并入每日复盘的固定环节(零命中也必须写明"零命中"——没扫和没命中必须能区分),开场自检加"来文扫描 >3 天缺位即点名"。
更深一层的教训:yinliu 数据链 8 月断采、信息分析 9 月断档,每条监督规则都是用一次断档换来的。所以要建最后一块:关键产物存续监督表——每个周期性产物登记"频率+断档判据",开场自检按表走,新产物立项时强制登记,不再靠事故驱动。
经验总结
- 配置是生产工序,不是灵感。定岗位→写配置→小剂量入库→双轨检查→投产验收,每道闸机器可判;外部材料蒸馏单次 ≤3 条未验证规则。
- 统计先过口径关:schema 清单会污染计数、注入式使用不走工具调用、提及次数≠使用次数——三个坑不修,退役名单就是冤案名单。
- 退役判据要需求侧取证:正文特征句零命中 + 需求不存在,才够格;退役走归档+台账备案,可回滚。
- 监督项不能靠事故驱动:关键产物全部登记"频率+断档判据",立项即登记,按表检查。
- 工具加装让数据说话:能力零增量的 MCP 不装;白挂的,统计跑一周自己现形。
结尾
一天的配置治理,9 个 commit,4 个白挂退役,1 个断档事故现形。最值钱的一句话反而来自被骂:「我们的解决方式好,真的可以退役;解决方式效率低,那得改,以后得用啊!」——数据只能回答"用了几次",回答不了"为什么没用"。
近期会把这个统计机制跑满一个月后的趋势数据放出来:哪些技能持续沉睡、哪些 MCP 真的白挂,一个月后再对一次账。
本文所有内容均为本人 AI 实战的过程和结果,经 AI 整理后发布,无任何瞎编虚构内容。
FAQ
Q:wire.jsonl 统计怎么排除工具清单污染?
A:逐行 JSON 解析,只统计 type=="tool.call" 的记录;llm.tools_snapshot、tools.set_active_tools、config.update 这类清单/快照记录全部过滤。实测某工具按字符串原始出现 8 行,真实调用 7 次——过滤后口径才一致。
Q:注入式技能的使用量怎么统计?
A:三个通道:子代理 dispatch 记录里的技能路径、Read 工具对 SKILL.md 的调用记录、CrewAI yaml inject_files 的静态引用(豁免退役)。注意这是"提及次数",判退役时还要叠加需求侧取证。
Q:技能退役了还能恢复吗?
A:能。退役=移入 _archive/ 目录 + 台账"已删除规则备案"登记(日期/文件/删了什么/删除依据),需求复发时查备案直接恢复,不是物理删除。
素材点
- 「8 个零调用技能里 5 个是冤枉的」——统计口径误伤的冲突故事,可作短视频钩子;
- 「每条监督规则都是用一次断档换来的」——金句,监督体系主题通用;
- schema 清单污染的技术细节(8 行出现 vs 7 次真实)——开发者向干货素材;
- 「我天天搞逆向啊?」骂醒 AI 的原话场景——人机协作调教素材;
- 退役判据四件套(双零 60 天/无常驻注入/需求侧零命中/归档可回滚)——可复用清单素材。
分发配套
- 标题 Top5:
- 我统计了 814 个 AI 会话日志:8 个「零调用」技能里 5 个是冤枉的(数字反差+实体锚定,90,综合首选)
- AI 技能断档一个月才发现:我用 814 份会话日志建了套配置治理统计机制(实体锚定+数字,88,稳健)
- 零调用≠该退役:AI Agent 技能生命周期统计的口径陷阱与取证方法(问题悬念+长尾词,85,搜索)
- Claude/Cursor 都在读的 AGENTS.md 怎么管?一套配置 SOP 救回我被骂的配置能力(大词前置,82,搜索)
- MCP 服务器挂了 6 天零调用:AI 工具配置的数据驱动治理实践(实体+数字,80,实验)
- 摘要(92 字):扫描 814 份 AI 会话日志建配置治理统计机制,第一天抓出 4 个白挂 MCP、5 个技能冤案和一个断档一个月的事故。附统计口径三坑、退役判据四件套、配置 SOP 五道工序,全部可抄。
- 分类与话题:人工智能 / AI Agent;#AI Agent #SKILL.md #AGENTS.md #MCP #配置管理
- 封面文案:8 个「零调用」技能,5 个是冤枉的
