MiniMax 开源了团队每天在用的 agent 技能
十六个技能加清单，不是提示词汇编，而是能跑的自检流程：什么时候该拆子 agent、工具定义吃掉多少上下文、评审为什么不该带上作者的对话。附安装路径和先试哪三个。
大部分「agent 最佳实践」读起来都对，落地时一句都用不上。原因很简单：写的人没在真实项目里被上下文撑爆过。
一、发生了什么
MiniMax Code 团队把他们内部每天在用的工作流和技能开源了，仓库叫 mcode-stack。开源中国把它归纳成十六个技能的清单，按使用场景分了组。
规划与拆分这一组，处理的是「这活该不该拆出去」。其中一项专门判断任务该交给子 agent 还是留在主循环，另一项把大功能、重构、迁移切成能评审的小 PR，还有一项负责写清「改了什么、为什么改」的提交说明。
上下文与工具这一组，做的是算账。一项量工具定义和工具结果各占多少上下文，然后决定是裁剪、改用工具搜索，还是换成程序化调用；另一项查每次请求都塞进了什么，对缓存命中有什么影响。
长会话与命令这一组，管的是「聊久了变笨」。一项决定该丢弃、摘要还是落盘，该压缩还是重开；一项生成交接文档，让新会话能接上；还有一项给长命令和后台任务做十项审计。
评审这一组有四项，最有意思的是独立评审：只给评审者三样东西——diff、需求、测试结果，故意不给作者的对话记录。理由很直白：继承了作者上下文的评审者，会继承作者的盲区。
实验与热修这一组，要求一次只改一处、重复跑、盯住翻转的任务；另一项看 agent 是怎么得出结论的，不只看它过没过。
仓库里每一项都是可直接加载的技能文件或清单，能装进 MiniMax Code，也能通过插件市场装进 Claude Code。
二、跟你有什么关系
自己搭 agent 工作流的人。 这套东西的价值不在内容多新，在于它把「凭感觉调」换成了逐条自检。
用 Claude Code 的普通开发者。 挑两三个装上就能用，不用改现有配置。
要给团队定规范的人。 六项工程类技能改编自谷歌的工程实践，条款相对成熟，比自创一套省事。
三、怎么用
读到这儿，可以顺路看 这个 agent 宿主把界面做成了终端 herdr 不碰模型，只接管 agent 跑的那个终端：关掉窗口、断掉 SSH，活还在跑，谁卡在审批一眼看得见。读完知道它和 tmux 差在哪、什么情况下不值得换。- 先装「子 agent 拆分检查」。它会逼你回答一个问题：拆分是因为上下文真的变差了，还是因为你习惯按人头分工。
- 再装「工具预算审计」。跑一遍，看工具定义每轮吃掉多少 token。多数人第一次看到这个数字会改架构。
- 评审环节加「独立评审」。把作者对话从评审输入里拿掉，只留 diff、需求和测试结果，看评审意见的质量有没有变。
- 装之前确认协议：整体是 MIT，但那六项工程类技能改编自谷歌的工程实践，沿用了 CC-BY 3.0，商用改造要保留署名。
四、三个别信的说法
「这是提示词合集。」 提示词是让模型换个说法，这套东西是让 agent 读你的代码和配置，逐条给证据、下判断。前者靠措辞，后者靠流程。
「装上就能提升效果。」 官方没有发布任何评测数据，仓库也很年轻。它是一套可执行的检查表，不是效果证明。
「技能越多越好。」 每装一个，模型就多一段要读的说明，上下文成本跟着涨。这套仓库自己就在教你怎么减，别反着用。
五、一句话结论
值得抄的不是那十六个技能，是「把每条经验写成能被 agent 执行的检查项」这个习惯。
信息来源
功能与价格以官方公告为准。本文写于 2026 年 10 月 31 日。
每周一封，只发新教程和可复制模板。不发广告，随时退订。