Dosu：Github维护Agent，与LangSmith携手打造可持续学习Agent

先来说说Dosu是什么。

如果你经常在GitHub的Issues里跟各种Bug“搏斗”，翻来翻去搜解决方案，那你大概率见过一个叫

的身影，在帮忙解答问题。

简单来说，Dosu就是一个

。它的任务很明确：帮开源项目的维护者们减轻负担——鼓励贡献者、整理Issue、分类Bug、回答问题，一条龙服务。

Dosu的CEO Devin Stein发现了一个普遍现象：那些受欢迎的开源项目，团队时间大部分都花在了维护上，而不是开发新功能。Dosu存在的意义，就是接过一部分维护工作，让开发者的精力集中在功能创新上，同时也能给社区提供即时响应，帮用户解决问题。

Dosu在2023年6月底正式发布。最初几乎没什么用户反馈，团队那时候的方法也很“原始”，每天就靠 grep 和 print 语句检查日志，一点点找可以改进的地方。

和传统软件更新不一样，改大语言模型（LLM）的逻辑没那么简单。你很难预判一个小改动到底对整体性能产生什么影响。这就带来一个核心问题：怎么确保每次改动都是正向的呢？换句话说，必须做到两件事：

• 在表现好的地方，保持住性能

• 在表现差的地方，实实在在地提升性能

“评估驱动开发”（EDD）这个概念，和测试驱动开发有点像，它的核心是给开发过程

。

通过EDD，Dosu的改进流程就变得很清晰：

1. 先创建一些初步的评估标准，用来衡量新行为
2. 把新行为推给用户
3. 监控线上的实际结果，找出失败的模式
4. 把每种失败模式的例子补充到离线评估数据集里
5. 针对新的评估集迭代优化，提升性能
6. 回到第一步，重复这个循环

这个工作流一开始效果挺好，但随着用量增长，想要跟上Dosu的节奏就变得越来越难了。

到现在，Dosu已经安装在数千个GitHub仓库里，全天24小时不间断地生成响应。Dosu团队也为此构建了几十个子模块，用来智能处理不同类型的场景，并且随着模型研究的进步，不断迭代问题的解决方案。

不过，成长也带来了挑战。Dosu的活动越来越多，想要监控每一条响应、识别生产中的故障模式，几乎变得不可能——而这恰恰是EDD工作流中至关重要的一环。团队需要找一款工具，既能帮助监控Dosu的活动，又足够灵活，能融入现有的工作流程。

当时定的评估标准有几条：

• prompts必须存在于Git中
  ——在EDD的理念里，prompts就是代码，任何改动都应该遵循和代码更改同样的标准。

• 代码级跟踪
  ——Dosu不只是一连串的LLM请求，它希望在单个跟踪里能追踪到LLM请求之间的元数据。

• 数据导出要方便
  ——已有的评估数据集和工具要能保留使用。

• 可定制、可扩展
  ——LLM发展太快，构建LLM应用没有标准答案，团队希望自己能控制追踪哪些元数据，根据需求定制。

研究了一圈市面上的工具之后，Dosu团队发现LangChain推出的LangSmith，几乎满足所有要求。

LangSmith最让Dosu团队兴奋的，倒不是它时尚的UI或丰富的功能集，而是它的SDK。这份SDK提供了团队一直在寻找的细粒度控制和可定制性。

要尝试LangSmith，只需要给一些和LLM相关的函数加上一个@traceable装饰器就行。

这个装饰器有个意想不到的威力——它能把函数和LLM调用的跟踪信息都发送给LangSmith。这样一来，在LangSmith的UI里，就能在同一个跟踪记录中看到原始的输入、渲染后的提示模板，还有LLM的输出结果。

LangSmith开箱即用，让团队能了解Dosu的全部活动。接下来，就是用它来识别故障模式，并集成到EDD工作流程中去。

Dosu每天收到的用户请求五花八门，从简单的代码库问题，到升级新库版本的错误跟踪，再到询问功能状态。输入越多，出现错误的概率自然就越大。

怎么判断哪些是Dosu处理得不好的请求或错误结果？可以从几个维度入手：

• 显式反馈
  ——就像ChatGPT里经典的赞/踩按钮，用户直接表态。

• 用户情绪
  ——用户在GitHub Issue上回复Dosu时，语气和内容往往能说明它到底有没有帮上忙。

• 内部错误
  ——LLM可能因为各种原因失败：输入或输出是不是太大了？生成的响应格式是不是不对？

• 响应时间
  ——Dosu优先保证质量，但响应缓慢的原因也需要搞清楚。有些请求需要快速响应，有些则需要更慢但更精确的答案。

LangSmith的高级搜索功能在这一点上特别有用，可以轻松识别出异常行为。团队能够根据一系列标准进行搜索，包括

。LangSmith还可以给每个跟踪记录附加额外的元数据，进一步扩展搜索能力。

一旦定位到失败的行为，EDD的工作流程就又回到原来的节奏：去LangSmith里搜更多相似例子，加进评估数据集，针对评估结果迭代，推送新版本的Dosu，然后重复。

虽然

（prompt engineering）对LLM的性能很关键，但Dosu不是一个纯粹的LLM，它是一个产品。如果产品的体验取决于用户的提示工程能力，那就太不稳定了。

既然提示工程这条路行不通，

（fine-tuning）呢？Dosu流量够大，收集微调数据集相对容易。但微调也有几个致命的弱点：

• 模型管理太复杂。如果给N个客户各微调一个模型，就得服务、重新训练、监控N个不同的模型，这事能解决，但非常耗时。
• 微调模型是静态的。就像提示一样，微调模型固定在某个时刻。组织一旦发生变化，数据漂移就会让模型性能以意想不到的方式下降。

静态的上下文学习也容易受到数据漂移影响。相比之下，

是一个简单而有效的方案。

上下文学习有个优雅的地方：它只需要调整一个变量——示例。要让Dosu了解一个组织的具体细节，团队只需要为该组织、在给定时间、针对给定任务，选择出最佳示例。

当然，在选出最佳示例之前，得先收集它们。当用户纠正Dosu的回答时，团队会把这次纠正结果保存为该任务的示例，并和用户的组织关联起来。所有示例都存入一个数据库，称之为“存储示例”，很像传统机器学习里的特征存储。

现在，每当Dosu要执行任务时，都可以去存储示例里搜索最相关的例子。这就把学习问题转化成了一个检索问题，和RAG的做法类似。最终的持续上下文学习流程在概念上很简单：

1. 收集用户的更正，保存到存储示例
2. 推理时，搜索示例存储，找到和当前输入最匹配的示例
3. 重复这个过程

结果正是团队想要的：Dosu以一种自然的方式了解组织，并随着时间的推移适应变化。

LangSmith具备实现持续学习所需的全部构建模块。要收集用户的更正示例，LangSmith可以把这份更正作为反馈，附加到运行记录（run）中作为反馈。

至于存储示例，可以直接依赖LangSmith的数据集。要插入示例，既可以通过规则来实现，也可以直接调用数据集API。

持续学习能创造一种神奇的产品体验，让最终用户能够按需定制Dosu。通过不断学习，Dosu当然还会犯错，但它能像伙伴一样，从错误中吸取教训，确保不再犯同样的错。

自动标记只是Dosu团队融入持续学习的一个例子。他们还在积极探索如何把持续学习整合到检索、答案生成，以及Dosu的许多其他任务中去。