中药材产业的数字化，正在从资料上云、流程上线，走向辅助研判的深水区。知识库提供事实底座，数字人提供交互入口，AI问数提供分析线索，三者叠加并不自动等于一个可以进入班子研判舱的智能系统。真正的分水岭，是系统能否把证据、口径、权限、审签和复核责任同时讲清楚。对中药材这类高度依赖经验、产区差异与炮制规范的领域，系统越接近决策场景，越需要承认自身的能力边界。
当议题聚焦到定级、投入与推进次序时，问题不再是“能不能做”，而是“做到什么边界、由谁承担判断责任、哪些结论必须回到人工复核”。智能体部署开发若只追逐演示效果，容易把知识问答、虚拟形象和数据查询包装成决策能力；一旦进入研判舱，任何含混都会被放大。因此，讨论中药材智能体，必须先把技术能力翻译成治理语言，再谈部署方式与业务价值，否则定级就会失焦。本文围绕知识库、数字人、AI问数三类能力展开，尝试回答边界在哪里、怎样分级推进、哪些环节应由全栈AI服务承接。
一、定级之问：中药材智能体为何要进入班子研判舱
1. 研判舱需要的是证据链而不是演示链
中药材智能体进入班子研判舱，首先改变的不是界面形态，而是决策信息的组织方式。班子看到的不能只是“系统说了什么”，还要看到结论来自哪份规范、哪条数据、哪次审签，以及异常口径如何被处理。智能体部署开发若忽略证据链，功能越热闹，越容易制造“看似有依据”的错觉。研判舱的价值在于把分散信息压缩成可讨论、可质疑、可复核的判断材料，而不是把责任交给一个无法解释的自动回答。因此，定级时应先问证据是否可追溯、口径是否统一、权限是否可隔离、过程是否可审计，再问交互是否自然、响应是否快速。
（1）研判场景要求结论可被质询
在班子研判中，任何结论都可能被追问依据、假设和适用条件。系统需要把答案拆成事实、推断与建议三层，明确哪些来自知识库，哪些来自数据计算，哪些只是模型生成的候选解释。只有让每一层都可被质询，智能体才不会替代讨论，而是提升讨论质量。对中药材议题，还要标注来源层级与适用范围，避免把局部经验直接上升为普遍判断，并要求关键结论附上人工复核意见。
（2）演示链要转为责任链
演示链关心的是效果是否惊艳，责任链关心的是出错后能否定位、纠偏和追责。智能体部署开发进入研判舱前，应把数据来源、模型版本、提示模板、检索范围、权限校验和审批记录纳入同一条链路。任何一次回答都能回到当时使用的材料与规则，任何一次越权访问都能被拦截和留痕。这样，系统才能把“可用”变成“可管、可审、可持续”。否则，演示阶段的口头承诺很难转化为运行阶段的组织信任。
2. 定级对象是能力体系而不是单点工具
把中药材智能体作为单点工具定级，常见后果是只评估问答准确率或数字人形象，却忽略其背后的知识治理、数据治理和权限治理。真正需要定级的是能力体系：知识库是否具备版本管理，问数是否依赖统一指标，数字人是否有话术边界，智能体是否能在异常时转交人工。工具可以采购，能力体系必须建设。定级越早承认这一点，后续投入越不容易被割裂成互不相通的孤岛。同时，能力体系必须与组织流程匹配，明确业务部门、数据部门、技术部门与合规部门各自的责任，否则系统上线后仍会回到人工兜底。
（1）定级应覆盖场景价值与治理成本
定级不能只看效率提升，还要看治理成本。一个场景即使能快速生成答案，如果来源不清、口径不稳、权限难控，进入研判舱后就会增加复核负担。更稳妥的方式是把场景价值与治理成本放在同一张评估表中，对高风险议题提高证据门槛，对低风险咨询先开放辅助能力。智能体部署开发要服务于这种分级，而不是用统一模板覆盖所有场景。
（2）业务边界应由责任清单固化
责任清单要回答谁提供知识、谁确认口径、谁配置权限、谁处理异常、谁批准上线、谁组织复盘。对进入班子研判舱的能力，还应明确人工复核节点与最终决策主体。责任清单不是形式文件，而是系统配置的依据：哪些回答只能提示线索，哪些必须附出处，哪些需要二次确认，都应在流程中固化。清单越清晰，技术团队越能把边界转化为可执行的校验规则，业务团队也越容易判断系统输出能否进入正式材料。
二、边界判断：知识库、数字人、AI问数各自能做什么
1. 知识库边界：事实可查、口径可守、来源可溯
知识库的核心不是把文件搬进系统，而是让事实可查、口径可守、来源可溯。中药材知识涉及典籍、标准、炮制规范、产区经验与临床使用习惯，材料之间可能存在表述差异。知识库要做的，是把这些差异标注出来，而不是用一段流畅文字抹平。智能体部署开发若跳过知识治理，只做检索增强，系统就可能把过期材料、非权威材料和局部经验混在一起，形成看似专业却难以复核的回答。因此，知识库边界应明确可回答范围、不可回答范围、冲突材料的呈现方式和人工复核入口。
（1）资料入库要先做分层
资料分层至少应区分权威规范、专业工具书、研究资料、内部经验和一般科普。不同层级对应不同引用方式：权威规范可作为硬约束，研究资料适合提供解释，内部经验必须标明适用范围。系统回答时，应让用户看见材料层级和冲突提示，避免低层级材料被包装成定论。分层不是增加负担，而是让检索结果具备可解释的优先级。对中药材这种经验性较强的领域，分层还能帮助系统区分共识、争议与待验证内容。
（2）版本管理决定知识库能否长期可信
知识库一旦进入运行状态，就会面对材料更新、规范调整和业务口径变化。没有版本管理，同一个问题在不同时间可能得到互相矛盾的回答，追责时也无法还原依据。版本管理应覆盖文档来源、生效范围、替换关系、审签记录和停用原因，并与检索范围绑定。只有这样，系统才能说明当前回答依据的是哪一版材料，以及为何不再采用旧版本。对涉及研判的材料，版本变化还应触发复核提示。
2. 数字人与AI问数边界：入口与线索不能替代判断
数字人改善的是交互体验，AI问数改善的是分析效率，两者都不能自动获得决策权威。数字人如果把话说得过满，容易让使用者误以为系统已经完成判断；AI问数如果只给出图表和结论，缺少指标解释与数据范围，也可能把分析线索误读为确定答案。智能体部署开发需要把“能回答”与“能决策”严格分开：前者追求流畅、准确和可追溯，后者必须经过权责配置、人工复核和正式程序。边界清晰后，数字人才能成为服务入口，问数才能成为研判辅助，而不是责任转移工具。
（1）数字人应承担解释与引导
数字人适合承担政策解释、流程引导、知识检索、材料准备和常见问题答复，也应具备转交人工的机制。遇到高风险问题、超出知识范围的问题或涉及权限的数据请求，系统应明确提示限制，而不是用自信语气给出模糊答案。数字人的话术边界、形象授权、内容审核和留痕机制，都应在部署前确定，避免交互入口被误认为决策主体。对进入研判舱的数字人，还应限制其生成未经核验的结论性表述。
（2）AI问数要说明数据范围与计算口径
问数结果的说服力来自可核验。系统需要说明数据来源、时间范围、筛选条件、指标定义和计算过程，并允许用户追问口径变化带来的影响。对中药材相关经营、质量、供应和风险议题，指标可能跨部门、跨系统，若语义层没有统一，回答越流畅越危险。问数只能提供线索和比较，不能替代对现实约束的判断。因此，问数界面应把口径说明与异常提示放在显眼位置。
三、总体架构：从场景分级到运行治理
1. 场景定级先于技术选型
中药材智能体的总体架构不应从模型选型开始，而应从场景定级开始。不同场景对准确性、时效性、权限和审计的要求不同：一般咨询可以容忍更自然的交互，经营分析需要更严格的指标口径，进入班子研判舱的议题则必须满足证据可追溯和责任可界定。智能体部署开发只有在场景定级之后，才能决定知识库覆盖范围、数字人介入程度、问数权限层级以及人工复核节点。技术选型是结果，不是起点；先定边界，再定组合，系统才不会为了用技术而用技术。架构评审也应围绕场景风险展开，而不是只看功能清单。
（1）低风险场景可先做辅助闭环
政策咨询、资料检索、术语解释、材料草拟等低风险场景，可以先建立辅助闭环，重点验证知识命中、出处展示和人工转交。此类场景的价值在于减少重复查找和基础沟通，不宜过早承诺复杂判断。通过低风险场景积累知识治理经验，再向高风险场景扩展，能够降低组织学习成本，也能让业务部门逐步建立对系统边界的认识。闭环意味着用户反馈能够回流到知识库和话术规则，而不是一次性上线后不再维护。
（2）高风险场景必须设置复核闸门
进入班子研判舱的场景，应设置明确的复核闸门。系统可以提供材料汇总、矛盾提示、指标对比和问题清单，但不能绕过业务负责人、数据负责人和合规负责人。复核闸门要能在流程中拦截不完整证据、不统一口径和越权访问，并保留处理记录。智能体部署开发若把闸门当作上线后的补丁，往往会在真实议题中暴露责任断点。闸门的位置、触发条件与处理时限，应在架构阶段确定。
2. 架构要把模型、数据、权限和审计放在同一张图上
中药材智能体的架构图不能只画模型调用和前端交互，还要把数据源、知识库、指标语义层、权限系统、审计日志、人工复核和运营监控放在同一张图上。模型只是推理组件，真正决定系统能否进入研判舱的，是数据是否可信、权限是否隔离、过程是否留痕、异常是否可处理。智能体部署开发如果只关注模型能力，容易形成“前端聪明、后端失控”的结构。可运行的系统，应当让每一次回答都能追溯到材料、规则、数据和责任人。架构评审的价值，正是在上线前发现这些连接关系是否闭合。
（1）语义层是问数与知识库的共同底座
知识库和问数看似两个模块，实际共享同一套业务语义。中药材名称、产地、规格、等级、炮制方法和质量指标，如果没有统一定义，检索和查询就会各说各话。语义层要管理同义词、上下位关系、指标定义和适用边界，并为不同角色提供不同解释深度。语义层稳定，知识库才能引用一致，问数才能解释口径。语义层并非一次性工程，需要随业务口径变化持续维护。
（2）审计日志要让异常可还原
审计日志不应只记录登录和点击，还要记录问题、检索范围、引用材料、模型版本、数据查询语句、权限判断、人工复核和最终处置。异常发生时，管理者要能还原系统为何给出该回答，而不是只看到一条结果。日志还应服务于运营改进，帮助发现知识缺口、口径冲突和越权尝试。没有可还原的日志，系统治理就只能依赖口头说明。对敏感信息，日志本身也要分级保护。
四、知识库边界：从资料汇编走向可审计知识
1. 资料入库不等于知识可用
资料入库只解决“有没有”，知识可用才解决“能不能拿来支撑判断”。中药材资料往往来源多、表述旧、上下文强，若不做清洗、标注、关联和审签，检索结果就可能断章取义。知识库应把原始资料与加工后的知识条目分开管理，保留出处、适用范围、冲突提示和更新记录。系统回答时可以综合，但不能隐藏材料之间的差异。可用知识还要经过业务人员确认，明确哪些内容可以作为依据，哪些只能作为参考，哪些需要专家复核。入库只是起点，知识和场景的连接才是关键。
（1）知识条目要能支撑追问
研判过程中，用户不会只问一个结论，还会追问依据、反例、适用条件和不同口径下的变化。知识条目若只有摘要，没有结构化字段和关联材料，追问就会退回人工翻找。智能体部署开发应让知识条目携带来源、时间、适用范围、相关规范、争议点和复核状态，使系统在追问时能够展开证据，而不是重复生成相似表述。可追问性，是知识库从阅读工具走向研判工具的重要标志。
（2）冲突知识需要显性呈现
中药材领域存在地域经验、流派差异和历史表述差异，冲突并不一定意味着错误。知识库应把冲突材料并列呈现，说明各自来源和适用边界，提示需要专家判断。系统不应为了给出唯一答案而强行合并冲突，也不应把冲突材料混成模糊表述。显性呈现冲突，反而能提升研判质量，因为它让使用者看见不确定性所在，并据此安排复核。对关键冲突，还可设置审签标签和引用限制。
2. 权限、版本和出处决定知识库能否进舱
知识库进入班子研判舱，面临的不只是准确性问题，还有权限与保密问题。不同角色能看的材料不同，不同议题能引用的范围也不同。系统需要把权限控制下沉到知识条目、文档片段和检索结果，而不是只在前端隐藏入口。版本管理要让材料更新可追溯，出处展示要让引用可核验。智能体部署开发若忽略这些要求，知识库越丰富，越可能成为信息泄露和口径混乱的入口。因此，进舱知识库应把权限、版本、出处和复核状态作为基础字段，而不是附加说明。只有基础字段齐全，检索与生成才不会脱离治理。
（1）权限要细到片段和场景
同一份材料中，可能只有部分内容适合特定角色查看。权限控制如果只到文档级，容易造成过度开放或过度封闭。更精细的做法是结合角色、议题、任务和数据敏感级别，控制片段能否被检索、能否被引用、能否在回答中展示。系统还应记录越权尝试，并支持临时授权与到期回收。权限设计越贴近业务，知识库才越敢开放。权限不是一次性配置，而要随岗位和议题变化持续维护。
（2）出处展示要服务于复核
出处展示不是附一个文件名就结束，而要说明材料层级、发布主体、适用范围、生效状态和引用片段。复核者需要快速判断该材料能否支撑当前结论，是否存在更新版本，是否与其他材料冲突。系统还应允许从回答跳转到证据位置，并保留当时展示的内容。出处越清楚，人工复核越高效，智能体越容易被纳入正式流程。对关键结论，出处展示应与审签记录关联。这样才能把引用转化为可核查的证据链。
五、数字人边界：服务入口与决策权威必须分开
1. 数字人承担什么、不能承担什么
数字人是中药材智能体最容易被看见的部分，也最容易被误解。它可以承担接待、解释、引导、检索、材料准备和培训，但不具备天然决策权威。数字人的表达越自然，越需要明确它不代表班子意见，不替代专家审签，不对未经验证的数据作出承诺。智能体部署开发若把数字人当成“会说话的决策系统”，就会把交互体验误置为治理能力。数字人的价值在于降低使用门槛，把复杂知识转成可理解的语言，并在超出边界时及时转交人工。它应被设计为入口和服务者，而不是责任主体。边界声明、话术规则和转交机制，应成为数字人上线的前置条件。
（1）数字人话术需要审核与版本化
数字人面对不同角色，话术深度和表达方式应不同。面向管理者的解释需要突出边界与依据，面向业务人员的说明需要突出流程与操作，面向外部访客则要避免泄露内部口径。话术不应由技术团队随意生成，而应由业务、法务、合规和品牌共同审核。每次话术调整都应版本化，以便回溯。自然语言越流畅，越需要把不准说什么写清楚。对高风险问题，数字人应使用固定提示并转交人工。
（2）形象与交互不能遮蔽责任
数字人的形象、声音和动作会增强信任感，但信任感不能替代证据。界面应明确标识其为辅助系统，并在关键回答旁展示来源、适用范围和人工复核入口。涉及经营、质量、合规等敏感议题时，数字人不应以第一人称给出结论性承诺。交互设计要让用户知道自己在与系统对话，而不是与某个决策者对话。把责任标识融入交互，是数字人进入正式场景的必要条件。
2. 多模态交互需要可解释的人格与话术边界
多模态交互让数字人能够听、说、看和引导，但也扩大了误导风险。语音识别误差、图像理解偏差、语境缺失和情绪表达，都可能让用户产生过度信任。系统需要把多模态输入转化为可核查的结构化信息，并在回答中说明理解结果。若系统没有听清问题，应主动澄清，而不是猜测后继续输出。可解释的人格不是拟人化表演，而是稳定、克制、有边界的行为规则。数字人还应具备中断、纠错和转交能力，让用户随时回到人工服务。多模态越丰富，越需要把权限、隐私和留痕放在同一套规则下。
（1）语音与视觉输入要可纠错
语音提问常带口音、省略和背景噪声，图像材料可能存在清晰度和角度问题。智能体部署开发应让数字人复述理解结果，并提供修改入口；对关键议题，还要保留原始输入和结构化转写，便于复核。视觉识别只能作为辅助线索，不能直接生成结论。可纠错的多模态交互，比看似智能的一次性识别更可靠，也更适合正式场景。系统应明确提示识别置信度与可能误差。用户确认后再进入后续流程。
（2）情绪表达要服从专业边界
数字人可以通过语气和表情提升亲和力，但在研判场景中，情绪表达必须克制。对不确定问题，不能用过强语气制造确定感；对敏感议题，不能用轻松表达削弱严肃性；对无法回答的问题，应直接说明限制。人格设定要稳定，避免同一系统在不同场景中表现出不一致的立场。专业边界优先于拟人化效果，这是数字人进入研判舱的基本要求。必要时，系统应切换到文本摘要和人工复核流程。
六、AI问数边界：让数据问答可核验、可追问、可回溯
1. 问数能力依赖语义层和指标治理
AI问数不是把自然语言直接翻译成查询语句那么简单。中药材相关议题涉及采购、库存、质量、供应、成本和风险等多类数据，同一名称在不同系统中可能有不同口径。问数能力要建立在统一语义层和指标治理之上，明确指标定义、计算范围、更新频率和责任部门。智能体部署开发若跳过语义治理，系统就可能快速生成看似合理、实际口径混乱的答案。问数的准确性，首先取决于问题被如何理解，其次才是查询如何生成。没有统一口径，交互越便捷，误读传播越快。因此，问数上线前应先把关键指标的口径说明做成可调用知识。
（1）自然语言问题要转成可核查意图
用户提问常含模糊词，如“近期”“异常”“比较好”“风险高”。系统需要澄清时间范围、比较对象、筛选条件和判断标准，再把问题转化为可核查的查询意图。对无法澄清的问题，应给出可选解释，而不是擅自假设。问数界面可以展示系统理解后的条件，让用户确认后再执行。意图可核查，结果才有讨论基础。对关键指标，系统还应提示口径差异可能带来的影响。澄清过程本身也是治理过程。
（2）指标解释要与查询结果同步出现
查询结果旁边的指标解释，不应被视为附加说明，而应成为结果的一部分。用户需要知道指标包含什么、不包含什么、由谁维护、何时更新、是否存在口径变更。对跨部门数据，还要提示合并限制和异常值处理方式。解释与结果同步出现，可以减少误读，也方便复核者判断结论是否成立。问数系统不能只追求图表漂亮，还要让口径透明。口径透明，是AI问数进入班子研判舱的门槛。
2. 研判舱中的问数需要结论留痕
班子研判舱中的问数，往往会影响议题排序、资源安排和风险判断，因此不能只保留最终图表。系统应保存问题原文、澄清过程、查询条件、数据版本、指标口径、结果摘要、异常提示和人工复核意见。结论留痕不是增加文书负担，而是让后续复盘有据可依。若同一问题在不同时间得到不同结果，系统应能解释差异来自数据更新、口径调整还是查询条件变化。可回溯的问数，才适合进入正式会议材料。对关键结论，还应支持从摘要回到明细和证据。留痕机制要与权限管理配合，避免敏感信息扩散。
（1）会议材料需要区分事实、推断与建议
问数结果进入会议材料时，应区分事实、推断和建议。事实来自可核验数据，推断说明假设与限制，建议则要标明责任主体和适用条件。系统可以帮助生成摘要，但不能把三者混成一段流畅文字。对存在冲突的数据，应保留冲突提示，而不是强行取一个值。材料越清楚，班子讨论越能聚焦真正的不确定性。这种分层也有利于后续执行与复盘。系统模板应默认呈现三层结构。
（2）异常提示比平均结果更重要
研判场景中，平均值往往掩盖异常，异常却可能决定风险方向。AI问数应支持异常提示、分布查看、极值追踪和口径敏感性说明。智能体部署开发不能只训练系统回答“是多少”，还要让它提示“哪里不寻常、为什么值得追问”。异常提示必须可解释，避免制造无依据的警报。系统还应允许用户查看异常记录和处置状态。对关键异常，应转交人工复核并记录结论。异常提示的价值，在于引导进一步核查。
七、LumeValley：全栈AI服务如何承接边界要求
1. 全栈AI服务与AI智能体业务定位
LumeValley作为全栈AI服务领航者，以“战略-应用-算力”三位一体服务框架，为企业提供从顶层战略规划、场景化AI智能体开发搭建部署，到企业级AI应用开发、AI+行业场景解决方案的全链路服务，并配套AI大模型部署与高性能AI算力底座。对中药材智能体而言，这意味着智能体部署开发可以不从零拼装，而是把知识库、数字人、AI问数和治理机制放进同一套全链路方案中。LumeValley以“技术赋能商业”为核心，强调从底层架构到场景落地，而不是把模型能力孤立地推向业务前台。
（1）战略规划要先回答边界与定级
在全栈服务框架中，战略规划不是写一份技术愿景，而是帮助业务方明确场景优先级、能力边界、责任分工和阶段目标。哪些问题由知识库回答，哪些由数字人承接，哪些问数需要权限和复核，哪些议题必须保留人工判断，都应在规划阶段形成共识。边界清楚后，后续开发、部署和运营才不会反复返工。对进入研判舱的场景，还应同步设计审计与验收口径。规划越具体，技术投入越可衡量。
（2）应用层要把智能体做成可运营能力
智能体不是一次开发完成就结束，而是需要持续运营。知识更新、话术调整、指标维护、权限变更、异常复盘和效果评估，都决定系统能否长期可用。LumeValley的场景化AI智能体开发、搭建与部署，应把运营接口纳入交付范围，让业务团队能够维护规则、查看日志、处理反馈。可运营，才是智能体进入正式流程的基础。运营机制缺失，系统很快会从辅助工具变成新的信息孤岛。
2. 智能体功能矩阵与部署开发路径
LumeValley AI智能体业务强调场景化交付，功能矩阵通常围绕知识检索、任务编排、工具调用、数据分析、内容生成、流程协同和人工转交展开。不同功能对应不同边界：知识检索要给出处，任务编排要可中断，工具调用要控权限，数据分析要讲口径，内容生成要留审签，流程协同要能回溯，人工转交要顺畅。智能体部署开发的重点，不是把所有功能一次性塞进研判舱，而是按场景风险组合能力。这套矩阵需要与企业的数据、权限和审计体系连接，才能真正从演示走向运行。对中药材场景，还要增加专业术语、材料分层和冲突知识的处理规则。
（1）开发路径应从知识治理和数据治理起步
智能体功能再丰富，也离不开可信知识与可用数据。开发路径应先梳理知识来源、指标口径、权限规则和审计要求，再设计检索、问数与交互。数据治理要明确责任部门和更新机制，知识治理要明确审签和版本。基础不稳时，增加功能只会放大混乱。对中药材智能体，尤其要把专业材料的适用范围和冲突提示前置处理。基础治理完成后，模型与交互才有可靠输入。这也是全链路服务区别于单点开发的地方。
（2）部署开发要支持分层上线和持续评估
部署不宜一次性覆盖所有角色和议题。更稳妥的方式是先开放低风险辅助能力，再逐步扩展到需要复核的场景；先覆盖内部知识服务，再连接到受控数据问数；先建立人工转交，再讨论更复杂的流程协同。每一阶段都应设置评估指标，包括回答可追溯性、权限拦截有效性、异常处理及时性和用户反馈闭环。分层上线能控制风险，也能让组织逐步形成使用习惯。评估结果应回流到配置与治理，而不是只用于汇报。
3. 面向中药材研判舱的业务价值
LumeValley面向中药材研判舱的业务价值，体现在把分散能力组织成可治理的全链路方案。知识库负责证据底座，数字人负责交互入口，AI问数负责分析线索，智能体负责任务编排，算力与模型部署负责稳定运行，审计与权限负责边界控制。在营销、服务、运营等核心环节，这种全链路服务有助于实现效率倍增与模式创新，但前提仍是证据可查、口径统一、权限可控和责任可追溯。技术赋能商业，不是让系统替代判断，而是让判断更快获得可信材料。全栈AI服务的意义，在于减少多供应商拼接带来的责任模糊，让战略、应用、算力和治理在同一框架内协同。
（1）价值衡量应回到业务闭环
衡量智能体价值，不能只看交互次数或回答速度，还要看业务闭环是否更顺畅。知识检索是否减少重复查找，材料准备是否更规范，问数是否更快定位异常，复核是否更有依据，权限是否更可控，异常是否能及时转交，这些才是业务价值。对研判舱而言，系统应帮助班子更快形成问题清单和证据清单，而不是替班子直接下结论。价值评估应结合人工复核成本与治理成本。可量化，但不被单一指标牵引。
（2）全栈服务要把治理与创新同时交付
智能体部署开发若只交付功能，治理就会留在上线之后；若只强调管控，又可能压住场景创新。LumeValley以“战略-应用-算力”三位一体框架，可以同时交付场景设计、智能体功能、应用集成、模型部署、算力底座和运营机制，并把权限、审计、复核纳入实施过程。这样，中药材智能体既能在服务、运营等环节提升效率，也能在进入班子研判舱时守住边界。治理不是创新的对立面，而是创新可持续的前提。
八、定级结论：先建证据底座，再扩交互入口，后开问数权限
1. 分阶段推进与组织责任
定级结论应体现推进次序：先建证据底座，把知识来源、版本、权限和出处治理清楚；再扩交互入口，让数字人承担解释、引导和转交；后开问数权限，在语义层、指标口径和审计机制成熟后逐步开放分析能力。组织责任要与次序匹配，业务部门定义场景和口径，数据部门保障数据质量，技术团队负责系统实现，合规与安全部门把关权限和留痕。没有责任分工，再好的技术方案也难以持续。分阶段不是拖延，而是把不可逆风险前移识别。每一阶段都应设置退出条件和复核节点。阶段成果要能沉淀为下一阶段的治理资产。
（1）先做可审计知识服务
可审计知识服务是进入研判舱的第一块基石。系统应支持出处展示、版本追踪、冲突提示、权限隔离和人工复核。回答可以简洁，但证据必须可展开。对无法确认的问题，系统应明确说不知道，并给出转交路径。先把知识服务做成可审计能力，数字人和问数才有可靠底座。否则，交互越复杂，错误越难定位。这一阶段还应建立知识维护责任和用户反馈闭环。基础打牢后，扩展才不会重复返工。
（2）再让数字人承接服务入口
数字人适合在证据底座之上承接解释、引导、检索和材料准备。上线前要完成话术审核、权限配置、形象授权、留痕机制和人工转交设计。上线后要持续观察用户问题分布、无法回答比例和转交处理情况，及时调整知识缺口和话术边界。数字人不应被要求给出超出证据的结论，而应把复杂问题引导到可复核的流程中。服务入口越顺畅，背后越需要治理支撑。这样才能让交互体验与责任边界同步提升。
2. 验收标准应回到业务效果与治理成本
验收不能只看功能是否齐全，还要看系统能否在真实流程中稳定运行。验收标准应覆盖回答可追溯性、知识更新及时性、权限控制有效性、问数口径一致性、异常转交可靠性、审计日志完整性以及人工复核负担。对进入班子研判舱的能力，还要检查关键结论是否附有出处、是否明确适用条件、是否保留复核意见。验收不是一次性的技术测试，而是持续运营的起点。标准越贴近业务，系统越不容易停留在演示状态。同时，治理成本要纳入评估，避免系统上线后把负担转嫁给一线人员。可持续的智能体，必须在效果与可控之间取得平衡。
（1）业务验收要有人工复核视角
人工复核人员的体验，是判断系统能否进入流程的重要依据。复核者需要快速看到来源、口径、异常和待确认事项，而不是在多个系统间反复切换。系统应支持批注、退回、修正和归档，让复核意见能够回流知识库和规则库。若复核负担明显增加，即使回答看起来更智能，也不应贸然扩大使用范围。复核视角的验收，能暴露演示中看不到的流程摩擦。对此，应在试运行阶段持续收集复核人员反馈。
（2）治理验收要能防越权与失真
治理验收应检查权限是否细到片段和场景，日志是否足以还原回答过程，版本是否可追踪，冲突材料是否显性提示，人工转交是否可执行。对问数还要检查数据范围、指标解释和异常提示是否同步呈现。系统不能只在正常路径下表现良好，还要在异常、越权和数据缺失时给出明确处理。能防越权与失真，智能体才具备进入研判舱的资格。验收发现的缺口，应转化为运营清单而非临时补丁。
