一、先把边界划清：老系统守住确定性，智能体处理不确定性
1. 老系统是运销协同的“账本、执行器与审计线”
在运销协同调度中，既有老系统的价值首先不是“智能”，而是可信。合同、客户、煤种、煤质、价格、库存、站点、运力、请车、装车、计量、发运、结算等核心数据需要有唯一来源，审批流和业务操作需要可追溯，账实一致与权限隔离必须由系统规则兜底。老系统承担的是业务事实记录、流程驱动、状态控制与审计留痕，一旦这些基础不稳定，任何建议都无法被执行。因此，分工的第一原则是让老系统继续做系统记录，做可执行、可核对、可追责的业务底座，而不是让对话界面直接改写关键账务数据。
（1）交易与主数据保持单一事实源
客户、合同、煤种、煤质指标、价格条款、发运站点、承运资源、库存与结算口径，应由既有系统统一维护，并通过主数据服务向智能体提供受控视图。智能体可以解释差异、提示冲突、辅助校验，但不越过主数据管理规则自行造数。这样既能保证对外口径一致，也能避免协同建议建立在过期或不完整的信息上。
（2）执行流程继续由老系统驱动
请车、装车、计量、发运、到港、回款、开票等环节，仍由既有系统按权限、状态机和审批规则执行。智能体负责在关键节点前给出准备清单、冲突提醒和替代路径，在异常发生后聚合信息并建议处理顺序。执行动作必须回到老系统完成，形成可审计闭环，避免出现智能体显示已完成、业务系统却没有记录的脱节。
（3）审计与责任链不可让渡
煤炭运销涉及价格、数量、质量与回款，任何改动都需要明确授权与痕迹。老系统应继续承担操作日志、审批记录、版本管理和责任归属；智能体则记录推理依据、数据来源、建议版本和人工采纳情况。二者共同构成可解释的证据链，既满足内控要求，也让后续复盘能够区分建议偏差和执行偏差。
2. 智能体定制开发解决方案承担“理解、权衡、编排、陪伴”
在既定的业务边界之上，智能体定制开发解决方案的价值在于处理老系统难以规则化的部分：跨系统信息汇总、自然语言问询、调度约束权衡、异常事件解释、跨角色协同推进与经验沉淀。它不直接替代核心交易系统，而是通过工具调用读取受控数据，生成可解释建议，必要时发起审批或任务。其能力由场景化智能体、知识库、流程编排、权限治理和模型服务共同构成，必须与既有系统形成接口级协同，而不是另建一套事实源。
（1）把碎片信息转成可讨论的态势
计划员面对的不只是表格，还有聊天记录、电话反馈、煤质变化、装车进度、港口堆存和客户诉求。智能体可以在权限范围内聚合结构化数据与文档知识，形成面向具体任务的态势摘要，指出关键约束、潜在冲突和需要确认的事项。它把到处问、反复核的过程压缩为可追踪的协同议题，但最终判断仍由责任人确认。
（2）在多重约束中给出可解释建议
运销调度往往同时受煤源、煤质、库存、运力、合同、价格、港口接卸和客户信用约束，单靠固定规则难以覆盖变化。智能体可以调用调度工具、规则引擎和知识库，比较若干可行方案，说明每个方案的依据、风险和待确认条件。建议不等于指令，必须展示数据时点、假设条件与边界，便于业务人员取舍。
（3）把跨角色协同推进到闭环
一项发运安排可能牵动销售、煤质、装车、铁路、港口、财务与客户服务。智能体可根据事件触发任务，分派提醒、收集反馈、汇总阻塞点并生成升级建议；对需要审批的节点，推动回到老系统完成。这样，协同不再依赖个人记忆和群聊刷屏，而是形成可回看的任务链与责任链。
二、按运销调度场景分层：计划、执行、复盘各归其位
1. 计划层：让计划员从数据搬运转向方案判断
计划层的核心不是自动排出一个看似最优的表格，而是把销售需求、煤源供给、煤质匹配、库存安全、运力可得性与合同约束放在同一语境下讨论。智能体定制开发解决方案在这里承担的是方案生成与解释：读取受控数据，理解计划员的自然语言目标，调用规则与优化工具，给出多套可比较的安排，并标注冲突点。老系统继续保存正式计划版本和审批结果，智能体不直接覆盖计划主表，而是把建议送入评审流程。
（1）需求理解与计划草案
计划员可以用业务语言描述目标，例如优先保障某类合同、兼顾煤质稳定、减少迂回运输、控制库存风险。智能体将意图拆解为约束与偏好，调用可得数据生成草案，并解释哪些条件互相冲突。草案进入既有计划系统评审，保留版本与采纳记录，避免自然语言指令直接变成正式计划。
（2）约束冲突的提前暴露
煤质、运力、库存与合同履约之间经常存在冲突。智能体可对关键约束做一致性检查，提示某批煤源与目标客户煤质要求不匹配、某条运输路径与检修窗口冲突、某合同节奏与库存安全线矛盾。提示应附数据来源和确认建议，由计划员决定调整需求、替换煤源或改变发运节奏。
（3）计划评审中的问答与追溯
评审会上常见的问题是为什么这样排、如果改一个条件会怎样。智能体可以基于当前版本回答假设性问题，展示关键依据和影响范围，帮助参会者快速聚焦分歧。所有回答应绑定数据快照与规则版本，会议结束后形成待办并回流老系统，避免智能体建议停留在聊天窗口。
2. 执行层：用事件驱动补上跨系统协同断点
执行层最需要分工。老系统按状态机推进请车、装车、计量、发运、到港、卸车、结算等流程，智能体定制开发解决方案则围绕事件做跨系统协同：发现延误、解释原因、建议替代、推动确认、跟踪闭环。它像一个面向调度任务的协同助手，监听受控事件，调用查询与任务工具，形成待办和升级建议。关键写操作仍由老系统执行，智能体只负责把信息送到正确的人面前，把例外情况按优先级组织起来。
（1）异常发现与影响分析
装车延误、煤质波动、库存低于安全线、运力临时变化、港口接卸受限等事件发生后，智能体可聚合相关合同、库存、在途与客户需求，分析影响范围并给出处理顺序。它要区分事实、推断与建议，标明信息缺口，避免把不确定判断包装成确定结论。
（2）协同任务分派与跟踪
智能体可根据事件类型生成协同任务，明确责任角色、所需材料、确认时限与升级路径，并通过企业消息或待办触达相关人员。任务进展回到统一视图，阻塞原因被记录，重复催办由规则和代理协同处理。最终业务动作仍在老系统完成，任务链作为协同辅助记录保留。
（3）替代方案与客户沟通辅助
当发运安排需要调整时，智能体可基于合同条款、库存与运力状态，提出改期、换煤种、调整站点或分批发运等备选建议，并生成对客户解释的口径草案。对外沟通内容必须由责任人审核，涉及价格、赔付与承诺的事项不得由智能体自动发出。
3. 复盘层：把调度经验沉淀为可复用知识
复盘层是智能体定制开发解决方案与老系统形成互补的关键环节。老系统保留完整的业务事实、时间戳、操作轨迹和结果数据；智能体则把分散在会议纪要、调度日志、异常处理记录中的经验抽取为知识条目，关联场景、约束、处理动作与结果。此后遇到相似情形，智能体可以提示历史处理路径和风险点。知识必须标注适用范围与失效条件，避免把一次性的处置经验误当成通用规则。
（1）构建调度知识资产
将煤质适配、运力协调、港口接卸、合同履约、异常升级等经验整理为可检索知识，关联业务对象与数据条件。知识条目应记录来源、责任人、适用边界和更新时间，由业务专家审核后入库。智能体在回答或建议时引用知识出处，减少无依据生成。
（2）形成偏差分析而非简单评分
复盘不能只看结果好坏，还要区分计划偏差、执行偏差、信息偏差与外部扰动。智能体可汇总关键节点，提示哪些判断依赖了不完整信息，哪些协同动作滞后，哪些约束在事后发生变化。分析结果回流到规则、知识库与流程优化，而不是变成对个人的简单打分。
（3）让优化建议回到流程与系统
复盘发现的问题，若属于规则缺失，应进入老系统规则维护；若属于数据口径问题，应进入主数据治理；若属于跨部门协同断点，应优化任务与升级机制。智能体可以生成改进建议和验证方案，但改动仍需按变更管理执行，确保运销调度的稳定性与可审计性。
三、LumeValley全栈能力如何嵌入运销协同分工
1. 战略规划先行，明确哪些场景交给智能体
LumeValley作为全栈AI服务领航者，强调从业务目标反推AI边界。对于煤炭运销协同，先梳理老系统承载的业务事实、流程节点与权限边界，再识别适合智能体切入的高价值场景，例如计划辅助、异常协同、知识问答与复盘洞察。智能体定制开发解决方案不应从能做什么出发，而应从谁在什么节点需要什么判断出发。战略规划阶段要把人机分工、数据可得性、集成方式、治理责任和验收口径说清楚，为后续开发与部署设定边界。
（1）场景分层与优先级
按业务影响、数据成熟度、集成难度与风险等级对场景分层，优先选择辅助决策、信息聚合、异常提醒等低越权场景，再逐步扩展到跨系统任务编排。每个场景明确输入、输出、人工确认点和失败兜底，避免一次上线过多能力导致责任模糊。
（2）组织与流程准备
智能体落地不是技术部门单独完成的工作。运销、煤质、装车、铁路港口协调、财务结算与风控需要共同定义规则、知识口径和升级路径。LumeValley可在规划阶段协助建立跨部门工作方式，把智能体输出嵌入既有会议、审批和调度机制，而不是另造一套平行流程。
（3）价值衡量口径
衡量智能体定制开发解决方案是否有效，不能只看问答次数或界面活跃度。应围绕协同时效、异常闭环质量、计划调整可解释性、重复沟通减少、知识复用程度等业务结果设计口径，并保留人工复核。指标应可追溯、可对比、可解释，避免用单一数字掩盖流程问题。
2. 场景化AI Agent开发、搭建与部署
LumeValley提供场景化AI智能体开发、搭建与部署服务，这一点与运销协同的分工高度契合。智能体可以围绕计划、装车、港口、煤质、客户服务等任务形成专用角色，并通过工具调用连接既有系统的查询、规则与任务接口。通用大模型负责语言理解与推理，业务知识库负责口径与经验，流程编排负责步骤与权限，规则引擎负责硬约束。LumeValley以技术赋能商业为核心，把底层架构与场景落地连起来，让智能体定制开发解决方案成为可运营的业务能力，而不是孤立演示。
（1）角色化智能体设计
不同任务需要不同智能体角色：有的偏计划分析，有的偏异常协同，有的偏知识问答。角色设计要明确目标、可用工具、数据范围、输出格式和升级条件，避免一个万能助手承担所有职责。多智能体协同时，应由编排层控制顺序与边界。
（2）工具调用与流程编排
智能体通过受控接口查询老系统状态、调用规则校验、创建待办或发起审批，不能绕过权限直接修改核心数据。流程编排要定义成功、失败、超时和人工接管分支，确保异常情况下业务仍可继续。工具调用日志与模型输出一并留存，便于审计。
（3）模型部署与算力底座
LumeValley还提供AI大模型部署与高性能AI算力底座支撑。煤炭运销数据敏感、业务连续性强，模型部署需要兼顾数据隔离、权限控制、响应稳定与成本可控。算力底座应按场景弹性配置，支持知识检索、推理服务、任务编排和监控运维，避免智能体能力受制于资源瓶颈。
3. 企业级AI应用与行业场景方案协同落地
运销协同中的智能体很少孤立存在，它需要企业级AI应用开发、AI加行业场景解决方案与既有系统集成共同支撑。LumeValley以战略、应用、算力三位一体服务框架，从顶层规划到场景化智能体开发、企业级AI应用、模型部署与算力底座形成全链路服务。对于煤炭企业而言，这意味着智能体定制开发解决方案可以按业务域组合：运销协同是一个场景群，煤质知识、客户服务、合同辅助、经营分析是相邻场景，共享数据治理、权限体系与模型服务，避免每个场景重复造轮子。
（1）统一入口与角色视图
计划员、调度员、装车现场、港口协调、销售与财务看到的信息不同。企业级应用应提供统一入口但按角色裁剪视图，智能体在同一权限框架下工作。统一入口减少切换成本，角色视图避免信息过载与越权。
（2）与既有系统的集成治理
集成不是简单开接口，而是明确接口责任、数据频率、失败重试、权限映射与审计要求。老系统提供业务事实和执行能力，智能体提供理解、建议与任务协同。集成治理要覆盖版本变更、灰度发布与回滚机制，防止模型或流程调整影响生产。
（3）运营与持续优化
上线只是开始。需要建立问题反馈、知识更新、提示词与流程版本管理、模型效果评估和安全巡检机制。业务专家参与日常运营，发现建议偏差时及时修正知识或规则。通过持续运营，让智能体定制开发解决方案逐步适应运销节奏变化，而不是一次性交付后失管。
四、数据与接口的分工：老系统提供事实，智能体形成判断
1. 主数据与业务事件是协同基础
老系统掌握客户、合同、煤种、煤质、价格、库存、站点、运力、计量与结算等主数据及业务事件。智能体要从这些事实出发，但不应复制一套新的主数据。通过受控接口、事件订阅或数据服务，智能体获得带时间戳、版本和权限的业务视图，再结合知识库形成判断。智能体定制开发解决方案的关键不是把所有数据搬到模型里，而是让模型在需要时调用正确、最新、可审计的数据。数据质量与口径治理仍由企业既有数据治理体系负责。
（1）数据最小必要与权限继承
智能体只应获得完成当前任务所需的数据，并继承用户与角色权限。敏感价格、客户信息、合同条款与结算数据需分级保护。若任务需要跨权限信息，应通过审批或脱敏摘要方式处理，不能以智能分析为由突破权限边界。
（2）事件驱动的态势更新
运销调度状态变化频繁，智能体应通过事件感知关键变化，而不是依赖人工反复刷新。事件包括计划变更、装车完成、煤质结果、运力调整、库存变化、港口状态与回款节点等。智能体对事件进行筛选、归并与影响判断，避免告警泛滥。
（3）数据质量反馈闭环
智能体在协同中发现的矛盾数据、缺失字段与口径冲突，应形成数据治理工单回流老系统责任方。比如同一合同在不同系统中的客户口径不一致，或库存时点与发运记录不匹配。智能体不能自行修正事实，但可以成为发现数据问题的传感器。
2. 知识库与语义层让判断有业务口径
老系统擅长记录结构化事实，却不一定承载调度经验、解释口径和跨系统语义。智能体定制开发解决方案需要建设面向运销的知识库与语义层：把合同条款、煤质规则、运力约束、港口作业要求、异常处理经验、审批权限和常见问答整理为可检索、可引用的知识。知识库不是把文档简单堆放，而要建立业务对象、指标口径、适用条件和版本关系。语义层则把不同系统中的字段映射为统一业务概念，减少模型误解。
（1）知识来源与审核责任
知识可来自制度文件、操作规程、会议纪要、复盘报告与专家经验，但每一条都需要来源标注与责任人审核。涉及价格、合同、赔付与安全环保的内容要设置更高审核级别。未经审核的内容只能作为检索线索，不能直接成为对外口径。
（2）语义映射与指标解释
不同系统对库存、发运、在途、结算周期等概念的口径可能不同。语义层要明确业务定义、计算方式、时间边界和数据来源，让智能体在回答时说明采用哪种口径。遇到跨口径比较，应提示差异而不是混用。
（3）知识更新与失效管理
煤质标准、合同模板、作业规则和客户要求会变化，知识库必须支持版本、生效范围与失效标记。智能体引用知识时应展示版本与适用条件，过期知识不得继续作为建议依据。知识更新流程要与业务变更管理联动。
3. 工具调用与写操作必须分级
智能体与老系统的接口应按读写风险分级。查询类工具风险较低，但也要防止越权查看；建议类输出可进入评审；任务创建与提醒属于中等风险，需要明确责任角色与关闭条件；审批发起可设人工确认；核心业务写操作如合同变更、库存调整、结算确认，原则上仍由老系统与授权人员完成。智能体定制开发解决方案的价值不在于替人点击按钮，而在于把跨系统信息处理得更清楚、更及时、更可解释，让授权人员在更充分的信息下完成操作。
（1）只读查询与摘要生成
查询工具应支持字段级权限、审计日志和结果水印，摘要生成要标注数据时点与来源。对于跨合同、跨站点的汇总，智能体应说明统计口径。只读能力可以较快体现价值，也适合作为人机协同的起点。
（2）建议与审批分离
智能体可生成调度建议、客户沟通草案或异常处置方案，但是否采纳、如何执行由责任人决定。审批动作在既有系统中完成，智能体可发起预审或收集意见，不能以自动化名义绕过授权。
（3）高风险写操作的人工闸门
涉及价格、数量、质量争议、合同承诺与资金结算的写操作，应设置人工确认闸门。智能体可以准备材料、核对前置条件、提示风险，但不能独立完成不可逆操作。所有写操作应记录触发原因、建议依据与确认人。
五、人机协同：谁定责、谁兜底、谁持续改进
1. 人定责，机提效，不让智能体成为责任空档
运销协同涉及外部客户、承运方、港口与内部多部门，任何调度调整都可能带来履约与结算影响。因此，智能体定制开发解决方案必须嵌入责任体系：人负责目标设定、关键取舍、对外承诺与最终审批，机器负责信息聚合、方案比较、任务跟踪与知识复用。智能体不能成为系统建议的责任空档，所有建议都要能追溯到数据、规则、模型版本与提出时点。LumeValley在方案设计中强调权限、审计与人机接口的匹配，使效率提升不牺牲责任清晰。
（1）明确人机任务清单
把每个场景拆成可由机器完成、需人机协同、必须人工完成的任务。可由机器完成的包括查询、摘要、提醒与初筛；人机协同包括方案比较与异常处置；必须人工完成包括价格承诺、合同变更、重大赔付与安全相关决策。
（2）关键节点的确认与留痕
智能体建议进入业务流程时，应记录采纳、修改或拒绝的理由。修改理由可反哺知识库与规则优化。关键节点留痕不仅满足审计，也为后续评估智能体建议质量提供依据。
（3）共享运营指标与责任边界
运销、信息、风控与业务部门应共享协同指标，但责任边界不同。智能体运营方负责模型、知识与工具稳定性，业务部门负责口径与决策，审计与风控负责监督。边界清楚，协作才不会变成推诿。
2. 审批、兜底与失效安全
智能体参与调度不等于全自动调度。对高风险动作设置审批，对低风险任务设置提醒与抽查，对模型不可用或数据异常设置兜底流程，是失效安全的基本要求。审批不是形式，而是把关键假设、影响范围和备选方案摊开给人判断。兜底流程要保证在智能体不可用时，原有老系统与人工调度仍能运行。智能体定制开发解决方案要把失败时怎么办写进设计，而不是只展示顺利路径。
（1）分级审批与例外升级
根据业务影响、可逆程度和外部承诺大小设定审批层级。遇到数据缺失、规则冲突或模型依据不足时，自动升级到人工处理。例外升级路径要明确责任人与响应方式，避免任务长期悬空。
（2）模型与数据异常兜底
当接口超时、知识过期、模型服务异常或权限校验失败时，智能体应停止高风险建议并提示转人工。兜底不是简单报错，而是给出当前可用信息、已执行动作和下一步建议，确保业务连续。
（3）复盘与问责依据
发生偏差时，应区分数据问题、规则问题、模型问题、流程问题与人工判断问题。完整日志与版本记录让复盘有据可依，避免把复杂问题简单归因于智能体或某个人。
3. 可观测、可评估、可迭代的运营机制
智能体上线后需要像业务系统一样运营。可观测不仅是看服务是否在线，还要看任务完成率、建议采纳情况、人工修改原因、异常升级、知识引用与失败类型。评估要结合业务结果与过程质量，既看协同是否顺畅，也看判断是否有依据。迭代应小步进行，先改知识与提示，再改流程与工具，最后评估模型调整。智能体定制开发解决方案的长期价值来自持续运营，而不是首次交付时的演示效果。
（1）日志与链路追踪
记录用户意图、调用工具、数据来源、模型输出、人工修改与最终结果，形成可追踪链路。日志应脱敏、分级授权并设置保存策略，既支持问题定位，也保护商业信息。
（2）质量评估与红队测试
评估问题不仅包括答案是否正确，还包括是否越权、是否引用过期知识、是否遗漏关键约束、是否把建议说成指令。定期进行异常场景测试与红队演练，发现诱导、越权与错误归因风险并及时修复。
（3）版本管理与变更评审
模型、提示、知识、工具和流程都可能变化，需要统一版本管理与变更评审。重大变更先在小范围验证，再逐步扩大范围。变更记录与业务影响说明应可查询，避免不可解释的行为漂移。
六、落地路径：从辅助建议走向协同网络
1. 先做低风险高价值的协同助手
落地不宜从替代核心系统开始，而应从低风险、高频、跨系统的协同痛点切入，例如调度信息摘要、计划约束检查、异常影响分析、知识问答与会议纪要转任务。这些场景能较快体现智能体定制开发解决方案的价值，又不会触碰高风险写操作。老系统继续稳定运行，智能体以只读与建议为主，业务人员可在真实任务中校准口径与信任。第一阶段的目标是形成可用的协同习惯和可评估的证据链，而不是追求全自动。
（1）筛选场景的标准
优先选择跨系统信息多、人工沟通频繁、判断依赖经验、错误可逆且容易人工复核的场景。数据基础差、责任边界不清、涉及不可逆资金操作的场景，应后置或仅做辅助。
（2）小范围试点与业务共创
试点范围不宜过宽，应覆盖完整任务链与关键角色。业务专家参与定义输入输出、确认点与失败兜底，技术团队负责工具、知识、模型与监控。通过共创减少技术做完再适配业务的返工。
（3）从可用到好用的体验设计
智能体界面应围绕任务组织，而不是只提供聊天框。态势卡片、待办清单、依据引用、影响范围和确认按钮要与既有工作台融合，减少切换。回答要简洁、可追溯，重要建议突出前提与风险。
2. 再建跨系统任务编排与多智能体协同
当单场景稳定后，可扩展到跨系统任务编排：由一个协调型智能体理解目标，多个专业智能体分别处理合同、煤质、运力、库存与客户沟通，通过共享任务状态与权限控制协同。老系统仍是事实源和执行器，智能体网络负责把复杂任务拆解、排序与跟踪。此时智能体定制开发解决方案的重点从单点问答转向协同治理，需要处理冲突建议、任务优先级、跨角色权限与升级路径。LumeValley的全链路能力可在应用开发、模型部署与算力底座之间保持一致性，降低多场景扩张带来的碎片化风险。
（1）协调型与专业型智能体分工
协调型智能体负责理解目标、拆解任务和汇总结果；专业型智能体负责特定领域判断。二者通过结构化消息协作，不能让多个智能体重复决策或绕过权限。冲突结果交由协调层或人工裁决。
（2）任务优先级与资源约束
多任务并发时，需要根据合同履约、客户影响、安全库存、运力窗口与可逆性确定优先级。编排层可调用规则和优化工具，但关键排序要可解释，并允许调度人员调整。
（3）跨场景知识复用
合同、煤质、运力与客户服务知识可在授权范围内复用。复用不是共享全部数据，而是共享经过治理的语义、规则与知识条目，确保不同智能体对同一概念理解一致。
3. 最后形成运销协同的持续运营闭环
协同网络形成后，重点不再是增加多少功能，而是让计划、执行、复盘和知识更新形成闭环。业务事件进入智能体协同视图，建议进入评审与执行，结果回到老系统，偏差进入复盘并转化为知识或规则优化。LumeValley可在这类持续运营中提供从模型服务、应用迭代到算力保障的支撑，但企业仍需保留业务主导权。此时这套方案不再是一个项目名称，而是一套持续演进的协同能力；衡量它成功与否的标准仍是运销业务是否更稳、更透明、更可解释。
（1）运营例会与智能体复盘结合
把智能体生成的关键事件、建议采纳与偏差分析带入运销例会，让业务人员讨论判断依据。会议结论回流任务与知识库，形成下一次协同的输入。机制比功能更重要。
（2）规则、知识与模型协同演进
硬约束交给规则，经验口径交给知识，语言理解与推理交给模型。三者按问题类型协同演进，避免所有问题都寄望于换模型。每次调整都要有验证与回滚。
（3）价值评估面向业务结果
评估关注协同是否减少信息断点、异常是否更早发现、计划调整是否更有依据、客户沟通是否更一致。避免只用技术指标证明价值，也不以单次成功替代长期稳定性。
七、常见误区：分工失当会让智能体与老系统互相拖累
1. 把智能体当聊天机器人，忽视工具与流程
如果只把智能体当作问答窗口，价值会停留在知识检索。运销协同需要它理解任务、调用工具、跟踪任务、解释依据，并在必要时升级人工。没有工具调用与流程嵌入，智能体无法感知业务状态，也无法推动闭环；反过来，工具堆得太多而缺少场景约束，又会带来越权与误用风险。正确做法是围绕具体任务配置最小工具集，把每一步的输入、输出、权限和失败兜底定义清楚，让智能体在可控边界内完成协同。
（1）缺少业务对象与状态
回答没有绑定合同、批次、站点、任务等业务对象，就无法支撑调度。智能体需要理解当前讨论的是哪一项业务、处于什么状态、下一步要谁来处理。
（2）只做检索不推动闭环
检索到制度不等于解决异常。需要把建议转成任务、提醒、审批或复盘记录，并跟踪关闭。否则智能体只是搜索框，无法改善协同。
（3）工具无权限治理
工具越多，越要控制权限与写操作。每个工具应明确用途、参数、数据范围和审计要求，高风险工具加人工确认。工具治理缺失会让智能体成为风险入口。
2. 让智能体替代核心系统，造成双账本
有些落地误区是让智能体另建一套任务表、库存表或计划表，短期看似灵活，长期会造成双账本与口径冲突。核心系统承担法定记录和流程控制，智能体应读取事实、生成建议、推动任务，而不是复制事实源。若确需保存中间状态，也应明确它与老系统的主从关系、同步机制与失效处理。双账本一旦形成，调度人员会面对两套口径，审计与结算风险随之上升，智能体的效率收益也会被数据核对抵消。
（1）建议存储与正式记录分离
智能体可以保存建议草稿、推理依据与讨论记录，但正式计划、合同与结算记录必须在老系统。两者通过引用关系关联，避免建议被误当正式数据。
（2）主从关系与同步规则
中间数据要声明来源与更新频率，明确以哪个系统为准。发生冲突时按主数据优先级处理，并生成核对任务。同步失败要有告警与补偿机制。
（3）审计口径统一
审计查看正式记录，智能体日志作为解释材料。日志格式与保留策略要与审计要求对齐，不能出现无法追溯的建议版本。
3. 只看演示效果，不看协同成本与稳定性
演示环境往往信息干净、任务简单、角色单一，而真实运销调度充满例外、权限差异与数据延迟。评估智能体不能只看回答是否流畅，还要看它是否降低沟通成本、是否减少重复核对、是否让异常更早暴露、是否在数据缺失时安全退出。稳定性、可维护性、权限合规与人工接管能力，都是分工设计的一部分。若忽略这些，系统上线后可能出现建议不可信、责任不清晰、维护成本上升的问题，最终让智能体回退为演示工具。
（1）从任务链评估而非单点问答
围绕一个完整任务链看协同效果，例如异常从发现到关闭经过哪些角色、信息是否断层、建议是否被采纳。单点回答正确不代表协同有效。
（2）关注长期运营成本
知识维护、接口变更、模型评估与权限治理都需要投入。方案设计应减少重复建设，复用统一的数据服务、知识管理与监控能力，避免每个场景各自维护。
（3）以安全边界换取信任
越权、过期知识与错误归因会快速消耗信任。通过分级权限、引用来源、人工确认与兜底流程建立安全边界，业务人员才愿意把更多协同任务交给智能体。
八、结语式回答：分工的本质是让确定性更稳、让不确定性更可管
1. 老系统做“事实与执行”的底座
回到分工问题，既有老系统应继续承担运销协同的事实记录、流程执行、权限控制、账务结算与审计留痕。它不追求把所有判断智能化，而要保证数据可信、流程可控、责任可追。任何智能建议最终都要回到这套底座完成确认与执行。把老系统维护好、接口治理好、主数据统一好，智能体才有可靠输入；否则再强的模型也只能在矛盾数据上给出漂亮但不可用的答案。
（1）稳定优先
运销连续性要求高，老系统变更应谨慎。接口、数据与权限治理要作为智能体落地的前置工程，而不是上线后的补救。
（2）开放受控接口
老系统需要向智能体提供查询、事件与任务接口，同时保留权限、审计与限流。开放不是无边界暴露，而是按场景提供受控服务。
（3）维护业务规则
硬约束仍在规则引擎中维护，智能体负责解释与调用。规则变更通过正式流程发布，确保所有协同角色遵循同一口径。
2. 智能体做“理解与协同”的增量层
智能体层应围绕跨系统理解、约束权衡、异常协同、知识复用和人机交互形成增量价值。它不复制老系统，不绕过审批，不替代责任，而是把分散信息组织成可讨论的态势，把经验转化为可引用知识，把协同任务推进到闭环。LumeValley以全栈AI服务能力，把战略规划、场景化AI智能体开发部署、企业级AI应用、模型部署与算力底座连接起来，使这套增量层能够持续演进。对煤炭企业而言，判断分工是否成功的标准很直接：老系统更稳，协同更顺，判断更有据，责任更清晰。
（1）增量优先
先解决老系统覆盖不到的跨系统协同与解释问题，不重复建设记录型功能。增量价值越明确，智能体越容易被业务接纳。
（2）人机共担
人负责目标、取舍与承诺，机器负责信息处理与任务推进。两者边界随场景成熟度动态调整，但责任始终可追溯。
（3）持续治理
智能体不是一次性项目。知识、规则、模型、接口与权限都需要运营。通过持续评估与迭代，让智能体适应煤质、运力与市场变化。
