Kimi 员工指控 MiniMax“复用”Office Skill：AI Agent 进入工程能力与知识产权博弈区

在大模型竞争从“对话能力”走向“生产力工具”的阶段，围绕 Agent 工程能力的争议开始浮出水面。

近日，有自称参与 Kimi Office Skill 开发的员工发文称，MiniMax 在其 M2.5 / M2.7 模型版本中，Office 能力与 Kimi 高度相似，甚至存在“约 8000 行代码一致”的情况，并指相关实现被重新命名或转为“内置工具”。

需要强调的是：上述说法目前来自单方指控，尚未有公开的技术鉴定或法律结论。

争议核心：Office Skill 到底是什么

所谓 Office Skill，本质是 AI Agent 在文档场景中的执行能力集合，包括：

• Word 文档生成与编辑
• Excel 数据处理与计算
• PDF 解析与生成
• 批注、修订与格式控制

从技术结构来看，这类能力通常由三层组成：

LLM（理解与规划）
   ↓
Tool Layer（工具调用）
   ↓
Execution Scripts（具体实现，如 PDF / Word 处理）

其中，真正具有工程价值与差异化的，往往在最底层：

具体工具链与脚本实现（如 PDF 处理逻辑）

指控焦点：从“能力相似”到“实现一致”

根据该员工描述，争议并不在功能层面，而在实现层面：

1. 代码级相似性

• 约 8000 行代码一致
• 目录结构与逻辑接近

2. 行为特征一致

• Office 能力表现路径相似
• 工具调用方式一致

3. 后续调整行为

• 删除或隐藏相关脚本
• 改名为“自研工具”（如 html_to_pdf）
• 重构目录但保留核心逻辑

如果属实，这类问题在工程上通常涉及：

• 代码复用 / 未授权使用
• 内部资产泄露
• 或开源协议违规（若涉及开源组件）

技术难点：AI Agent 能力“相似”与“抄袭”的边界

这类争议之所以复杂，在于 AI Agent 领域存在天然的“相似性问题”：

1. 能力收敛

所有厂商都在做：

• 文档生成
• 表格处理
• PDF 转换

→ 功能层面高度趋同

2. 技术路径趋同

常见实现路径：

• Python + PDF 工具链
• HTML → PDF 渲染
• Office Open XML 处理

→ 工程方案可能类似

3. Prompt 与 Tool 的“灰区”

• Prompt 可能相似但不可版权化
• Tool 调用逻辑较难界定归属

因此，真正关键的判断标准通常是：

是否存在“可验证的代码级一致性”与“独特实现被复用”

行业背景：Agent 能力成为新竞争焦点

这起争议出现的时间点，也非常关键。

当前大模型竞争已经进入：

而 Office Skill 正是 Agent 最典型的落地场景之一：

• 高需求（办公自动化）
• 高频使用
• 易于评估效果

这也导致：

厂商在该领域的竞争异常激烈

更深层问题：AI 工程资产的“可复制性”

与传统软件不同，AI Agent 的工程资产具有一些新特征：

1. Prompt + Tool 混合资产

• 一部分是代码
• 一部分是提示词
• 一部分是调用策略

2. 边界模糊

• 哪些算“原创”
• 哪些属于“通用实现”

3. 复制成本低

• 一旦泄露或反编译
• 可快速迁移与重构

这使得 AI 时代的知识产权问题，比传统软件更加复杂。

可能走向：技术争议走向法律化

如果争议继续发酵，通常会进入几个阶段：

1. 技术对比（代码 / 行为分析）
2. 平台或社区讨论
3. 法律层面取证与起诉

关键证据包括：

• 代码相似度分析
• 提交记录（commit history）
• 构建产物对比（如 DLL）

写在最后

Kimi 与 MiniMax 的这起争议，反映的不只是一次“是否抄袭”的个案，而是一个更大的行业问题：

当 AI 能力越来越依赖工程实现，知识产权如何界定？

在 Agent 时代，真正的护城河不再只是模型，而是：

• 工具链
• 执行逻辑
• 系统集成能力

而这些，恰恰也是最容易引发争议、最难界定边界的部分。

可以预见，随着 AI 从“生成内容”走向“执行任务”，类似的工程与版权纠纷，只会越来越多。