基于deepseek的工作流搭建感受

水力发电站
1

本以为LLM发展至今，已经可以充分处理一些科研上的review工作，但是构建了一个包含RAG的工作流是之后确确实实感觉到LLM存在一些较大的问题，我把这些问题写下来供大家参考，如果有好的解决策略大家可以畅所欲言：

  1. 上下文过短：虽说ds现在已经可以满足128k的上下文长度，但是当涉及RAG依旧multi-agent的时候，随便一个对话就能有4k左右的字数，多谈几轮就超过上下文长度了，所以不得不将一部分数据存储起来，当agent需要的时候在让其调用工具来查看。

  2. 话题漂移：这是上下文过短的问题引申出的问题：因为上下文有限，所以很有可能说了后面忘了前面，就会出现：我一开始让他写一个关于a的综述，后面写着写着就变成了b的综述。

  3. 工具调用问题：我并不清楚这是不是ds的专属问题，调用的时候有概率会传错参数或者不传参数：就算我已经写清了每个函数的说明，不过llama的工作流倒是自带纠错机制，所以也就只是需要多生成几次。

  4. 陷入死循环：工作流中常常需要一个reviewer用于评价之前的工作并给出建议，但是常常由于reviewer要求过高而陷入死循环，所以需要限制最大的迭代次数或者让reviewer降低要求。甚至删掉reviewer：实测就算让reviewer提出建议，似乎由于文本过长，一开始提出的要求也会被“writer”忘掉，然后再写一次相同的内容 :sweat_smile: ，reviewer接收之后又会美美给writer提出相同的要求。

2

感觉可以参考一下claude code的实现？这个工作流已经和agent很像了，agent框架的实现对整体效果的影响还是挺大的，像是数据检索，上下文压缩等等。
（如果是要实际使用的话，建议直接ds接claude code，这个体验包好的 :nerd_face: :index_pointing_up:）

3

应该全是ds自己模型的问题（而不是当今模型训练技术不足）；

  1. 上下文：当你见到opus等1M上下文后者几k的就是小意思了；而且当需要处理图片时（尤其是需要模型直接读入理解时）200k模型会直接爆掉
  2. 话题漂移：这个其实大家多少有点，但是codex gpt5.3codex之后基本没这问题，能很好的记住你的各种要求，很多次折叠以后还能记住第一次要求(不过有时这也不完全是件好事…这方面模型能力确实不算顶尖)
  3. 工具调用是需要专门训练的，这点用过几次cc/cx的应该就能有所体会… 现代专门训过的模型的工具调用完全可以不是问题
  4. 死循环的问题应该就是模型训得不好，今天我在gemini3也遇到了loop问题，gemini程序甚至专门会检测这个，并问你要不要结束循环；而cc/cx我从没见过这种事
4

这个问题我最近也挺有共鸣，感觉很多“工作流问题”本质上其实是 状态管理问题，不全是模型智力问题。

我会比较推荐把 agent 系统拆成 4 层来看：

  1. 工作记忆（working context）
    只放当前这一步真正需要的内容，不要把历史对话原样一股脑塞回去。能摘要就摘要，能结构化就结构化。

  2. 项目状态（project state）
    单独维护一个持续更新的 state / brief，比如：任务目标、当前结论、待验证问题、已排除路线。后续轮次优先读这个，而不是读几十轮聊天记录。

  3. 外部知识（RAG）
    RAG 不要“召回越多越好”，而是要做预算控制。一次只喂最相关的几段，不然模型会把检索结果也当噪声。

  4. 控制器（controller）
    负责决定：什么时候检索、什么时候总结、什么时候停止迭代。很多 loop 其实不是 writer/reviewer 的错，而是 controller 没有给出退出条件。

对应到你列的几个问题，我的体感是：

  • 上下文过短：
    不要试图让主模型记住一切，改成“短上下文 + 外部记忆”。让它每轮先读一份压缩过的 state，再按需调用资料。

  • 话题漂移：
    给每轮生成前都附一个很短的任务卡片会明显好很多，比如：
    当前目标 / 本轮只做什么 / 不要做什么 / 输出格式。
    这比单纯拉长上下文更有效。

  • 工具调用出错：
    最好把工具设计成参数少、类型硬、失败可重试。很多时候不是模型不会调，而是接口太“自由”了。能把多参数 API 包成几个窄工具，成功率会高不少。

  • review 死循环：
    reviewer 不要只负责挑刺，最好强制它输出：
    1）是否通过；
    2）最多 3 条修改意见；
    3）达到什么条件就停止。
    否则它会天然趋向于一直继续优化。

如果场景是科研综述/review，我甚至觉得可以把 reviewer 改成 rubric 打分器，按“完整性、相关性、证据充分性、结构”打分，低于阈值再返工；这样比开放式批评更不容易无限循环。

一句话总结：
别指望一个大模型在长对话里自然地维持秩序，秩序通常要靠你在系统外面补出来。

2 个赞