@LangChain: Austin Berke, Lead AI Product Engineer at @Harmonic recently shared how they rebuilt Scout on Deep Agents, quadrupling …

Austin Berke, Lead AI Product Engineer at @Harmonic recently shared how they rebuilt Scout on Deep Agents, quadrupling retention along the way.

Watch the full fireside chat at https://t.co/WTE470p7VQ https://t.co/1MKtizqOTO

Tl;DR：Harmonic 用 Deep Agents 重构了 Scout，第一周到第四周的留存率提升了 4 倍；关键是把代理、前端和确定性进程之间的上下文打通，用文件系统作为共享存储，而不是让模型“发射后不管”。

Harmonic 与 Scout 是什么

Harmonic 是创业生态系统的实时数据库，追踪 3700 万家公司、2 亿人、22 万名投资者，并且每周都在增加。绝大多数顶级 VC 都依赖 Harmonic 做项目挖掘——目前排名前 10 的 VC 里有 9 家都在使用 Harmonic。

Scout 是构建在整个生态系统之上的自然语言界面，运行在 Deep Agents 之上并连接到数据。它既能处理“谁是 LangChain 的 CEO”这种简单查询，也能处理非常复杂的任务，比如“描绘这个行业的格局”“创建一个市场地图的可视化”，或者“根据这个评分标准给团队打分，从 1 到 10”。在后台，它基本上是一个工具循环：执行任务，然后把响应渲染给用户。界面结合了类似 Claude Code 或 ChatGPT 的聊天体验，也包含一些自定义构建的交互元素——比如点击公司、添加到列表、拉出侧边栏——既能交互，又保持代理式的对话流。

转向 Deep Agents 后的效果

这是令人印象深刻的指标：自从切换到 Deep Agents 后，Scout 从第一周到第四周的留存率提升了 4 倍。

定性反馈也很强。有人提到：“我和其他公司的一些同事聊过，我觉得每个人的秘密武器都正在变成 Scout。”另一个人说：“它就像是我的天堂。”

从 Scout 1.0 到 Deep Agents

Scout 1.0 是初始版本，大约一年半前还算前沿，但很快就过时了。它的概念是：如何处理自然语言查询？比如“给我看看过去两个月里在纽约融过资的所有金融科技 SaaS 公司”。

当时有一个查询解析图，接收查询后：

• 提取语义部分（金融科技 SaaS），针对嵌入向量运行
• 获取位置信息
• 获取融资部分，路由到自定义搜索语言

在 LangGraph 里，每一个节点都有自己的模型、自己的评估，需要大量维护，靠不断调优来通过评估。

快进到现在，模型变好，各种框架出现，于是他们切到了 Deep Agents。新架构的图要简单得多：中间只有一个工具调用循环，由模型、工具和中间件组成。中间件运行在模型之前、模型之后，也运行在代理之前和代理之后，整个就是工具调用循环。

现在 Scout 基本上就是模型加工具。他们创建了一堆能连接到生态系统的工具，从搜索实体、使用 Tavily 搜索网络，到按 ID 丰富数据、按 URL 丰富数据，以及和用户的 CRM 交互——添加到列表、操作列表、移动东西。

他们发现，用前沿模型和框架，给它一堆工具（甚至 50 个工具），模型都能很好地选择正确工具，执行非常复杂、长时间的组合任务。

为什么选择 Deep Agents

有了 50 个工具和大量交互，有些线程会变得非常长。比如公司搜索返回 1000 个结果，每个结果里可能还包含嵌套的团队成员、融资信息等等。实际响应返回后，可能有几千行甚至几万行长，具体取决于模型选择拉入什么内容。如果只是通过消息列表传给模型，很快就会非常拥挤。

Deep Agents 最核心的优点之一是它管理上下文：

• 压缩：消息列表变长时，它会运行压缩，让代理可以无限继续下去。
• 工具调用驱逐：比如那个返回数千行的公司搜索调用，Deep Agents 会把它拉到文件系统中，并返回一个指针，指向如何按块拉取文件内容。这样模型可以继续运行，而不会被整个响应污染。
• 技能和自定义中间件：可以在运行时拉入提示信息，而不是让每次调用都包含所有内容。
• 文件系统抽象：可以随意读写不同的工件到代理中。
• LangSmith 集成：把新框架接入现有图非常简单。用户仍然看到同样的聊天界面，团队可以渐进式地进行 A/B 测试，再把用户迁移过去。

代理 vs 产品：模型 + 框架 + UX

如果说代理是模型加框架，那么产品就是在代理之上加上某种用户体验，让用户能很好地交互。Scout 的情况是：前沿模型 + Deep Agents 框架 + 一个自定义 Web 界面。

这里有一个核心张力：代理喜欢那些“像代码”的东西——模型是在编码任务、工具调用、结构化 JSON 上训练的，喜欢把响应结构化成 XML、JSON；框架那边还有文件系统原语，会写 markdown，输出“嘿，我把这个文件写到了这个路径”。但用户并不想看到这些，尤其 Scout 的用户大多数是非技术背景的。

所以必须应对这个张力：如何充分利用框架的全部能力——它在前沿模型配合下非常强大——同时把它构建成对普通人普遍有用的产品，又不损害能力。

框架上下文契约：对模型不可见的东西

Deep Agents 管理上下文的方式，本质上与模型有一个契约：

• 模型总是只获取一个消息列表：助手消息、人类消息、工具消息。
• 每次调用模型时，传入一个消息列表，模型流式返回接下来该出现的内容。
• 框架的工作是把东西从消息列表中拿出来腾出空间，确保不会触及上下文窗口，也不会上下文腐化。
• 消息列表里的所有内容始终对模型可见；被框架卸载的所有东西，存在于代理的管辖范围内，但并非每次调用都直接对模型可见。

关键在于：框架从消息列表中拿出来的任何东西，都必须通过工具让模型可以使用。如果拿出一个文件，就返回指向该文件的指针，并提供工具一次读取一块。这就是渐进式披露：先有一行轻量级描述，说明某个工具里有什么，模型再选择按需分块构建上下文。

对 UX 设计来说，重要的推论是：任何位于这两层（消息列表和框架）之外的东西，对模型基本不可见。如果你构建了一个与对话并排渲染的 UX，但它既不在消息列表中，也不在框架的卸载范围内，那代理就完全不知道它存在。

案例：可视化

Scout 上最有趣的用例之一就是可视化。人们开始问：“你能给我做一个这样的图表吗？”或者“做一个这个行业的市场地图图形吗？”团队本来没有任何方式去显示它，但模型会尝试输出 SVG 代码或 HTML/CSS。结果发现这些开箱即用的效果看起来不错，于是他们想把它变成真正的产品表面。

不规范的做法：暴露一个工具，说“渲染这些数据”。传入参数，返回“成功：true”这类空操作。前端拦截调用并根据数据渲染，但代理完全不知道实际发生了什么——它只是把东西扔进虚空，收到成功消息。如果用户问“为什么那家公司在左边？”，模型没有关于前端在做什么的任何上下文，因为那完全在框架的管辖范围之外。

更好的做法：让它完全存在于消息列表中。对于可视化这类东西，通常足够小，直接放在助手消息里没有问题。做法是提示代理使用分隔符，比如用 XML 标签（如 html_visualization）包裹它要输出的 HTML。前端可以作为输出的一部分拦截并实时渲染图形。最重要的是，模型对正在发生的事情有完全的可见性——它知道“为什么那家公司在左边”，因为是它自己做的；用户让它“把这三个东西移到右边，换个背景颜色”，它也有完全自主权去修改。因为这一切都生活在消息列表内部，始终对模型可见。

案例：大规模公司搜索

Harmonic 最大的用例之一是搜索公司。有人可能想从之前的搜索出发，找纽约的金融科技公司，结果可能有成千上万家。前端需要执行搜索，同时代理也必须知道结果是什么。但如果消息列表里有 10000 行内容，直接塞进一条消息就太大了。

天真的做法：模型触发一次搜索，但不把信息返回给模型。这正是他们一开始做的事，引发了一堆问题：模型调用某个搜索服务，前端拦截调用并开始在旁边渲染结果，可没有信息回到模型。用户跟进说“顶部有五个结果，我不知道它们为什么会出现在这里”或“你能告诉我第二家公司的 CEO 的更多信息吗？”模型没有任何上下文，甚至没有办法构建上下文去知道那里有什么。用户看到了一个很棒的东西，代理却失去了构建上下文的能力。

更好的做法：创建一个工具，返回某种标识符，再提供工具来进一步探索那个工件。模型调用类似“开始公司搜索”的东西：

• 执行搜索，返回搜索 ID、状态、结果数量
• 前端拦截它，并随着结果到来开始渲染
• 模型有了搜索 ID，可以用工具来检查工件
• 模型可以说“获取这个搜索 ID 的搜索状态”“获取这个搜索的前 10 个结果”“获取第二批结果”

这样模型就能按需构建上下文。如果用户问“为什么这五家公司在顶部？”，模型能说“让我看一下”，然后触发工具调用，获取前 10 个结果，再回答用户。

最佳做法（Deep Agents 原生版本）：使用文件系统作为共享存储，供代理、前端，以及任何其他确定性进程使用。

主代理作为 Deep Agents 框架的一部分，自带文件系统工具，可以读文件、执行 ls、cd、grep。团队可以创建并启动第二个搜索代理，它挂载到主代理正在运行的同一个文件系统上。搜索代理可以发起一个会运行一段时间的搜索，运行自定义评估，对结果排名、排序、加注释——但它运行在同一个文件系统上。

这样：

• 在搜索代理运行期间，主代理可以任意检查输出和状态
• 前端也连接到同一个文件系统，通过 API 直接从那里渲染结果
• 前端可以在结果到来时查看它们，最多成千上万个结果，经过排名、排序并带有注释
• 用户仍然可以问“为什么这五家在顶部”或“为前五家公司起草外联邮件”
• 主代理能说“好的，让我读一下这个文件，我知道它存储的路径”，然后读前 10 行、读接下来的 10 行，把信息拼凑起来

一切和谐了：前端实时渲染，搜索代理持续写入数据，主代理随时能掌握内容。

启发式判断：你是否在对抗模型

最后一个技巧，也是团队学到的判断方向是否正确的启发式方法：

如果你发现自己正在与模型对抗——比如你在说“相信这个会被渲染出来，你调用这个工具之后用户会看到这个，相信我，不要回应，不要把这个包含在你的响应里”——这就像一种嗅探测试，说明某些东西可能对模型不可见，或者说明有些问题可以通过更好的第一性原理设计来解决，比如框架和模型之间的上下文流。

回顾一下：代理是模型加框架，产品在它之上添加了 UX。而构建产品时，最值得警惕的时刻，就是当你开始要求模型信任一个它看不见的东西。

Source: @LangChain: Austin Berke, Lead AI Product Engineer at @Harmonic recently shared how they rebuilt Scout on Deep Agents, quadrupling …