在 FDE 的实战里，Agent 构建和知识库搭建不是两个独立任务，而是一枚硬币的两面。Agent 是执行单元，知识库是决策依据。没有知识库的 Agent 只会机械调用 API，没有 Agent 的知识库只是一堆文档。真正的工程难点，在于把两者都做“实”，让它们在客户真实环境里稳定咬合，而不是在演示环境里互相表演。
Agent 构建：从业务动作倒推边界
很多团队一上来就急着搭框架、选模型，结果 Agent 能力泛化，什么都能聊，什么都做不深。FDE 的路径必须反过来：先看客户业务里哪个动作可以被自动化，再围绕这个动作定义 Agent 的边界。比如客户要“自动识别合同风险”，Agent 就只做一件事：输入合同文本，输出风险标签和依据。边界越窄，可控性越强。边界宽的 Agent，听起来强大，到了现场全是故障源。
定义 Agent 时，三个要素必须写死。输入输出契约：字段名、类型、缺失值处理，要和客户系统对齐。权限边界：Agent 只能读什么、不能写什么，最小权限原则从第一天生效。失败模式：输入异常、依赖超时、模型输出不符合规则时，分别走重试、降级还是人工介入。没有失败模式的 Agent，上线就是裸奔。
可观测性也得从 Agent 诞生第一天就内置。日志、指标、trace 三件套不能省。现场排障最怕的不是报错，而是“不知道它为什么这么干”。Agent 的每次决策路径都要能回溯，否则客户问起，你只能现场编。
知识库搭建：真实数据面前，没有捷径
知识库的核心不是向量数据库多先进，而是数据质量。客户的数据字典缺失、文档版本混乱、Excel 和 PDF 混在一起，这些才是常态。FDE 要做的第一件事，是建立一条数据接入与清洗的 pipeline，把不同格式、不同来源的数据统一成结构化片段。这一步琐碎、耗时，但绕不开。很多项目失败在“知识库看起来有内容，检索出来全是垃圾”。
数据清洗完后，索引策略要结合实际查询模式。向量检索不是万能的，关键词匹配在某些场景更稳定。混合检索加 rerank 是常见做法，但最终效果取决于切分策略。切分太细，语义碎片化；切分太粗，检索噪音大。没有放之四海而皆准的粒度，必须在客户真实查询上做小样本评估。
权限治理是知识库搭建里最容易被忽视的一环。不同角色的客户员工，能检索到的内容必须隔离。知识库不能是一个大池子，要按组织、按密级做切片。金融政务场景里，这点是硬约束，不是加分项。
协同机制：让 Agent 用得着知识库
Agent 调用知识库不能是黑盒。每次检索返回的结果，要带上来源片段和置信度。这样业务人员看到 Agent 的决策时，知道它依据了什么，也知道该不该信。置信度低的结果，可以触发人工复核，而不是让 Agent 硬着头皮给答案。
更重要的是建立反馈闭环。用户在业务系统里对 Agent 输出的每一次纠正、每一次忽略，都应该回流到知识库的更新策略里。知识库不是建完就封存的，它得跟着业务走。学术上讲，这叫“人在回路的持续对齐”，实操上讲，就是别让知识库变成一潭死水。
验证：只看真实场景，不看演示效果
最终验证 Agent 和知识库的协同，只有一个标准：在 Thin Production Slice 里跑通。选一个最小的真实业务场景，让 Agent 用真实数据、真实权限完成一次完整动作。评估指标不要只看准确率，要加上业务采纳率——客户员工到底用不用这个 Agent？如果用起来，说明它解决了真问题；如果绕开不用，指标再漂亮也是失败。
说到底，Agent 构建和知识库搭建的核心工程价值，不在于用了多新的模型或框架，而在于把执行和知识都纳入了可治理、可解释、可迭代的工程体系。这个体系在客户环境里立住了，交付才算真正开始。
