前面的文章我们已经分别介绍了 Context Engineering、Function Calling、Structured Output、RAG、Agent Loop、状态机和 Memory。这些能力单独使用时并不复杂。真正进入企业应用以后问题变成怎样把这些能力组合成一个真正可以被员工使用的知识助手早期企业知识助手通常可以概括为上传文档 → 建知识库 → 用户提问 → RAG → 大模型回答。但到了 2026 年这已经只能算知识库问答系统。一个真正完整的企业知识助手还应该知道当前用户是谁可以访问哪些知识简单问题应该直接检索复杂问题是否需要多轮 Agentic RAG答案依据了哪些原文什么时候应该查询数据库或业务系统而不是继续搜索文档用户过去确认过哪些偏好和决策工具调用是否需要审批出错发生在检索、Tool、模型还是权限环节模型升级以后效果是否真的变好。因此企业知识助手真正需要建设的不是一个“聊天框”而是一套Knowledge Agent Tool Memory Governance组成的 AI 应用运行体系。一、先明确我们要开发的不是“企业版 ChatGPT”一个常见误区是把企业知识助手理解成给通用大模型增加一个企业知识库。这种产品当然有价值但能力边界仍然比较窄。例如员工问“上海地区销售人员出差住宿标准是多少”普通 RAG 可以很好地回答。但如果继续问“我下周要去上海参加客户交流根据公司制度帮我确认预算并查询当前项目还有多少差旅预算如果足够就生成一份出差申请”。任务已经发生变化。系统至少需要需求需要的能力查询差旅制度RAG查找适用地区和人员标准Metadata / Permission Filter查询项目剩余预算Tool / Business API理解用户和当前项目Context / Memory生成出差申请Structured Output提交申请Tool Calling高风险提交前确认Human-in-the-Loop记录整个执行过程Trace所以企业知识助手真正的演进是Knowledge Assistant → Enterprise Agent知识仍然是核心但已经不是全部。二、一个完整企业知识助手应该具备哪些能力可以把系统能力分成五层。层次核心能力交互层对话、多轮、流式输出、文件上传Agent 层意图判断、路由、规划、Tool CallingKnowledge 层RAG、Agentic RAG、Citation、MetadataContext 层Session、State、Memory、WorkspaceGovernance 层Permission、Audit、Trace、Evaluation这五层有一个非常重要的分工Knowledge 层负责“知道什么”Agent 层负责“下一步做什么”Governance 层负责“允许做到什么”。因此一个比较完整的架构可以设计为三、知识层从“每次都 RAG”升级为按复杂度选择策略前面的 RAG 文章已经介绍过 Hybrid Search、Rerank、Query Rewrite 和 Agentic RAG这里不再重复原理。完整企业知识助手真正需要解决的是什么时候用哪一种检索方式一个简单策略可以是问题类型推荐方式简单制度查询Traditional RAG精确编号 / 产品编码Keyword Metadata多文档综合Agentic RAG多条件筛选Agentic RAG数据计算RAG Tool / SQL实时信息Tool / Search企业系统数据Connector / API也就是说不应该设计成所有问题 → Vector Search → LLM而应该先进行 Routing。例如if query.type simple_knowledge: return rag.search(query) if query.type complex_knowledge: return agentic_rag.run(query) if query.type business_data: return tool_agent.run(query)2026 年 Agentic RAG 已经开始成为正式产品能力。腾讯云 ADP 当前的 Agentic RAG 可以自主规划检索策略、反思首次结果并进行多轮检索其知识库检索 Agent 还能组合知识检索、SQL 和计算工具处理跨文档以及数据分析问题。这意味着现代企业知识助手正在从Retrieval Pipeline升级到Retrieval Decision System四、知识库本身也在发生变化Metadata 正在变得越来越重要传统知识库主要保存Chunk、Embedding、DocumentId。但企业数据通常具有非常明确的业务属性产品、部门、地区、版本、生效时间、文档类型、密级、作者、租户。这些数据应该成为 Metadata。例如{ department: 销售部, region: 上海, effectiveDate: 2026-01-01, documentType: 差旅制度 }用户询问“上海销售人员当前住宿标准”。系统首先就可以过滤department 销售部 region 上海 effectiveDate today然后再执行语义搜索。这样往往比单纯依赖 Embedding 更准确。2026 年 9 月腾讯云 ADP 已经进一步把 Metadata 引入知识库召回同时增加知识源定时更新能力这也说明企业 RAG 正从单纯“向量相似度”继续走向结构化过滤 内容检索 知识生命周期管理。五、权限过滤必须发生在检索之前企业知识助手和公共知识问答最大的区别之一就是同一个问题不同用户可能看到不同答案。例如员工→ 可以查询普通制度部门经理→ 可以查询部门经营资料财务人员→ 可以查询财务制度和预算高管→ 可以访问经营分析材料。因此不能设计成检索整个知识库→把内容交给 LLM→最后再判断能不能展示。因为敏感内容已经进入模型 Context。正确方式应该是User IdentityTenant / Department / Role→Permission Filter→Allowed Knowledge Scope→Retrieval。也就是说Permission 是 Retrieval 的前置条件而不是答案生成后的过滤器。对于多租户系统还必须保证Tenant A的 Chunk 在任何情况下都不会进入Tenant B用户的 Candidate Recall。这是企业知识助手必须坚持的安全边界。六、引用不是 UI 装饰而是答案的数据结构一个企业知识助手回答“上海住宿标准为 600 元 / 晚” 还不够。真正可靠的答案应该包含答案EvidenceCitation。例如上海地区普通员工住宿标准 600 元 / 晚。 依据 《2026 年差旅管理办法》 第三章第 12 条 第 8 页因此 Retriever 返回的不能只是content还应该保留documentId、documentName、version、page、section、chunkId、score。最终 Answer 可以设计为record KnowledgeAnswer( String answer, ListCitation citations, double confidence ) {}这实际上把前面 Structured Output 的思想重新带回来了企业知识助手的最终输出不是一段字符串而是“答案 证据”的结构化结果。七、Tool当知识库不能回答时不要继续搜索知识库这是知识助手升级为 Agent 最重要的一步。例如用户问“我的报销申请现在审批到哪里了”这个答案根本不应该来自 RAG。它来自审批系统 API。再例如“项目还剩多少预算”应该查询Project / Finance System。因此 Knowledge Assistant 至少需要Knowledge Tool、Business Tool、Search Tool、Calculation Tool模型根据问题选择能力。例如查询差旅制度 → search_knowledge 查询剩余预算 → get_project_budget 提交出差申请 → create_travel_requestOpenAI 当前 Responses API 已经把file_search、Function Calling、Web Search、远程 MCP 等工具统一到同一工具体系中其中file_search本身支持语义和关键词检索并由平台托管执行。DeepSeek 当前同样支持 Tool Calls并提供strict模式来约束模型严格按照 Function JSON Schema 生成参数。这说明 Tool Calling 已经逐渐成为现代 Agent 的基础设施而不再是某个特定框架的附加能力。八、MCP 正在成为企业知识助手连接外部能力的重要接口层如果每接一个系统都自己设计CRM Adapter、OA Adapter、ERP Adapter、Git Adapter、Database Adapter企业 Agent 很快会进入大量重复集成工作。MCP 的价值就是逐渐把Agent ↔ Tool / Data之间的连接方式标准化。当前 OpenAI 的工具体系已经支持 Remote MCP并且可以对 MCP Tool 设置自动执行或显式审批私有网络中的 MCP Server 也可以通过 Secure MCP Tunnel 接入而不必把内部服务直接暴露在公网。2026 年 7 月发布的 MCP2026-07-28规范又进一步增加了Stateless Protocol CoreMulti Round-Trip RequestsCacheable List ResultExtensionsAuthorization Hardening。这使 MCP 更接近真正适合企业网关、负载均衡和权限体系的 Agent 基础协议。因此企业知识助手中的 Tool Layer 可以逐渐演进为Agent Runtime │ ▼ MCP / Tool Gateway │ ┌────┼────────┐ ▼ ▼ ▼ OA CRM ERP而不是在 Prompt 中硬编码几十个业务接口。九、Memory让助手认识用户但不要污染企业知识上一篇已经专门讨论过 Memory这里只关注它在企业知识助手中的位置。企业知识助手通常至少会使用两种 MemorySession Memory解决“我们刚才聊到哪里了”User Long-term Memory解决“这个用户长期有什么稳定偏好”例如用户习惯中文回答、用户是研发人员、常用项目为 Project-A。但需要特别注意用户 Memory 与企业 Knowledge 必须分开。用户说“我记得公司报销标准是 800”。不能因为这句话被长期记忆就污染正式企业知识库。正确优先级应该是Authoritative KnowledgeBusiness System DataUser Memory。Memory 可以帮助 Agent理解用户但不能替代企业事实来源。十、把这些能力组合起来一次完整请求到底怎样执行来看一个完整例子。用户说“我下周要去上海参加客户交流根据公司制度看看我的住宿预算再查一下 Project-A 还有多少差旅预算如果够的话帮我生成出差申请”。系统首先识别用户身份、项目 Project-A、目标 出差申请。接下来并不是简单执行一次 RAG。第一步查询制度通过 Permission-aware RAG差旅制度地区 上海用户职级获得住宿标准并保存 Citation。第二步查询业务数据发现“剩余项目预算”不属于知识库于是调用get_project_budget(Project-A)获得实时预算。第三步进行计算与判断Agent 综合住宿标准出差天数剩余预算计算预算是否满足要求。第四步生成结构化申请利用 Structured Output 生成{ project: Project-A, city: 上海, hotelBudget: 1800, reason: 客户交流 }第五步人工确认因为create_travel_request会改变真实业务状态因此进入 Human-in-the-Loop是否提交用户确认后再真正调用业务系统。这一个场景已经把前面几篇内容全部连接起来能力在本场景中的作用Context当前用户和目标RAG查询制度Citation给出制度依据Memory用户和项目偏好Tool Calling查询预算Structured Output生成申请数据State保存当前执行进度Human Approval提交前确认这才是“完整企业知识助手”的真正含义。十一、代码层不需要写一个巨大的 KnowledgeAssistant从工程实现看不建议把所有逻辑都塞进一个KnowledgeAssistantService。更合理的是拆成稳定能力。例如interface KnowledgeRetriever { RetrievalResult search( Query query, UserContext user ); } interface MemoryService { ListMemory recall( UserContext user, String query ); } interface ToolExecutor { ToolResult execute( ToolCall call, UserContext user ); }Agent Runtime 只负责编排var context contextAssembler.build( user, session, memoryService, currentTask ); var result agent.run( context, knowledgeRetriever, toolExecutor );关键不是这几行 API而是避免形成Controller → Prompt → LLM → String这种难以扩展的结构。企业知识助手应该拥有独立的Knowledge、Memory、Tool、Session、Permission、Trace服务边界。十二、流式输出不仅要流 Token还要流“执行状态”普通 Chatbot 的 StreamingToken Token Token就够了。Agent 型知识助手则更适合向前端传递正在理解问题 正在检索知识库 找到 12 条候选资料 正在重新排序 正在查询业务系统 等待人工确认 正在生成最终答案也就是说 Streaming 的对象正在从文本流扩展成Agent Event Stream。例如前端可以接收{ type: retrieval_started }或者{ type: tool_completed, tool: get_project_budget }这样用户看到的不是一个长时间旋转的 Loading而是 Agent 当前实际在做什么。十三、可观测性企业知识助手必须能够回答“为什么这样回答”普通日志只记录Question Answer远远不够。完整 Trace 至少应该包含Original Query Rewritten Query Retrieved Documents Retrieval Score Rerank Result Memory Recall Model Calls Tool Calls Tool Result Permission Decision Citation Token Latency Cost Final AnswerOpenAI 当前 Agents SDK 的 Trace 可以记录模型调用、Tool Call、Handoff 和 Guardrail官方也建议先通过 Trace 调试 Agent 行为再进入系统化 Eval。当用户说“这个答案为什么错了”系统才能判断到底是知识没有入库 权限过滤错了 Query Rewrite 错了 Retriever 没召回 Rerank 排错 Tool 返回错误 还是模型推理错了这也是 Agent 可观测性与普通 API 日志最大的区别。十四、Evaluation知识助手上线以后不能只看“用户觉得还行”传统软件测试往往强调Input → Expected Output但 Agent 具有不确定性不能只靠几个人工 Demo 验证。至少应该建立一套企业 Golden Dataset问题 期望答案 允许访问的知识 必须引用的来源 不允许访问的内容 需要调用的 Tool 期望行为评估维度可以包括维度示例Retrieval Recall正确文档是否召回Citation Accuracy引用是否真的支持答案Answer Correctness最终回答是否正确Permission是否发生越权检索Tool Selection是否选择正确 ToolTask Completion是否真正完成用户目标Cost / Latency代价是否可接受现代 Agent Eval 也正在从只评价最终答案转向评价完整执行轨迹。OpenAI 当前的 Agent Evaluation 就支持基于 Trace 对模型调用、Tool Call、Guardrail 和 Handoff 等流程行为进行评分。因此企业知识助手的质量不是一个 Prompt 的质量而是一整条执行链的质量。十五、安全治理越强的知识助手越需要确定性的边界当知识助手只回答文档问题时风险主要是答错。当它开始拥有 Tool 后风险会变成做错。因此 Tool 应该分级。Tool风险search_knowledge低query_database中create_document中send_email高submit_approval高delete_data极高可以建立Read Tool→ 自动执行Write Tool→ 权限校验High-risk Tool→ 权限 Human Approval。同时必须防止Prompt Injection越权检索Tool 参数注入Memory Pollution敏感数据进入 TraceMCP Server 获得过宽权限。最新 MCP 规范也持续强化 Authorization2026-07-28 版本进一步加入了授权硬化和正式扩展体系Enterprise-Managed Authorization 也已经稳定用于集中管理企业 MCP 授权。因此企业知识助手真正需要的是Agent 自主决策 最小权限 确定性安全边界。十六、2026 年的企业知识助手正在发生哪些变化把最近的发展放在一起可以看到几个非常清晰的趋势。第一RAG 正在 Agentic 化简单问题继续使用传统 RAG复杂问题开始让 Agent 自主规划、多轮检索和交叉验证。第二知识库正在结构化Metadata、权限、版本和知识更新时间越来越重要不再只关注 Embedding。腾讯云 ADP 在 2026 年 9 月已经新增知识库 Metadata 与知识源定时更新。第三Tool 连接正在标准化Function Calling 仍然重要但 MCP 正逐渐成为连接企业数据与业务系统的重要标准接口2026 年 MCP 又继续强化了可扩展性、无状态部署和授权能力。第四Memory 开始成为独立服务Memory 不再等于 History而是拥有 Capture、Recall、Update、Forget 和 Scope。第五质量治理从 Answer 转向 Trace不只评价模型最后说了什么还需要评价它为什么检索这些知识、为什么调用这个 Tool以及整个任务是否正确完成。这些变化共同说明企业知识助手正在从“知识库前面的聊天界面”演变成企业 Agent 的统一知识与任务入口。十七、不要一开始就把所有能力全部打开即使拥有这些技术也不意味着第一个版本就应该同时实现Agentic RAG、GraphRAG、Memory、Multi-Agent、MCP、Workflow、几十个 Tool。更加合理的演进路径是第一阶段可靠知识问答重点完成Permission-aware RAG Citation Trace第二阶段加入实时业务能力增加Tool Calling Business API Human Approval第三阶段提升连续性增加Session Memory State第四阶段处理复杂知识任务增加Agentic RAG 多轮检索 数据计算第五阶段平台化治理再建设MCP Gateway Eval Cost Audit Tool Governance这仍然符合本系列一直强调的原则不要为了使用 Agent 而过度设计。先让系统可靠解决真实问题再逐步增加自主性。十八、小结到这一篇我们终于把前面介绍的能力真正组合在一起。一个完整的企业知识助手已经不再是Knowledge BaseLLM而更接近Enterprise Knowledge Agent Knowledge Context Memory Tool State Permission Evaluation。其中RAG提供企业知识Agentic RAG解决复杂知识检索Tool / MCP连接真实业务系统Memory提供跨任务连续性State保存任务执行状态Structured Output让结果进入程序Permission限定可以看到和操作什么Citation让答案有据可查Trace / Eval让系统能够持续改进。这也是为什么真正的企业知识助手不能只关注“回答是否像人”。更加重要的是答案是否有证据、数据是否有权限、工具是否调用正确、操作是否可审计以及整个任务是否真正完成。如果把第 614 篇连起来看会得到一条非常清晰的技术路线Context → Tool → Structured Output → RAG → Agent Loop → Framework → State → Memory → Enterprise Knowledge Agent。到这里第三部分“第一个 Agent 应用”也基本完成了从基础组件到完整应用的闭环。上一篇回顾【第三部分第一个 Agent 应用】13. 为 Agent 增加记忆能力不是记住一切而是在需要时想起正确的信息-CSDN博客下一篇将进入第四部分Agentic智能体设计模式为什么 Agent 也需要设计模式因为当一个 Agent 已经能够检索知识、调用工具、维护状态并完成真实任务以后接下来的问题就不再是能不能做出来而是面对越来越复杂的任务应该怎样组织 Agent 的推理、路由、并行、反思、规划和协作这也将从“Agent 应用开发”正式进入“Agentic 智能体设计模式”。