FDE 怎样把 AI 试点扩到多个部门：复用配置，每个部门独立放行

共享候选通常包括运行框架、工具接口格式、日志结构和部署方式。部门差异包括资料范围、业务对象、金额规则、任务结束条件、例外接手人和外部动作。把这些写成配置清单，再由相关负责人确认是否真的相同。

同一种“报价”在销售和采购部门可能含义不同：销售给客户的金额涉及对外承诺，采购比价的金额可能只是内部分析。复用一个功能名称不代表复用执行权限。遇到差异，应保留独立规则或接口，不让模型根据部门名临场猜测。

部门也不总等于独立租户。企业需按数据与职责建立可执行的业务范围，可能是部门、项目或客户组的组合。技术上共享资源的系统仍应验证这些范围，不假定只有物理分开才需要授权。

表中编号是教学示例，不是某个产品必须采用的命名。重要的是一件任务发生错误时，维护者能找到它实际使用的组合。只记录“最新版”无法解释升级前后的差异。

资料持续更新的场景也需要可回溯依据，可以记录来源更新时间、内容版本和检索时点。无法固定整份快照时，如实说明重现限制，保留当时引用的必要证据和权限信息。

MCP 安全指南讨论代理接入第三方工具时的授权和凭证风险。跨部门系统尤其应避免把一个宽范围凭证交给模型，再用“你只属于销售部”的文字约束访问。工具服务需要依据经过验证的身份，检查请求中的业务对象和动作。

不仅检索结果要过滤，缓存键、历史会话、媒体下载和日志入口也要带正确范围。同一问题可能在两个部门得到不同资料，缓存不能仅按问题文本命中。共享故障排查入口也不能让普通部门用户浏览其他部门的完整记录。

对确实需要跨部门协作的任务，显式定义可共享字段和授权角色。协作不是无限开放：采购可以核对某个产品的供货信息，不代表应获得销售客户的全部合同。每个跨范围读取都应有具体依据。

新部门即使只用只读功能，也应测试引用是否来自允许资料、旧缓存是否仍可见，以及资料撤回后如何更新。第一部门已经成功的样本适合保留作共享回归，不能替代新部门自己的规则和权限检查。

共享组件发布后，为每个部门建立可选择的采用记录。先在隔离环境运行共同回归和该部门测试，再根据约定范围试用。部门规则负责人确认结果后，才把该部门切到新组合。这样可以让一个部门的试验不直接改变其他部门。

涉及字段含义或存储结构的升级，要明确新旧组件和配置的兼容关系。某部门仍在旧版本运行时，共享服务是否继续支持其接口必须检查。不能只退回提示词，却让它面对已经改变的业务字段。

记录回退前提，包括未完成任务和外部动作如何处理。退回组件版本不会撤销已经创建的订单或已发送消息。运行中的任务应按状态查询结果，再决定在原组合继续、转交或重新确认。

Palantir 的生产责任文章强调由熟悉相关代码的团队承担运行问题。跨部门扩展可以据此约定：公共运行故障交给共享组件维护者，销售规则冲突交给销售规则负责人，来源资料失效交给资料责任人，避免所有问题都汇总到最初的 FDE。

给告警和问题单加上实际部门范围与配置版本，路由到有能力处理的人。共同接口错误可能影响多个部门，负责人需要查看受影响组合；单一部门规则错误则先限制相应范围。暂停和修复动作应与影响范围一致。

负责人离岗或团队变化时更新名单与操作权限。每个采用部门都应知道如何暂停高影响动作、如何查看任务结果以及何时升级给共享团队。长期靠项目创建者手动处理，不适合持续扩展。

准备销售和采购两个测试身份，使用相似问题分别查询，并尝试读取对方对象、命中对方缓存和查看对方日志。预期结果由权限规则事先决定，检查实际返回是否符合。随后只升级其中一个部门，确认另一个部门仍使用原有配置。

还要模拟部门配置缺失。系统应该拒绝进入未定义的业务范围，或采用事先明确的受限默认行为；不能回落到最大权限的公共账号。运行记录应显示失败原因，让维护者能区分接入配置问题与模型理解问题。

当配置差异越来越多，把常见能力整理为可测试的组件，同时保留差异清单和版本记录。是否值得统一某条规则，由业务含义与责任决定。多个部门使用同一套代码，仍需要各自能解释结果和独立停用的边界。