把客户问题、协作过程和确认结论连起来，让知识在下一次使用中继续修订。
在外贸公司里，一次客户沟通，往往会带出一串内部沟通。销售问工程，工程查资料、问生产，采购再向供应商确认。几轮讨论之后，客户拿到了答复，公司是否也留下了一份下次能用的知识？
建设企业知识库，可以先从这些真实发生的问题开始：保留解决过程，提炼有依据、有适用条件的结论，再让它们回到下一次业务协作中。
从销售答不上来的问题开始
客户问了一个产品问题，销售没有把握，于是去问工程。工程需要确认某个细节，又去查资料、问生产，或者联系供应商。销售终于拿到答案，回复客户，事情暂时告一段落。
过一段时间，另一位销售遇到相似的问题，可能又要从头问一遍。原来的聊天记录还在，只是大家不知道该搜哪个词，也不确定当时的答案现在是否适用。知识仍然依赖那几位经验丰富的同事。
每一次值得保留的问题解决过程，都可以成为知识库的起点。 客户提问的那一刻，知识就有了明确用途：为什么需要回答它，谁会再次用到它，都比较容易判断。整理的价值，也能在后续使用中检查。
工程师的追问本身就是知识
假设客户问：“这个材料能不能长期在 150°C 的环境下使用？”
工程可能不会马上回答能或不能，而是先追问：
- 具体是什么材料牌号？
- 连续使用，还是短时间接触？
- 是否承受载荷？接触什么介质？
- 预期使用多久？
这些追问决定了判断所需的条件。如果最后只保存一句“需要工程确认”，下一次销售依然不知道怎样收集信息。保留工程的判断过程，销售下次就可以先把关键条件问清楚，再带着完整信息寻求支持。
知识库因此既能帮助回答问题，也能帮助同事更准确地提出问题。
同时保留原始过程与可复用结论
一个完整的沉淀过程，可以沿着下面这条链路展开：
客户提出问题 → 补充上下文 → 协作解决 → 确认结论 → 提炼入库 → 下次复用 → 反馈修订。
这条链路需要留下两种相互关联的记录：
| 保留什么 | 包含哪些内容 | 下次怎样使用 |
|---|---|---|
| 原始问题解决过程 | 客户原话、产品和工况、同事讨论、查阅资料、最终答复与后续结果 | 回看当时的证据、背景和判断经过 |
| 提炼后的可复用知识 | 当前结论、适用条件、需要先确认的信息、仍未解决的部分 | 帮助销售快速找到重点，判断能否用于当前问题 |
任何人看到一条知识，都应该能追溯它来自哪次问题、哪份资料，以及谁确认了结论。
一条知识需要有依据、边界和负责人
企业内部讨论很容易省略背景。工程师知道正在讨论哪款产品，销售知道客户准备卖到哪个市场，供应商也知道报价对应的是哪批材料。但一段话被摘出来以后，这些共同背景就消失了。
某个型号可以做到，不代表整个产品系列都可以做到；某种工况下验证过，不代表换了使用环境仍然成立。供应商的一次口头建议，也不能直接变成公司的长期承诺。
因此，一条可复用知识至少应该讲清楚：
- 适用条件：对应什么产品、市场和使用环境？
- 结论与状态：已经确认什么？哪些部分还在等待测试或补充？
- 依据与负责人：来源在哪里，由谁确认？
- 重新检查的条件：材料、规格、工况或其他依据发生什么变化后，需要复核？
还要区分“销售已经回复客户”和“技术结论已经得到验证”。有时答复只是当前判断，有时仍在等待测试结果。沟通结束不能自动成为结论生效的依据。
AI 整理草稿，负责人确认结论
在这条流程里，AI 可以承担大量提取、查找、归并和整理工作。关键结论仍然需要有负责人。
从一次标记，生成一份待审核草稿
第一版可以提供一个很轻的入口：同事发现某段讨论值得留下，就选中相关消息，标记“沉淀这个问题”。
系统围绕这次问题关联沟通记录、文件和答复。AI 从中提取客户问题，汇总散落的条件，找出引用过的资料，标出说法冲突的地方，并搜索已有知识，判断本次是在补充旧问题，还是形成新的知识。
随后生成一份待确认草稿，说明问题是什么、建议保留什么结论、依据在哪里、适用范围是什么，以及哪些部分仍需补充。
销售问工程、工程问生产、采购问供应商，都是同一次问题解决过程中的不同环节。最终需要保留的，是这些协作共同形成的有效判断。
让确认结果决定能否复用
工程负责人确认技术内容，销售负责人确认客户表达，涉及交期、价格或合规的内容，由对应负责人确认。
审核时要同时检查来源、条件和文字。AI 把话写得顺畅，并不会增加原始信息的可靠性。待审核的草稿保留在待处理范围，正式查询使用当前已经确认、生效的知识。
先围绕明确授权、确有业务用途的材料整理，客户身份和敏感商务信息按访问范围处理。一个有用的知识条目，通常不需要让所有同事看到整段原始对话。
用 Agent 架构承接这条业务流程
业务上的问题、证据、确认和复用，需要在系统中有对应的位置。Agent 按当前任务读取相关知识，再调用工具完成处理；知识库负责持续维护这些任务所需的业务上下文。
先分清材料、知识、流程与工具
| 业务内容或能力 | 在架构中的职责 |
|---|---|
| 客户问题、沟通记录、测试报告、供应商资料 | 作为原始材料进入待处理区；处理后仍保留来源，供知识条目回溯 |
| 已确认的产品判断、适用条件与注意事项 | 作为正式知识维护，关联依据、确认人和当前有效状态 |
| 信息收集、工程确认、客户答复、反馈修订 | 形成工作流，明确每一步由谁处理、交付什么 |
| 引用要求、审核要求、客户表达与访问范围 | 形成规范，并由实际系统执行对应的权限和状态约束 |
| 目录、关键词、向量索引与重排 | 帮助定位知识；索引从正文派生，正文更新后重新构建 |
| 搜索、资料提取、消息关联等工具 | 由 Agent 按任务调用，返回处理结果，供后续判断和交付使用 |
销售提出一个问题时，Agent 先定位相关产品资料和既有知识，再核对当前工况与适用条件。条件不完整，就列出需要追问的信息；已有知识无法覆盖，就整理材料并提交负责人确认。
交互图：查看知识如何被调用和更新
下面这张图根据翔宇的 Agent 知识库视频整理，提供四个视图。可以按下面的顺序阅读：
- 总体架构：看知识正文、导航、检索和执行工具怎样配合。图中的八个领域是原作者的个人知识组织方式，企业可以按上表中的业务职责组织。
- 外部资料入库：沿着待处理、提炼、待审核、确认入库走一遍，理解原始材料怎样成为可引用的知识。
- 经验与记忆迭代：看任务产生的经验怎样被筛选、归位，再进入后续任务。
- 任务执行：用原视频的内容生产示例，理解 Agent 怎样按需补齐上下文、分阶段交付产物。
点击图中节点，可查看输入、处理方式、输出和对应的视频时间点。图较宽，也可以打开独立交互图查看完整布局。
小屏幕上可左右滑动图形，点击节点查看输入、处理方式和输出。 在独立页面查看完整交互图 ↗
企业采用这套组织方法时，需要把审核责任和资料权限落实到系统。图中的外部资料入库由用户确认，记忆迭代展示了原作者用 Gemini 自动筛选经验的机制；模型筛选候选之后，企业的技术和商务结论仍须由相应负责人确认。
目录也不能替代权限控制。销售能查到一条可用结论，并不意味着他应当看到完整客户对话或全部商务附件。索引、引用和检索结果都要沿用来源资料的访问约束。
图中保留了原视频的出处、回看链接与技术选型。本文未独立审计原作者源码，也未验证其中的参数与效果；上表是对企业业务场景的设计映射。
在下一次使用中修订同一条知识
销售查到答案后，可能发现少了一种工况；工程可能发现旧材料已经被替换；客户的实际使用结果，也可能与原先判断不同。这些反馈应该回到原来的知识条目，触发补充、修订或停用。
同一个问题不必每次重新创建一份 FAQ。已有条目能够覆盖，就更新它，并补上新的依据。历史案例保留当时的背景，当前答案指向最新生效的信息。
如果产品参数已经在正式规格资料中维护，知识库就引用那份资料。价格和交期等经常变化的信息，也应回到对应业务系统查询。把同一个事实复制到规格书、培训文档和销售问答里，会让后续更新越来越困难。
因此，需要明确谁维护事实、谁使用事实。销售问答可以改善表达、补充判断方法，但不应悄悄成为另一套产品参数表。
第一版先跑通一个产品线
先选一个产品线、一类反复出现的客户问题，再确定一位有能力确认结论的负责人。每遇到一次真实问题，就完整跑一遍收集、解决、确认、入库和复用的过程。
等这条流程稳定以后，再逐步增加聊天提取、相似问题归并、审核提醒和检索能力。自动化替换已经验证过的步骤，系统会更容易维护，团队也更容易形成使用习惯。
用复用效果检查是否值得继续
检验效果时，可以看三件事：
- 销售是否更容易找到当前可用、条件匹配的答案？
- 工程是否减少了重复解释，同时保留了必要的确认？
- 答案被再次使用时，是否仍然准确，反馈能否回到原来的知识条目？
文档数量和自动采集的消息数量，只能说明整理了多少材料，不能替代这些结果。
企业里有价值的知识，经常就产生在日常协作中：一个客户追问了什么，一位工程师先排查了什么，一位同事提醒过哪个条件，一次测试推翻了什么判断。
把这些过程留下，提炼出依据和边界，并让它们在下一次工作中得到使用和修正，公司积累的就不只是答案，还有解决问题的能力。