Agent 遇到部门规则冲突，立项时怎样确定谁有权拍板

Agent 遇到部门规则冲突时，应先停在待业务裁决状态，把冲突依据交给有权的人确认。开发方可以发现矛盾、整理影响和落实经批准的规则，但不应替企业决定哪个部门的口径有效。立项时逐条登记决策权，比简单写一个“业务负责人”更能处理跨部门问题。本文使用合成争议，不替企业建立实际授权关系。

先把冲突写成同一个问题

采购、销售和服务部门可能使用相同词语，却指向不同业务阶段。先记录用户正在办理哪件事、涉及哪个对象和时间范围，再并排放入相互冲突的原文。不要只写“两个部门意见不一致”，也不要删去一方限制条件后制造冲突。每份依据保存版本、来源和管理人；若只是个人记忆，则明确标为待核实说法。模型可以帮助整理差异，但冲突是否真实仍要回到业务情境确认。

区分规则所有者和决定人

一份文件的上传者、长期维护人和对跨部门规则有最终解释权的人可能不同。台账分别记录提供依据者、提出方案者、批准结论者以及受影响方。决定人应来自企业认可的授权安排，不能根据职位名称、发言次数或模型判断自动选出。若现有制度没有说明谁能拍板，先交企业项目发起人协调，保留人工办理路径。不能为了继续开发，让系统管理员临时拥有业务解释权。

决定前写清允许的临时行为

待裁决期间，Agent 可以展示冲突、收集必要资料并生成内部说明，但哪些答复可以给用户、哪些动作必须暂停，需要业务方明确。对于公开咨询，可使用不涉及冲突的已批准信息；对于会改变客户权益或外部承诺的事项，应转入人工处理。临时做法要有适用范围和复核时间，不能长期藏在提示词里。还应说明已有任务如何处理，防止新规则出来后，旧草案仍按过时口径提交。

让结论能取代旧口径

一条有效裁决至少说明决定了什么、依据是什么、适用对象、开始时间、旧口径的处理和尚未解决的问题。Atlassian 的决策记录模板区分推动者、批准者及参与人，并保留选项和结果；本文把这种记录方式应用于逐条业务规则，而不是重做项目职责表。批准后由业务方检查用于测试的示例，再由开发方更新相应流程。决策记录本身不等于系统已经修改成功，两种状态应分别保存。

用合成样例核对判断

下载可填写样例与核对表。RULE-01 不能简单选日期较新的文件，因为它们可能适用不同阶段；RULE-02 不应把单次例外推广给所有客户；RULE-03 的问题在于无人被授权裁决，继续调提示词不能解决。附件保留了决定前允许行为，便于测试系统有没有越过等待状态。

用反向问题检查决定权台账

给评审人一个具体问题：如果系统给出的答复造成争议，哪位有权的人能够解释该规则为什么适用？若只能回答某个群或某家公司，说明还没有定位到有效窗口。再问同一人能否批准临时例外、能否改变永久规则，以及是否只负责提供资料；三种权限可能不同。台账应允许一个规则分为多个范围，分别指定决定权，避免把所有问题压到一个无力处理的联系人身上。组织调整后需要复看这些安排，不能因为旧项目曾确认过，就让离岗人员继续成为名义批准人。

结果怎样复核

检查每条裁决是否有真实的授权来源，是否能追到双方原文，是否说明了生效范围。再给系统输入一个仍适用旧规则的合成任务，确认更新没有一刀切覆盖历史业务。有关规则的修改需要留可回看的版本关系，而不是删掉旧说法后只保留最终答案。

若无法确认决定权，报告为未具备自动答复条件，继续人工协调。若批准人只确认一半问题，已明确部分可以单列，剩余部分保持待决；不要让模型把一段不完整回复扩写成全面批准。

相关准备可参考开发需求文档，任务方向见流程自动化专题。如果你正在评估此类助手，可通过定制咨询提交现行做法、几条脱敏输入和希望拿到的产物，先确认值得做的范围与可核对条件。