企业软件项目的 Agent Harness：规则为什么

让 AI Agent 进企业项目，最容易走偏的路，就是疯狂堆规则。

Agent 出一次错，我们就加一条：代码怎么分层、函数怎么命名、测试怎么写。时间一长，规则文件越来越厚，Skill 越来越多，互相重复还打架。连维护者自己都分不清哪些还有效。

后来我们换了思路：Harness 不是给 Agent 塞一本包罗万象的开发手册，而是给它提供完成任务所需的知识、工具、反馈和边界。

规则要少，但关键风险必须写死。 比如金额字段统一用定点小数类型，普通验收绝不能修改真实订单状态。这些一旦漏了代价太大，必须明确写出。

Skill 的文字得有人把关。 模型为了覆盖所有情况，会把一句话改出好几个互相冲突的版本。长期生效的规则，尤其是权限和安全，必须由熟悉项目的人来审。

复用的是能力，不是复制段落。 把“导出需求”做成独立 Skill，其他流程直接引用。接口一变，只需改一处。

确定性工作交给脚本。 让 Agent 猜接口路径容易出错，不如写个脚本直接读取注册信息。Skill 只负责告诉它怎么用。

Hook 只做保底提醒。 任务卡住了发条通知可以，但不能代替权限控制和最终验收。

Harness 必须跟着项目一起迭代。 每次加规则前，先问问哪条老规则能删掉。随着模型变强，很多步骤它已经能自己搞定，别再让它多背。

最后拿真实任务做回归测试。 固定输入和环境，看成功率有没有提高。只有在质量没退化的情况下，规则越写越少才是真本事。

要不要我帮你把这套思路，整理成一份给团队看的极简版操作清单？