OPEN SOURCE DEEP DIVE
MiniMax Code 团队的智能体工作流库
MiniMax 开源的三套编码智能体工作流，把独立评审、上下文预算、长会话交接、受控实验与需求生命周期做成可安装技能。
先说清楚它是什么
mcode-stack 是 MiniMax Code 团队公开的一套编码智能体工作流库。它把团队日常使用的评审方法、上下文管理、长会话交接、受控实验和需求跟踪写成可安装的 SKILL.md、检查清单与工作流说明。这里所说的“工作流”不是又一个提示词合集，而是可以在具体项目中逐项执行的工程约束。
它不包含 MiniMax Code 应用本身的源代码，也不是一套已经证明能提升所有模型表现的基准方案。仓库提供的是操作程序和验证方法。哪些做法适合你的项目，仍然需要在相同模型、相同工具和相同任务集上自行做对照实验。
三套已发布技能栈
仓库目前发布三套技能栈，共 27 个技能。三套栈都打包成插件，但解决的问题并不相同。
| 技能栈 | 技能数 | 核心范围 |
|---|---|---|
ronny | 19 | 编码智能体的上下文、评审、长任务、实验和日常工程实践 |
jiachen | 2 | 移除重复的人工作业环，以及把素材整理成内容成品 |
req-tpm | 6 | 需求从受理到结果复盘的完整生命周期 |
主栈 ronny 来自 MiniMax Code 研发负责人日常使用的一套流程。它覆盖任务拆分、代码评审、小型变更、长命令、子智能体分工、工具预算和轨迹复盘。另两套栈不是同一套流程的换皮版本：jiachen 更关注个人与智能体之间的协作方式，req-tpm 则把流程延伸到产品需求和组织状态。
独立评审与证据优先
independent-review 要求评审者使用干净上下文，只看代码差异、原始需求、测试结果和必要的项目说明，不继承实现者的整段推理过程。这样做是为了把“代码是否成立”和“实现者如何解释代码”分开。实现者已经形成的假设，不应该自动成为评审者的前提。
evidence-first-review 进一步处理智能体报告“已经完成”的那一刻。它要求先打开工具日志和命令输出，再阅读最终总结，并逐项回答三个问题：这项检查证明了什么，没有证明什么，哪些默认决定是在执行过程中被悄悄做出的。测试通过只说明被测输入在特定条件下通过，不等同于调用方正确、运行时行为正确或需求理解正确。对于高风险变更，还要主动寻找能推翻结论的证据。
review-capacity-check 把评审能力本身当作瓶颈。并行启动更多智能体并不会自动增加可信产出。如果团队没有足够时间理解差异、判断取舍并承担后果，那么新增智能体只会制造更多待审工作。这个检查把并行度与真实评审能力绑定在一起。
上下文预算与缓存位置
tool-budget-audit 同时计算工具定义和工具返回结果占用的上下文。它建议先删除不必要工具，再把低频工具放到按需搜索之后，最后才考虑让模型编写程序调用工具。每一步都应该单独测量，因为工具数量、返回体积和调用轮次都会影响成本。
context-tax-audit 则检查每个请求都被注入的内容，包括系统说明、环境信息、目录结构、规则和动态状态。仓库特别指出，把当前时间等内容直接写进系统提示词，会让每轮共享前缀发生变化，从而破坏提示缓存。更稳妥的做法是把会话内稳定的环境信息放在前面，把逐轮变化的时间写入历史中的上下文块，并控制时间精度。判断一项内容该不该进入请求时，可以依次检查必要性、频率、精度、位置和缓存影响。
长会话、交接与长命令
long-session-check 处理会话变长后的注意力衰减。它要求区分哪些信息可以丢弃，哪些应该压缩成摘要，哪些必须写入文件，哪些需要进入长期记忆。上下文压缩不是简单删字，而是重新安排状态，使后续步骤仍然能追溯到目标、约束和已完成工作。
handoff-doc 把这套状态整理成可交接文档。新会话不依赖旧会话的隐含记忆，而是从目标、现状、关键决定、失败尝试、未完成事项和验证方式继续工作。这个技能适合在上下文接近上限、任务跨天或需要转移给另一个智能体时使用。
long-command-check 用十项检查审阅长时间运行的命令和后台任务。它关注命令是否会阻塞主循环、是否可能无限等待、输出是否过大、失败后是否可见、并发是否会互相干扰，以及任务脱离终端后如何确认完成状态。它不是给每条命令增加仪式，而是在启动耗时或有副作用的任务前补齐可观测性和收尾路径。
把改动当作受控实验
harness-experiment 明确把智能体脚手架变更视为实验。实验开始前先写一句可证伪的假设，再准备一个小型端到端评测集。基线运行需要固定模型版本、设置、工具和仓库状态，并重复执行以暴露波动。候选版本一次只改一个变量，例如一段提示词、一个工具位置、一个子智能体结构或一个压缩阈值。
比较基线和新版本时，不能只看平均通过率。记录应包含逐任务通过率、正反翻转任务、请求次数、输入与输出词元、缓存命中率和实际耗时。平均分不变但请求更少，可能是收益；平均分上升却破坏不可违例规则，则不是可接受的收益。每个翻转任务都要打开轨迹，查清翻转原因。
trajectory-review 正是为此设计。它不只检查最终答案是否正确，还检查智能体如何获得结果：是否跳过了必要步骤，是否误解工具输出，是否在失败后重复同一动作，是否用了不稳定的捷径，以及成功是否依赖偶然条件。
把重复纠正变成检查
taste-to-checks 关注同一类人工纠正反复出现的情况。如果审阅者第二次指出同一问题，就不应继续依赖记忆和口头提醒，而应把它转成测试、静态检查、钩子或持续集成步骤。这个技能把个人品味转化为团队可重复执行的门禁，减少智能体和人类审阅者在同一处反复协商。
主栈还包含小型变更拆分、变更说明、代码评审评论、评审反馈处理和紧急变更判断。这些技能沿用了公开的工程实践框架，并在仓库中注明部分材料改编自 Google Engineering Practices，采用相应的署名和许可。项目本身与 Google 没有隶属或背书关系。
六阶段需求生命周期
req-tpm 让提出产品需求或技术需求的人，与自己的智能体一起承担需求技术项目管理的职责。六个阶段分别是受理、排优先级、设计、跟踪、发布和结果复盘。需求正文存放在飞书文档，状态和流程存放在 Meegle。
- 受理：判断需求是否值得做，并固定指标、基线、目标、测量方式和观察窗口。
- 排优先级：整理成本、影响和风险，提出建议，但由负责人做最终决定。
- 设计：记录备选方案、最终决定、影响范围和检查点。
- 跟踪：定期更新进展、阻塞和下一步，并把停滞项放到报告前部。
- 发布：检查回滚、可观测性、完成定义和状态迁移。
- 复盘：按照受理时固定的预期结果核对证据，只有达到目标并以证据确认后才能关闭。
这套设计把“已经上线”与“已经产生预期结果”分开。未达到目标的需求不会因为任务关闭而自动成功，而会回到设计阶段继续调整。外部可见的评论、提及和状态变更必须先展示给提出者，确认后才会执行。
需要明确的是，req-tpm 当前标记为 v0，属于可选技能栈。仓库说明它尚未在真实 Meegle 空间中运行过，字段、角色和状态中有一部分是待核对的假设，同时依赖 meegle 与 lark-cli。因此它适合作为需求流程的试验起点，不应被描述成已经完成生产验证的通用需求管理产品。
安装、校验与采用边界
仓库提供 Claude Code、Codex、MiniMax Code 插件市场和直接复制技能目录等安装方式。也可以把整栈作为插件安装，或只复制一个 SKILL.md 目录到 ~/.agents/skills/。安装脚本会优先使用本机已有的 claude 或 codex，否则回退到目录复制。
scripts/check.mjs 会验证技能前置元数据、清单接线、插件市场文件一致性、可选版本递增和官方 MiniMax Code 校验。它适合在修改技能或新增技能栈后运行，确保插件声明与实际目录没有悄悄分叉。
采用这些技能时，最合理的起点不是一次安装全部 27 个，而是选择一个已经反复出现的问题，例如评审失焦、上下文膨胀或长会话交接。先记录当前基线，再启用一个技能，观察它是否改变实际行为。团队如果决定保留某项流程，应同时确定证据来源、失败处理方式和退出条件。技能只是把规范变成可执行动作；它不能替代项目目标、工程判断和最终责任。