AI 越用越聪明？EDOAPP 智能体的自学习机制

开头：答错一次，下一次真的会改吗？

以一个示例场景看，用户第一次问“哪些合同还没提完货”，智能体把“合同已完成”当成了“提货已完成”，给出的结果看起来有道理，实际却答偏了。

第二天再问同样的问题，如果系统没有留下记录，没有人分析原因，也没有补充业务规则，那么它很可能还会沿着原来的思路再答一次。

这件事说明了一个容易被忽略的事实：智能体不会因为被使用了几次，就自动变得更聪明。

模型可以生成答案，RAG 可以把业务知识检索出来，但“这次为什么答错、下次应该怎么改”，需要一套持续优化机制来完成。

这也是很多企业在使用 AI 时会遇到的分水岭：

• 有的系统每次都像第一次见到问题；
• 有的系统能够把错误留下来，把正确做法沉淀下来，逐步减少重复犯错。

后者并不是因为模型在后台偷偷完成了训练，而是因为企业建立了一个清晰的闭环：

用户提问
  → 智能体回答
  → 记录反馈与异常
  → 人工判断问题原因
  → 更新知识、案例或 Prompt
  → 下一次类似问题回答更准确

这就是 EDOAPP 问数智能体所说的“自学习”。

同一个问题，前后会有什么不同

假设用户第一次问：

哪些合同还没提完货？

第一次，系统只检索到合同状态，回答“已执行但未完成”的合同。这个答案听起来合理，却没有核对实际提货数量。

经过人工复盘、补充业务规则和验证案例后，下一次相似问题会继续检查合同数量、提货数量和关联明细，并把“还差多少”作为结果的一部分。

用户不需要知道 YAML、向量索引或 Prompt。用户真正感受到的变化只有一个：系统不再只会查字段，而是开始理解问题背后的业务判断。

一、先把“自学习”说清楚

自学习不等于重新训练大模型

一提到 AI 学习，很多人首先想到的是重新训练模型。但对企业问数场景来说，日常优化通常不是这样做的。

企业业务系统里的变化，很多是局部的：

• 新增了一个业务字段；
• 某个状态值的含义发生了变化；
• “提货”“出库”“发货”被不同部门用来指代同一类业务；
• 查询某类单据时，需要增加一个默认过滤条件；
• 两张业务表之间新增了一条关联路径。

这些变化不一定值得重新训练一个大模型。更直接的做法，是把变化补充到业务知识、成功案例和查询规则中。

重新训练模型成本高、周期长，也需要准备和审核训练数据。更重要的是，模型训练并不能替代企业对业务规则的确认。一个字段到底代表什么，最终仍然要由懂业务的人说清楚。

对企业来说，自学习是应用层的持续优化

在前两篇文章中，我们分别讨论了两个问题：

• AGENT-01：如何用自然语言查询业务数据；
• AGENT-02：如何用 RAG 让 AI 先理解企业自己的业务知识。

第三篇继续往前走一步：当答案不准确时，系统如何把这次经历变成下一次可用的改进？

在这套 V1 方案里，最实际的优化路径不是修改大模型，而是维护三类内容：

1. RAG 业务知识库
2. 已验证的成功问答案例
3. 查询 Prompt 和规则约束

所以，“智能体越用越聪明”更准确的说法是：它在反馈闭环中被持续喂强。

二、一次错误回答，系统应该留下什么

还是以“哪些合同还没提完货”为例。这不是一个简单的合同状态查询。

这里有一个很容易混淆的业务边界：

合同状态完成 ≠ 货物全部提完

合同状态回答：合同流程走到哪一步？
提货完成度回答：约定数量、已提数量、未提数量分别是多少？

合同状态是流程状态，提货数量是执行状态。两者属于不同维度。如果只查其中一个维度，技术上可能查到了数据，业务上却仍然没有回答问题。

系统至少需要理解几层关系：

• 合同本身是否已经执行；
• 合同约定的可提货数量是多少；
• 已经关联的提货单有多少；
• 实际提货数量和合同数量之间还差多少；
• 用户说的“没提完”，究竟是指合同状态未完成，还是数量还没有全部完成。

如果智能体只检索到了合同状态，却没有检索到合同和提货单之间的数量关系，就可能生成一个看似合理、但没有回答真正问题的查询。

还要注意，很多“AI 答错”其实不是模型问题，而是基础数据本身不完整：合同数量没有维护、单据关联缺失、状态含义在不同部门之间不一致，或者历史数据没有补齐。智能体可以更快地暴露这些问题，但不能凭空补出不存在的数据。

这类问题不能只记录“回答错了”四个字。为了找到原因，系统需要记录完整过程：

• 用户原始问题是什么；
• 系统识别出的意图是什么；
• RAG 检索到了哪些知识文档；
• 智能体生成了什么查询参数；
• 调用了哪些模型、字段和关联路径；
• 查询执行是否报错、返回空结果或结果异常；
• 异常发生在哪个阶段。

这些信息合起来，才足够支持一次有效复盘。

错误通常来自四个地方

这一步很重要。因为不同原因，不能用同一种方式修复。

如果是知识缺失，盲目修改 Prompt 只会让提示词越来越长；如果是后端权限问题，继续给模型增加案例也解决不了。先分清原因，再选择修复位置，系统才不会越改越乱。

谁负责确认和修复

“人工复盘”不能只写在方案里，还要有明确的责任分工：

业务人员确认“这个答案对不对”，技术人员负责“系统如何稳定地得到这个答案”。两者不能互相替代。

三、三层优化：知识、案例和 Prompt

这三层不是越多越好，而是要把问题放回正确的位置：知识解决“它不知道”，案例解决“它不会这样组合”，Prompt 解决“它总是漏掉某个约束”。

第一层：补充业务知识，解决“它不知道”

这是成本最低、通常也最直接的一层。

假设系统没有记录“提货完成”的业务判断规则，智能体不知道哪些状态代表已经收货或确认，也不知道合同数量和实际提货量应该如何比较。

这时应该补充业务知识文档，例如说明：

• 哪些状态属于有效业务记录；
• 哪些状态表示已经完成提货；
• 合同和提货单通过什么字段关联；
• 如何比较应提数量和实际提货数量；
• 用户说“提完货”“已经出完”“还有多少没提”时，分别对应什么业务含义。

处理过程可以是：

发现知识缺失
  → 更新对应 YAML 文档
  → 更新向量索引
  → 用原问题和相似问题回归测试
  → 后续查询检索到新的业务规则

这类改进不需要改业务代码，也不需要重新训练模型。但它必须经过业务人员确认，因为知识文档本身就是企业规则的一种表达。

知识库通常适合保存相对稳定、可复用的内容：

• 模型和字段定义；
• 状态值及其业务含义；
• 表与表之间的关联路径；
• 全局过滤规则；
• 部门常用的业务术语和同义词。

第二层：沉淀成功案例，解决“它不会这样做”

有些问题不是知识缺失，而是知识已经存在，智能体仍然不容易把它们组合起来。

例如，知识库里分别写了合同、提货单和数量字段，但“哪些合同还没提完货”需要把这些知识串起来。一个经过人工验证的成功问答案例，就可以帮助模型理解这种问题通常怎样组织查询。

一个案例至少应当包含：

• 用户问题；
• 正确的查询参数；
• 使用了哪些模型和字段；
• 过滤条件是什么；
• 关联路径是什么；
• 为什么这样查询；
• 是否经过人工确认。

案例库的作用不是让模型机械复制旧答案，而是提供一个经过验证的参考模式。

它尤其适合处理这些情况：

• 同一个业务问题有很多种自然语言问法；
• 某类复杂关联已经有过正确处理方式；
• 用户经常用口语描述，而系统字段使用专业名称；
• 某种查询需要同时满足多个业务约束。

在实际流程中，可以把用户反馈纳入案例积累：

智能体回答
  → 人工判断是否正确
  → 正确：保存为成功案例
  → 错误：人工修正后保存正确版本
  → 下次相似问题：检索相近案例作为参考

这里有一个前提：错误答案不能自动成为案例。 只有经过确认的答案，才适合进入案例库。

同时，案例库也不能无限增长。重复、过时或和现行规则冲突的案例，需要定期合并、废弃或重新审核。否则知识越积越多，检索越复杂，系统反而更难维护。

第三层：优化 Prompt，解决“它总是漏某个约束”

还有一类问题，业务知识和案例都已经存在，但模型仍然反复漏掉某个要求。

例如：

• 查询提货单时经常漏加状态过滤；
• domain 格式反复不符合接口要求；
• 已经明确目标模型，却选错了关联字段；
• 生成查询参数前没有先确认字段是否存在。

这时可以对 generate_query 节点的 Prompt 做针对性调整，并记录版本变化：

Prompt V1.0：初始查询规则
Prompt V1.1：增加 domain 格式约束
Prompt V1.2：增加全局状态过滤提醒
Prompt V1.3：增加字段存在性检查

Prompt 优化也不能靠感觉。每次修改后，都应该使用一组典型问题进行回归测试，确认它解决了原来的问题，同时没有破坏已有查询。

Prompt 不是垃圾桶。遇到每一个异常就加一句提醒，最后很容易变成一份互相冲突、没人敢维护的长文档。

四、人工复盘，是自学习闭环的控制点

如果系统把每一个错误答案都自动写回知识库，所谓“自学习”很可能会变成“自动放大错误”。

企业数据尤其不能这样处理。财务、库存、合同和权限都存在业务边界，相似的自然语言不一定代表相同的业务意图。

所以，人工复盘不是系统不够智能，而是企业应用必须保留的控制点。

如果没有这道控制点，系统可能把一次偶然的错误当成“经验”，再通过案例和 Prompt 反复放大。对财务、库存、合同和权限相关问题来说，这种自动放大比一次回答错误更危险。

复盘时要回答四个问题

1. 用户真正想查的是什么？
2. 系统检索到了哪些知识？
3. 查询参数在哪一步偏离了业务意图？
4. 这个问题应该修知识、修案例、修 Prompt，还是修后端？

不同阶段的复盘频率

一条异常记录最终应该有明确去向：

degraded=True
  ├─ 知识缺失 → 补充 YAML 知识库
  ├─ 理解偏差 → 增加 Few-shot 案例
  ├─ Prompt 问题 → 更新 Prompt 版本
  └─ 后端问题 → 修复 API、权限或数据

这样，复盘就不再是“看一眼日志”，而是一次有结果的维护动作。

不同异常，要按业务影响排序

不是所有错误都同样重要。可以先按影响范围排序：

这样做的目的不是让系统看起来更完善，而是先处理那些可能改变经营判断的错误。

五、一个完整的优化示例

下面用“哪些合同还没提完货”演示一遍完整流程。这个例子用于说明产品机制，不代表某个客户的真实数据或上线结果。

第一步：用户提问

用户问：

哪些合同还没提完货？

第二步：智能体首次回答

智能体检索到了合同状态相关知识，于是只查询了“已执行但未完成”的合同状态，没有继续检查下游提货数量。

回答听起来合理，但没有真正回答“数量是否提完”。

第三步：系统记录异常

日志中保存：

• 用户问题；
• 检索到的合同文档和提货文档；
• 生成的合同状态过滤条件；
• 没有生成合同数量与实际提货量的比较逻辑；
• 异常阶段为查询理解或参数生成阶段。

第四步：人工判断根因

复盘发现，问题不是接口报错，也不是字段不存在，而是知识文档没有明确描述“合同提货完成度”的判断方式。

第五步：补充知识和案例

在合同相关知识中补充：

• 合同已执行不等于货物已经全部提完；
• 需要读取关联提货明细；
• 将合同可提数量与实际提货量进行比较；
• 实际提货量小于应提数量时，才属于“尚未提完”。

同时保存一条人工确认过的正确问答案例。

第六步：回归验证

重新测试原问题，并增加相近问法：

• 哪些合同还有余货？
• 哪些订单没有全部出库？
• 还有哪些合同没完成提货？

验证的重点不是“这一次答对了”就结束，而是确认相似表达也能检索到同一类业务知识。

这才是一次完整的优化：错误被记录，原因被分类，修复进入正确的位置，修复结果又经过了验证。

六、从“查得更准”到“做出更好的决定”

查询准确不是终点。对管理者和财务负责人来说，还要继续追问三层：

这是什么？
  → 哪些合同还没提完货？

这意味着什么？
  → 是客户需求变化、供应链执行滞后，还是合同和提货数据没有对齐？

所以怎么办？
  → 哪些合同需要催办、调整交付计划，或者进一步评估库存和现金流风险？

同一个问题，可以对应三个层次的价值：

如果智能体只是把数据查出来，它仍然只是一个更方便的报表工具。真正有价值的系统，要让查询结果能够继续进入业务分析和管理动作。

对财务来说，“哪些合同还没提完货”还可能牵涉：

• 未完成合同对应多少未实现收入；
• 相关库存或采购资金被占用了多少；
• 哪些客户已经超过约定交付周期；
• 哪些异常可能进一步影响应收账款和现金流。

这些问题不一定都由智能体直接回答，但系统至少要让用户能够沿着结果继续追问，而不是在一张报表上结束。

七、企业真正需要关注的四件事

企业不必先追问“AI 会不会自己学习”。更实际的问题是：

1. 错误有没有被记录

没有日志，就没有复盘；没有复盘，就不知道系统到底哪里需要改。

2. 错误能不能定位

只知道“答案不对”还不够。要能区分是知识、意图、Prompt、接口还是权限问题。

3. 修复有没有经过审核

进入知识库和案例库的内容，应该有明确来源和确认过程，而不是让错误自动循环。

4. 修复后有没有回归验证

改完规则后，要用原问题、相似问题和容易混淆的问题一起测试，确认改进没有带来新的问题。

这四件事做得越扎实，智能体就越能适应企业自己的业务，而不是只会回答通用问题。

写在最后

智能体不会因为多回答了几次问题，就自动变得更聪明。

但如果企业把每次反馈记录下来，把错误原因分清楚，再把修复结果沉淀回知识库、案例库和 Prompt，它就能一次比一次更贴近自己的业务。

这套机制不神秘，也不依赖“模型突然开窍”：

• 知识缺了，就补充知识；
• 问法复杂，就沉淀案例；
• 规则容易漏，就优化 Prompt；
• 后端有问题，就修复接口和权限；
• 每次改完，都用真实问题回归验证。

所以，企业智能体的“自学习”，不是完全放手让 AI 自己成长，而是让系统拥有一条反馈、记录、复盘、优化、验证的可持续路径。

当这条路径真正跑起来，智能体才会从“能回答问题”，逐步变成“越来越懂这家企业的问题”，再把更可靠的数据转化为业务和财务动作。

加入智能财务交流群

如果你正在关注智能财务、财务数字化、问数智能体或企业信息化实践，欢迎扫码加入“智能财务交流群”，和同行一起交流真实问题与落地经验。

二维码有有效期，如无法扫码入群，请重新获取最新二维码。

---

我是唐朝，做了23年企业信息化，财小智 / EDOAPP 创始人。如果你正在建设企业智能体，或者遇到过“AI 明明接入了数据，却总是答不准”的问题，欢迎交流。