诊断agent的一些思考

 零、意图识别

上线后发现用户输入比想象中的宽泛、口语化很多。由于我们有多个subagent去诊断不同类型的问题，如果这一步路由到错误的subagent，会让我们的agent成功率下降很多。 //todo 意图识别怎么做？LLM去识别还是有什么机制策略？

一、记忆部分

首先我面临的问题问题是记忆相关的问题。怎么设计记忆部分？分几层？怎么存？怎么取？怎么删？还有一个问题，agent什么时候做（存/取/删）这些操作。这几个问题决定了agent的准确性、成本、响应速度。 

短期记忆

当前回话内的记忆。如：

当前执行到哪一步了；

agent的state状态；

近几轮的聊天记录；

工具调用记录，结果可以存也可以不存到短期记忆中。

长期记忆

系统知识：

1、首先要保存系统知识，我拿A业务举个例子，A业务从请求、召回、精排、返回、到曝光等完整的业务流程。

2、主要字段的含义，这里可以认为是库表schema说明，以及在代码里相应的映射。

3、具体的产品线、业务类型等特有的逻辑需要单独说明清楚。

诊断方法：

1、诊断流程，特别是SOP的内容，需要在写清楚。

案例记录：

• 成功案例：要把成功的案例记录沉淀下来。不要只记录原因和结果，比如“A计划五曝光，根因：预算不足。”要记录背景、排查步骤、关键证据、排除过的假设。
• 失败案例：怎么处理？不要直接过滤掉失败案例，最好把失败案例的具体失败的原因、失败在哪个步骤记录下来。

长期记忆怎么存？怎么取？

• 在我的agent场景，什么时候才会去读长期记忆？事实类的、基线类的内容，比如该产线的CTR、一些大盘数据等。
• case沉淀中的现象对应的诊断路径、清单要尽早读。历史诊断的结论不要一上来读，否则LLM就不诊断了。。。
• 假设、证据核验、结论判定、已经证伪的清单等信息？

上下文

1、哪些东西放上下文中

2、上下文爆了怎么办？

上下文爆炸后必然会压缩，问题不是压缩，而是压缩关键信息丢失，语义漂移，从而产生幻觉怎么办。

压缩必然导致信息减少，什么样的信息是能减少的，什么样的信息是不能减少的，要区分这两类信息才能正确处理上下文压缩。

上下文中哪些不能被压缩？我称之为冻结区，这些信息是永不被压缩的。

冻结区包含任务定义，硬约束、事实账本、执行了哪些工具，这些都不能被压缩。

可压缩区，摘要区：这部分包含探索轨迹、工具原始返回、失败尝试等信息。这些信息，如工具原始信息本身可以记录在外部黑板上的，等到要用的时候查明细。

上下文优化手段

1、不要等上下文爆了才压缩。而是要尽量让上下文膨胀太快。

最典型的就是工具调用后的数据不要原封不动塞进上下文，tool做结构化输出，然后放入上下文。tool的原始返回可以让入其他外部存储，我们称之为外部黑板。

2、上下文隔离优于上下文压缩

把长流程拆成多个步骤，其中不少步骤是可以用短对话形式的，简单记录已经调用的工具、格式化输出，每个节点只要有干净的上下文就能完成该节点的本职工作了。

3、用结构化文本摘要替代自由摘要。比如不要写“我们检查了出价、受众和素材，发现素材更新频率较低……”这类摘要，而是维护一个 schema 绑定的状态机 {已排除: [...], 待验证: [...], 已确认: {字段: 值, 置信度}}。自由摘要可以随机漂移，这是我们无法掌控的。

4、压缩对账

压缩前用后必须对账，如何对账？结构化对账。约定一个schema，比如：（实体、指标、数值、单位、方向、否定条件、认知等级），压缩后再做一次schema抽取，两个schema逐个字段做diff对比。比较语义、精度是否丢失。否则就拒绝这次压缩，退回到“删低价值片段”的策略。

 

3、压缩后关键细节丢失怎么办？

summary压缩后会导致信息减少，导致关键信息丢失或者语义漂移。解决此类问题，我们采取的是langchain的with_structured_output()让LLM结构化输出。然后采取“关键事实结构化+候选摘要”，结构化事实里存关键证据ID，便于LLM需要的时候去查找、核实。

 

 

二、知识库如何搭建

一个好用的知识库，可以让agent的准确性大大提升。

怎么做

如何优化

知识冲突了怎么办？

如何评测知识库的好坏 

 

三、工具调用

1、工具异常处理：这个要格外注意。是超时、还是返回0值、还是其他报错要分开处理。不然会误导agent后续判断。

2、失败重试：有限次充实，并把失败明细在上下文写清楚。

3、失败后有无降级方案？

有些工具失败后可以有降级方案，有些则没有。如果SLS查失败了可以去ODPS里查数据。即使没有降级方案，也需要评估是否真正阻塞整个agent的任务继续。但该步骤需要写清楚。“查询xxx数据失败。原因：工具调用超时”。

4、工具有时候返回的数据非常长怎么办

要格式化输出

 

四、开发、使用过程中遇到哪些问题

1、执行太慢

原因一、之前采用的方案是skill里描述执行步骤，但是发现有些步骤并没有并行。改成了在agent里通过节点和边的方式去控制确定性的workflow执行。

2、上线后输入超过预期边界

3、运行时允许用户补充信息

这一点很重要，有时还没有得到问题的全部信息，用户就反馈问题了，之后得到的补充信息往往很重要，能帮agent缩小范围。

4、有没有出现过幻觉

agent产生幻觉不是一种原因，可能是多个原因造成的：

• 工具幻觉：工具参数描述不清晰，或者工具集太大，边界、功能不清晰，导致LLM去猜参数、猜工具之间的差异。
• 记忆幻觉：这个很常见，比如知识库召回不准确、压缩后关键信息丢失、语义漂移、目标漂移。
• 完成幻觉：LLM告诉你她完成了一个写操作，其实她写失败了。这种幻觉需要采取read-after-write，也就是强制回读。要他把刚才写的数据读出来返回。

怎么解决/优化

• 工具参数描述清晰,schema强校验；工具职责、使用场景描述清晰。
• 写后读：每次做了啥完成了啥，要写完后再读一次。比如你说你改了某条数据、某个文件，把它读出来这个动作本身就是校验。
• 证据绑定：每个关键结论都要对应证据，如SQL的结果片段、命令行输出等。做到结论都有依据。
• 给不知道留出口。并不是什么事情agent都能搞定的。该退出就退出、转人工。

5、结论冲突怎么办

6、长任务怎么恢复

五、如何评测一个agent的好坏

 

六、如何停止

诊断agent跑了很久没找到用户问的问题的原因该怎么处理呢？

设置loop次数我觉得不是很可取，不同的问题loop次数不一样。设置预算上限也只是兜底方案，并不是技术方案。

我在设计的时候采取的是判断标准是收敛判断：每次活动都需要更新假设清单，这份假设清单每次都要有更新，这就是进展，而不是单纯的LLM空跑。这份台账是解决“白跑”的关键，因为它是机械可判定的：每轮结束时，代码只需比较清单前后的状态，就能知道这一轮有没有进展。既不靠模型自省，也不靠它说“我还在继续分析”。