多智能体从代码中提取业务规则：arXiv 2609.22719

当天发生了什么

2026-09-19 03:08（UTC），Garima Agrawal 等作者在 arXiv 提交了论文《From Code to Requirements: Agentic Reverse Engineering of Business Rules at Enterprise Scale》（2609.22719）的 v1，主分类为 cs.SE。论文的背景是正当的系统迁移：企业软件常常缺少结构化需求，逻辑散落在代码、配置和人员经验里。作者提出由七个专门智能体组成的框架，从代码、测试、配置和现有文档中识别用户流程、提取业务规则，并生成业务需求文档；过程中使用静态分析工具，并在设定的升级节点由人工审核。摘要报告：在一个真实企业部署的执行轨迹上，每个服务生成完整文档用时不到九分钟；提取出的规则与真实生产缺陷记录做了独立核对；与基于仓库指标、IFPUG 复杂度模型和行业人力费率构建的基线相比，成本降低超过 98%，而此前一次类似迁移耗时两年以上。

对克隆风险评估意味着什么

在应用克隆的威胁模型里，最昂贵的一步往往不是复制界面，而是弄清楚「规则到底是什么」：价格如何计算、哪些条件触发风控、哪些功能受授权限制。这篇论文展示了，在拥有源码、测试和配置的前提下，多智能体流程可以把这一步压缩到分钟级。需要诚实说明的是，论文的场景是企业内部有完整访问权限的迁移，并没有评估只拿到发布二进制或前端代码的外部攻击者。因此，它不能直接证明克隆者也能达到同样效果。但它提示了防守方应该关注的面：凡是随客户端发布的规则表、特性开关、配置 JSON、测试夹具和注释，都是这类流程最容易利用的材料，因为它们本身就是半结构化的「需求」。

可以在自己的发布物上做的检查

第一，检查发布包和前端产物中是否包含测试文件、示例数据、source map、规则表或带说明的配置文件，能删的删，能移到服务端的移到服务端。第二，把「规则」与「展示」分开：客户端只拿到结果，不拿到计算规则和阈值；必要时由服务端下发经过裁剪的结果。第三，审查代码注释与日志字符串，避免在发布构建中保留描述业务逻辑的文字。第四，对内部使用的 AI 智能体同样设定访问边界：哪些仓库、配置和文档可以被读取，是否会被发送到外部服务，需要有明确记录。

行动清单

• 清理发布物中的测试文件、source map、规则表与带注释配置
• 客户端只接收计算结果，规则与阈值留在服务端
• 记录内部 AI 智能体可读取的仓库与文档范围