OpenFDE：把客户访谈、业务记忆和 Agent 任务连成一条证据链
FDE 现场有三个经常断开的环节：知识在会议和聊天里，任务在人的脑子里，验收靠“看起来不错”。OpenFDE 试图把它们放进一个本地优先的工作区。
OpenFDE 的基本闭环是：
资料导入
→ 结构化业务记忆
→ 可追溯任务
→ Agent 执行
→ 结果回写
→ 评测和验收
为什么普通知识库不够
企业 AI 项目中的知识不是一堆可以任意拼接的文档。真正有用的信息包括：
- 某个部门想完成什么目标；
- 当前流程有哪些步骤；
- 哪些数据源被谁信任；
- 哪些约束不能违反；
- 哪个决策为什么这样做；
- 哪个痛点已经被验证；
- 哪项任务由谁负责验收。
如果只把材料塞进向量库，Agent 可能找到相似文字，却不知道它代表什么业务对象、是否已经过期、与哪条决策相关。
来源引用是写入条件
OpenFDE 强调 provenance：没有来源 URI 的内容不能直接进入正式事实记录。事实被召回时，还要能够展开到原始引用。
这对企业 Agent 很重要。回答“客户为什么拒绝这个方案”时，系统应该能回到访谈中的具体片段，而不是只给出一个无法追溯的摘要。
来源可以是：
- 访谈记录；
- 会议纪要；
- 客户文件；
- 系统页面；
- 研究结果；
- Agent 执行过程中的发现。
引用机制不能保证事实一定正确，但至少让团队知道事实从哪里来、何时记录、是否需要复核。
业务本体：让记忆围绕工作组织
OpenFDE 使用 FDE 领域本体组织信息，例如目标、工作流、决策、约束、数据源和痛点。
这比单纯的文档标题更适合交付现场，因为管理层关心的是“哪个业务目标受什么约束”，Agent 关心的是“执行这个任务需要哪些上下文”。
可以把一个客户事实表示成：
业务目标：减少发票异常处理时间
工作流：发票审核
痛点：异常规则依赖资深员工经验
数据源：ERP、供应商邮件、历史审核记录
约束：高金额付款必须人工批准
验收人：财务运营负责人
来源：访谈记录和审核样本
从记忆到任务
OpenFDE 不只负责“查资料”，还把业务记忆转成可派发任务。一个任务应该带有：
- 目标；
- 成功标准；
- 来源；
- 相关约束；
- 责任人或 Agent；
- 当前状态；
- 验收方式。
Agent 执行前，context 命令会把约束和相关事实组装成上下文包。这样，Agent 获得的不是整个客户资料库，而是与当前任务相关、带来源的最小信息集合。
Agent 执行必须回写
如果 Agent 只读不写，系统仍然会回到“经验存在会话里”的状态。OpenFDE 的闭环要求 Agent 将执行中发现的新事实、结果和问题写回账本。
memory → task → context → execute → finding → memory
回写内容应区分：
- 客户原始事实；
- Agent 的观察；
- 尚未验证的推断；
- 已经被人工接受的结论。
不能把 Agent 的猜测自动升级为客户事实。
评测比主观感觉更重要
OpenFDE 把任务标准和评测结果放进同一条审计链。企业项目至少需要准备：
- 代表性输入；
- 可接受输出；
- 禁止出现的错误；
- 人工复核规则；
- 通过、退回和重新处理的状态。
例如，一个资料问答任务的验收可以要求：
20 条脱敏真实问题中：
- 18 条引用正确版本资料；
- 无来源问题必须明确拒答；
- 涉及付款动作时必须转人工；
- 每条结果保留可追溯引用。
这比“回答看起来挺准”更容易讨论，也更容易在模型、提示词或资料变更后回归测试。
本地优先的边界
本地优先适合客户不希望把完整工作记忆放到外部 SaaS 的场景，但仍需单独处理：
- 本地目录的文件权限；
- 备份和设备丢失；
- 客户资料脱敏；
- 外部模型调用时传出的内容；
- 多客户项目隔离；
- 分享报告时的访问范围。
“数据保存在本地”不代表所有处理都在本地，也不等于自动满足客户的合规要求。尤其是抽取和生成阶段，必须明确哪些内容会发送给模型服务商。
适合的使用场景
- 访谈资料很多，但交付团队需要持续引用；
- 客户项目需要把任务派发给多个 Agent；
- 交付结果必须保留来源和审计轨迹；
- 需要向客户管理层展示实时进度；
- 需要把一次交付中的经验沉淀到后续任务。
总结
OpenFDE 的重点不是把所有资料变成“更大的知识库”，而是让资料变成有来源的业务记忆，再让记忆支撑可追踪任务和可验收执行。
它更适合作为 FDE 工作台来理解，而不是一个脱离交付流程的聊天应用。项目命令、依赖和功能会持续变化，使用前请查看 OpenFDE 当前 README。本文是结构化解读，不代表 GPT88 对该项目的官方背书。