跨部门流程的断点，很少出现在某个环节内部，几乎都出现在两个部门智能体的交接面上。财务智能体算清了付款条件，法务智能体却取不到合同变更记录；供应链智能体识别出交期风险，采购与生产各持一套判断。问题不是模型能力不够，而是事实与责任在交界处无人承接。
断点会以新的形态出现
把每个环节各做一个智能体，并不会消除断点，只会让断点换个样子：任务状态不共享，同一份业务事实被反复索取；判断规则散落在各自的提示词里，谁前置审查、谁需要会签没有统一口径；高风险动作缺少共同的处置规则，一旦出事无法定位是哪个环节放行。集团业务的参与方多、规则异构、责任链长，这三点决定了断点不会因为单点模型变强而自然消失。方案设计的起点应当是“链路在哪里断、由谁接续、接续时依据什么规则”，而不是“建多少个智能体”。
分层，并共享同一份事实
更稳妥的架构是把编排、业务能力与权限控制拆开。调度层只负责任务拆解、分发与状态跟踪，不越权代替专业智能体做业务判断；执行层以明确的输入输出约定调用业务系统，而不是直连核心数据；治理层贯穿全程，而不是事后补丁。
共享上下文的价值在于让协同不靠反复确认。任务、业务、执行三类上下文分开维护，合同条款更新时只需刷新业务上下文并通知相关方，不必重跑整条链路。路由规则要写成可配置的显式规则，比如哪些任务必须法务前置、哪些金额以上必须财务会签，而不是藏在提示词里。依赖关系也要支持并行与串行混合：排期与审查可以同时推进，付款执行必须等两者都通过。
安全边界与验收标准
权限按任务授予最小范围，跨部门流转以“结论加依据”为主，减少原始数据扩散。异常挂起必须有明确入口、明确岗位和响应时限，处理结果回写上下文，供同类任务参考。
验收阶段要警惕表面指标。端到端时长下降但人工介入比例上升，说明协同只是把工作挪给了审批人；一次通过率提高而越权拦截频繁触发，则要回头检查权限与路由配置。先选一条断点清晰、频次高的链路跑通，复制时复用调度与治理能力，只替换执行层智能体。
还有两个不属于技术架构的问题需要提前定：谁对智能体的最终动作负责，部门结论冲突时按什么规则裁决。这两问答不上来，协同体系跑得再顺，也只能停在演示阶段。