面向智能体调度：企业知识库从“被检索”升级为“被调用”

真正要改造的是调用边界，不是聊天界面

传统知识库主要响应人的查询：用户输入问题，系统返回文档、片段或答案。进入智能体工作流后，调用者可能是负责拆解任务和选择工具的智能体。它要判断该查哪个知识库、传入什么参数、返回内容是否足够，以及下一步是继续检索、调用业务工具还是转交人工。

腾讯云的资料展示了按问题复杂度分流的方式：简单问题进入普通知识问答节点，复杂问题交给可执行多阶段检索的Agentic RAG工具。AWS参考架构则把不同知识库映射为独立检索工具，由智能体根据问题主题选择；上下文不足时，可以继续调用其他知识库。这些是特定平台的实现，不能证明所有系统都应采用同一种编排方式，但都提出了一个实际要求：知识库必须成为边界清楚、能被机器识别和调用的能力。

因此，升级工作的第一批交付物不应只有新的对话入口。更值得优先明确的是：每个知识工具解决什么问题、允许谁调用、接受哪些参数、返回什么结构，以及在哪些条件下必须停止。聊天界面以后可以更换，模糊的调用边界却会持续引发误选知识库、越权访问和错误执行。

第一步应把只读检索封装成明确的工具

可调用知识库需要一份稳定的工具契约。工具说明至少要覆盖用途、适用任务、输入字段、返回结构、知识范围、身份要求、错误状态和调用限制。名称也要能区分职责。例如，“查询产品安装规范”和“查询客户合同条款”比“企业知识搜索”更容易被正确选择。

不同产品给出了一些可参考的控制方式。Algolia使用索引说明帮助模型选择目录，并设置工具执行次数、令牌预算、访问域名、速率及输入输出限制。Rubrik公布的MCP方案则计划通过API schema向获得授权的智能体暴露平台能力，并沿用角色访问控制和可配置权限。需要注意，Rubrik公告发布时该功能仍处于面向现有客户的私有预览阶段，计划于2026年10月正式可用，不能据此判断它已经具备普遍采购和生产部署条件。这些方案可以作为工具化设计参考，企业仍需根据自身的数据分类、权限体系和产品可用状态确定边界。

多数企业更适合先开放只读检索，再考虑让智能体修改业务状态。只读阶段已经可以验证工具选择、参数构造、权限过滤、结果结构和知识依据，同时降低订单、网络配置、身份权限或人员数据被错误改写的风险。这是风险控制建议，不是所有项目都必须遵守的固定顺序。如果某项自动化动作风险低、参数范围固定，并且已有审批、幂等处理、回滚和审计，企业可以更早试点执行能力，但检索工具与写入工具仍应分开授权。

只读工具的验收不能停留在接口返回成功。测试集应包括正常问题、范围相近的问题、越权请求、过期信息、知识不足和参数错误。需要检查智能体是否选对工具、是否只读取获准内容、是否正确处理空结果，以及证据不足时会不会停止或改用其他知识库。

跨库调度需要范围说明和路由规则

企业同时维护产品、制度、客户、运维和合规知识库时，智能体需要的不是一份不断增长的文档目录，而是可以支持选择的范围信息。每个知识工具应注明主题、适用任务、数据时效、责任部门、权限要求和不处理的问题。名称相似但职责不同的知识库，还要说明调用优先级，以及内容冲突时以哪一方为准。

Meta介绍的合规知识架构将知识文件与recipes分开维护：知识文件保存专家立场、约束和边界，recipes规定检查信息、加载知识和形成分析的顺序，顶层路由再按任务阶段选择下游流程。其效果来自特定系统，不能直接推算到其他企业。更有普遍参考价值的是资产分离思路，即把“判断依据是什么”和“何时、按什么顺序使用”分别管理。

实际编排时，可以先为每个工具建立正例和反例。正例说明哪些任务应调用它，反例说明哪些相似任务不应调用它。涉及多个知识域的任务则拆成阶段，例如先确认客户权限，再查询合同规则，最后读取产品操作规范。这样既能限制每一步可见的数据，也便于判断错误发生在选库、检索还是后续流程。

如果路由长期不稳定，编辑上更合理的排查顺序是先检查工具说明是否重叠、标签是否含糊、任务是否需要分阶段，以及返回结构能否反映信息是否充分。这个顺序基于可直接检查和修改的系统边界，不代表模型更换一定无效，也没有资料证明工具说明在所有场景下都比模型能力影响更大。是否需要调整模型，应使用同一组任务分别测试现有配置、修订后的工具说明和候选模型，并比较误选工具、重复调用、漏检及停止条件执行情况。

知识依据和业务动作必须分开授权

知识工具提供判断依据，业务工具改变实际状态。两者如果共用一个宽泛入口，系统就难以区分“查到可以退款”和“已经执行退款”，也无法分别设置权限、审批与失败处理。Salesforce提出的AI Harness将可信上下文、智能体编排和业务动作分开：智能体先结合知识与实时信号形成判断，再通过工具预留库存、更新订单、触发履约或转交人工，执行结果随后回流为新的上下文。

开放业务动作时，可以按风险划分四级能力：只读查询只返回获准知识；生成建议形成方案但不改变业务状态；提交审批生成待确认的操作；自动执行仅处理边界明确、可审计且可恢复的动作。这不是统一的行业分级，而是一种便于企业配置控制措施的方法。每一级都应对应不同的身份、参数范围、审批条件和回滚要求。

Beeline的方案让智能体继承现有人类用户的身份验证、角色权限和审批层级，并继续要求人员分类、合规判断等高风险事项由人工参与。Zayo也允许组织分别限定智能体可见的信息、可使用的工具和可执行的动作。这些案例支持一个治理判断：接入智能体不应绕开既有权限体系。至于哪些动作可以自动执行，仍取决于企业自身的风险评估、异常处理能力和监管要求。

对资金、合同、网络配置、身份权限、人员决策和合规状态有影响的动作，上线前至少要回答四个问题：谁以什么身份发起，哪些参数可以修改，什么条件触发审批，失败后如何撤销或补偿。任何一项无法验证，系统都应停留在查询或建议阶段，不能因为答案看起来合理就直接写入业务系统。

验收要覆盖整条调用链，而不只看最终答案

面向人的知识库通常重点检查答案相关性和正确性。面向智能体调度后，验收对象还包括任务如何拆解、选择了什么工具、传入哪些参数、读取了哪些知识范围、调用了多少次、何时触发审批，以及最终动作是否符合权限。AWS参考架构记录推理与行动循环、工具调用、令牌使用和评估指标；腾讯云资料也提供Agent、Skill与工作流之间的层级调用信息。

知识和流程可以分别维护，但要在同一组任务中回归。Meta将专家反馈归类为知识缺口、流程问题或真实歧义，并通过审查、回放和回归测试更新系统。企业可以采用类似的问题分类：答案依据错误时修订知识，工具选择错误时调整路由，步骤顺序错误时修改流程，权限越界时收紧工具契约或审批条件。真实歧义不应被强行改写成唯一答案，应保留条件说明或转交人工。

一组可执行的验收题至少应覆盖五类情况：单库可以回答的问题、必须跨库组合的问题、用户无权访问的问题、现有知识不足的问题，以及可能触发业务动作的问题。每道题都要记录预期工具、允许参数、权限结果、停止条件和是否需要人工审批。系统升级模型、修改工具说明或更新知识后，应重复运行同一组任务，比较改动前后的结果。

最终标准不只是智能体答对了多少题，还要看它是否在正确条件下调用正确知识，是否在信息不足时停止，是否遵守权限，是否区分建议与执行，以及失败能否被定位和回放。只有这些结果可以持续验证，知识库才具备被智能体调用的基础。否则，它仍是被自动化流程包裹的搜索入口。