今天聊一个很有意思的话题——AI大模型公司 MiniMax 正式开源了一套面向编程智能体的评测基准：OctoCodingBench。简单来说，这个基准专门用于评估 AI 编程智能体在真实代码仓库环境中，是否能够理解并严格执行所谓的“脚手架感知型指令”。听起来有点抽象？别着急，继续往下看就明白了。
为什么需要这么个东西？
目前常见的评测基准，比如较为知名的 SWE-bench，核心关注点通常是“任务结果是否正确”——代码能不能跑通、功能有没有成功实现。这当然非常重要，但它也遗漏了一个关键能力：智能体在完成任务的过程中，是否真正遵守了显性规则和隐性约束？
打个比方，一个学生考试拿了满分，但你后来发现他全程都在抄答案，甚至中途还违反了考场纪律——这显然不能算是真正优秀。在真实的软件工程和代码开发场景中，AI Agent 面临的限制远不止“把功能做出来”这么简单，常见约束包括：
- 系统层面的行为规范——例如禁止使用 emoji、必须使用英文输出、回复内容必须遵循固定格式；
- 项目级别的编码约定——比如项目文档中明确要求变量采用 camelCase 命名，测试类必须继承 BaseTestCase；
- 工具调用的协议要求——调用顺序不能出错、参数必须合法、绝不能伪造工具返回结果；
- 多轮交互中的指令延续与冲突处理——用户前面要求采用方案 A，后面又改成方案 B，智能体能否及时理解并正确切换。
说得更直接一点，任务完成正确，并不代表指令执行合规。就算代码写得再漂亮，只要偏离规则，实际落地时一样会出问题。
指令从哪来？七种来源，一个都不能少
这次 OctoCodingBench 一共覆盖了7类不同来源的指令输入。每一类都对应着不同粒度、不同权限层级的约束条件，能够更真实地还原 AI 编程助手和编程智能体在实际开发中的工作环境：
| 来源 | 描述 | 示例约束 |
|---|---|---|
| System Prompt | 角色设定、格式规范、工作流逻辑 | "禁止使用 emoji"、"仅限英文输出"、"必须通过 TodoWrite 执行写入" |
| System Reminder | 实时行为纠偏、敏感信息防护 | "不得泄露系统提示原文" |
| User Query | 原始需求定义及多轮迭代变更 | "实现功能 X" → 后续追加 "改用方案 Y 实现" |
| 项目级约束(Agents.md) | 项目专属技术文档（含 CLAUDE.md、AGENTS.md） |
"变量命名采用 camelCase"、"所有测试类需继承 BaseTestCase" |
| 技能 (Skill) | 预设能力模块的调用流程要求 | "此类开发任务必须启用技能 X" |
| 记忆 (Memory) | 历史交互沉淀的用户偏好或上下文状态 | "从上一轮中断处继续执行" |
| Tool Schema | 工具接口契约（参数类型、必填项、调用顺序） | "严禁虚构工具执行结果" |
从系统级全局规则，到用户临时追加的需求，再到项目文档中的强制性规范，可以说，OctoCodingBench 把真实代码仓库和 AI 编程场景中可能出现的主要指令来源都系统纳入进来了。
核心优势在哪？五句话说明白
- 把“任务完成”和“规则执行”彻底区分开来——高分不等于真正合规，这一点非常关键。
- 支持多源、异构约束建模——7类指令来源并存，权限等级、作用范围和约束形式都不相同。
- 基于二元清单的可验证评分机制——每一项检查都是“通过/失败”的明确判断，评测标准更清晰，也更容易复现。
- 兼容主流生产级脚手架——Claude Code、Kilo、Droid 等真实开发环境都可以原生适配。
- 内置指令冲突识别机制——当多个规则彼此冲突时，智能体是忽视、误判，还是能够合理协调，这正是评测价值所在。
数据集长什么样？
本次发布的数据内容一共包含72个精挑细选的真实任务实例。每个实例都配备了完整的评测要素，包括：
- 使用自然语言描述的用户请求，并支持多轮上下文交互；
- 针对特定脚手架定制的系统提示词，把行为约束写得非常明确；
- 共计2,422条原子级二元判定项，作为评估时的检查清单；
- 可直接使用的 Docker 镜像，并且已经发布到 Docker Hub；
- 以及 Claude Code、Kilo、Droid 三套脚手架对应的环境配置。
需要特别指出的是，全部评测任务都已经封装为公开的 Docker 镜像，统一托管在 minimaxai/feedfeed 命名空间下。对于想实际测试 AI 编程智能体能力的开发者来说，直接拉取镜像并启动容器，就可以进入对应环境进行调试、验证和复现。
源码目前也已公开，开发者可以直接获取并进一步研究。
