专栏 · Agent 工程手艺 › 第 184 期 · AGENT 工程 · 收录于 2026 年 8 月 21 日
什么时候该自建 agent harness——Harrison Chase(LangChain)
HC
Harrison Chase · Sequoia Capital
6.7万观看
922赞
1.4%点赞率
33评论
24.1万频道订阅
数据截至 8 月 27 日
TL;DR · 三句话
- 一harness（外壳/骨架，即包在模型外面那层负责调工具、管上下文、决定下一步做什么的代码）的本职只有一句话：在正确的时间点，把正确的 context 送到模型面前。 今天外面几乎所有 agent 的内核都是同一个「LLM 在循环里不停调工具」，所谓高级 harness 不过是在这个循环的几个固定位置上挂了钩子。→ 详细
- 二该自建还是用现成，判据是 in / out of distribution（在不在模型训练练过的那类事的分布里）：整体任务越偏离模型练过的东西，就越该定制 harness；但任务里像「编辑文件」这种模型被 RL 专门练过的小动作，要贴着模型层原样保留。 LangChain 的 DeepAgents 为此做了 model profiles，按当前用的是哪个模型自动切换编辑文件的实现。→ 详细
- 三harness 最终会收敛成一种还是分化成千百种，Harrison 的原话是「我不知道」——正因为不知道，eval（评测）和 observability（可观测性）才是这个快变领域里唯一耐用的那层。 而 agent 出错时，「多数情况下毛病出在这次调用拿到的 context 不够好，而不是模型不够强」。→ 详细
01
agent 就三块：harness、model、context——「把智能握在自己手里」意思是三块都要握
- Harrison Chase 是 LangChain 的联合创始人兼 CEO。他给整场定的框架是「owning your own intelligence（把智能握在自己手里）」：在 LangChain 看来 agent 只有三块——一个 harness，负责编排一个 model（模型）和一堆 context（上下文，即这一轮喂给模型看的所有材料）；想真正掌握自己的智能，这三块多半都得握住。→ 详细
- model 这块他不多讲（同场 Fireworks 的 Lin 刚讲过开放权重模型），只强调换模型的能力：以前叫「cloud agnostic（云中立）」，随时能换云厂商，现在同一件事发生在模型上——一是避免被锁死（lock-in），二是有更好的模型出来时马上能用上。context 这块则要「全归你」：memory（记忆）、语义知识、过往对话记录，作用是把 agent 个性化并在运行中给它引导。→ 详细
02
harness 的本职：在正确的时间点，把正确的 context 送到模型面前
- 这是全场最凝练的一句定义。「harness 的核心职责就是：在正确的时间点，把正确的 context 送到模型面前。」 它要围绕固定 context（每次都带的，如系统提示、工具说明）和动态 context（这一轮才产生的）做全部编排，塞进模型的 context window（上下文窗口，模型一次能看进去的量的上限），拿到回复，再拿回复去干点什么。→ 详细
- 他特别点出一个因果闭环：agent 要完成任务就得跟外部系统交互（查数据库、跑命令、调 API），而你一跟外部系统交互，它们就会吐出更多 context，这些新 context 又回流进 agent 的循环里。所以 context 不是一次性塞进去的静态包袱，是跑的过程中越滚越大的雪球——harness 就是把这套滚雪球过程编排起来的那个东西。→ 详细
03
今天几乎所有 agent 的内核是同一个：LLM 在循环里调工具
- 「大家一提 agent，其实说的就是一个 LLM 在循环里不停调工具。」 只有四步：来一个请求 → LLM 生成一段内容 → 内容里可能包含要调用的工具，有就执行 → 把 observation（执行结果的观察值）回传给 LLM，再来一轮。他说这架构「非常简单，但非常通用」，今天外面几乎所有 agent 内核都是这个——差别不在内核，在于你往循环的哪些位置塞了什么。→ 详细
04
middleware：不动核心循环，只在四个位置挂钩子
- 他现场对比了两个自家产品：LangChain 是一个「极简的基础 harness」，只有那个裸循环；DeepAgents 则是「我们做的、模型无关且更通用的 Claude Code 版本」——干的事多得多：接文件系统、有 skills、有 sub-agents（子智能体，主 agent 派出去干专项活儿的小 agent）。关键是 DeepAgents 就搭在那个极简 harness 之上，全靠一批「操纵杆」定制出来。→ 详细
- 这些操纵杆他叫 middleware（中间件，即夹在流程节点之间、能拦一手做点事的小代码块），可挂的位置他列了四个：① agent 被调用之前跑一段代码；② 每次模型调用之前跑一段代码；③ 把模型调用整个包一层；④ 把工具调用整个包一层。 就靠这四个位置，「你能把这个简单的核心循环定制出非常强的花样」。→ 详细
- 他还点破了一件很多人没意识到的事：「很多编码 agent 里的 hooks 和 plugins，本质上干的就是这件事」——拿住那个在跑的基础循环，在各个节点上挂点钩子，让你能改。也就是说 hooks / plugins / middleware 是同一个东西的三个名字，只是不同产品的叫法不同。→ 详细
05
摘要和 context offloading：两个最典型的 middleware 用法
- 通过 middleware 能给循环接上的东西他列了一串：沙箱（隔离的临时运行环境）、文件系统、sub-agents、memory、摘要（summarization）——agent 还是在那个循环里跑，只是身上多挂了这些。→ 详细
- 两个最典型的例子正好各占一个挂载位：摘要挂在「模型调用之前」（先检查 context 是不是太长，太长就压缩一遍再送进去）；context offloading（上下文卸载）挂在「工具调用外面」（把体积很大的工具调用结果卸出去、不塞进上下文，需要时再取）。他的落点是：这些就是你把 harness 调教到贴合自己领域的插入点。→ 详细
06
cognitive architecture 是 2023/2024 年模型不够好时的产物，现在大半被吸进了 harness
- 定制 harness 的第二条路是写一套更显式的 cognitive architecture（认知架构，即你自己画好流程图、规定 agent 第一步干什么第二步干什么）。他把这条路明确打上了时代标签：「2023、2024 年那会儿大家基本都这么搭 agent，因为当时模型还不够好，扔进循环里跑不起来。」 换句话说，这类硬编排最初是为了补模型能力的短板才存在的。→ 详细
- 他现场给了两个具体例子：① deep research（深度调研）——先生成一堆子问题，扇出去，再逐个执行；② code review（代码评审）机器人。两张图里都是「很定制化的步骤」，一格一格写死的。→ 详细
- 然后是这一场里最该被划重点的一句判断：「这类东西现在很多都被吸进 harness 里了。」 他补充说，他说的 harness 仍然是那个核心循环，只是这些步骤改以「对核心循环做特定改造」的形式加进去。也就是说，原本写死的流程图正在退化成循环上的几个钩子。→ 详细
- 但他没有一棍子打死：「对某些非常具体的流程，我们确实还看到有人在用这样的认知架构，把 agent 往特定方向硬引导。」 这句留了口子——后面 Q&A 里他给出了这个口子的真正理由（见第十八节：可预测性与可控性）。→ 详细
07
路线建议：先用通用 harness 抢时间，把场景收窄之后再加关卡
- 「先从通用 harness 起步，这最容易上手，出价值最快（quickest to time to value）；等你把想做到极致的那个场景收窄了，再往上加各种关卡（gates）和校验（checks），把它引导到特定路径上。」 顺序有讲究：收窄场景在前，加约束在后——先知道要在哪件事上做到极致，才知道该在哪里设卡；反过来先把流程画死，等于在还不知道要优化什么的时候就把可能性锁掉了。→ 详细
08
自建还是用现成？判据是 in / out of distribution
- 「我们被问得最多的问题之一是：什么时候该自建 harness，什么时候直接用现成的？」 他先摆事实：很多现成 harness 是绑定特定模型的——Claude Code 和 Claude Agent SDK 配 Anthropic 的模型，Codex 配 OpenAI 的模型。然后他坦承「我觉得这在行业里还是个很大的开放问题」。→ 详细
- 他的一般性回答就一条判据：「你越是落在模型训练分布之内（in distribution），现成 harness 的效果就越好；一旦你越走越偏、跑到分布之外（out of distribution），那你多半就得对 harness 做些调校。」 大白话就是：你要 agent 干的事，越像模型被训练时反复练过的那类事，人家配套的外壳就越合身；越是模型没练过的怪活儿，你越得自己改衣服。→ 详细
- 关键在于这条尺子不是二选一，而是分层量的：整体任务的分布位置，和任务里每个具体动作的分布位置，可以完全不同。这就引出了下一节那个例子。→ 详细
09
大任务在分布外、小动作在分布内：编辑文件的 RL 差异与 DeepAgents 的 model profiles
- 他用同场讲者 Gabe 讲的法律 AI 做例子（他提到 Gabe 说过他们有自己的 harness）：法律 AI 这个整体任务，对主流模型来说是 out of distribution 的；但法律 AI 里有些环节仍然在分布之内——比如「编辑文件」。 → 详细
- 而「编辑文件」这个动作有个很多人不知道的细节：所有主流模型都被 RL（强化学习，用「做对给奖励」的方式把某个动作练成肌肉记忆）专门训练过它，而且训练方式还各不相同。 原话是：「OpenAI 的模型和 Claude 的模型在各自 harness 里编辑文件的方式就不一样，结果就是它们各自最擅长的编辑文件方式也不一样。」 也就是说，同一个「改文件」的活儿，你用 A 家的写法去指挥 B 家的模型，会平白掉分。→ 详细
- LangChain 在 DeepAgents 里的解法叫 model profiles（模型画像）：对于编辑文件这类落在模型分布内的动作，根据当前用的是哪个模型，在不同的编辑文件实现之间自动切换。→ 详细
- 他把这条提炼成了一句可直接照抄的设计原则：「整体任务 out of distribution 时定制整个 harness，但里面那些 in distribution 的小零件，尽量贴着模型层原样保留。」 定制的量不是一个总开关，而是要逐个零件问一遍「这块模型练过吗」。→ 详细
10
Satya 的三句话：私有 eval 定义「什么叫做得好」
- 转到第二大块（evals 和 observability）时，他引了两周前 Satya 在 Twitter 上写的一篇长文，挑出三句他印象特别深的话：→ 详细
- 「建立你自己的私有 evals，因为 eval 定义了在你这个组织内部『什么叫做得好』。」（eval＝评测，即拿一批固定题目去量模型/agent 做得好不好）
- 「把组织的记忆、trace、反馈、决策和机构性知识的所有权握在自己手里。」——他特意说明「反馈」这两个字的加粗是我加的，即他本人最看重的是反馈这一项。
- 「打造自己的持续学习闭环、自己的爬坡机器（hill climbing machine），让你在 AI 上的投入能对公司价值形成复利。」
- 他的解读是：这三句正好点出 evals、observability 和它们驱动的学习闭环，对于真正掌握并复利放大你的智能有多重要。→ 详细
- 落到实践：「我认为每家公司在做关键任务级别（mission-critical）的 agent 时，都会给这个 agent 造一套 benchmark。」 benchmark 有两个用途——一是定义和捕捉回归（regression，指改完一处，本来能做对的事反而做错了），二是拿它来爬坡；爬坡时既可以调 harness，也可以调模型。→ 详细
11
Harbor：正在成为行业标准的开源 eval runner，一个任务四个文件
- 他点名的行业标准工具是 Harbor——一个开源的 eval runner（评测运行器），作者就是做 Terminal Bench 2 的那个团队（Terminal Bench 2 是评测编码 agent 的行业标准 benchmark 之一），现在 Harbor 在很多领域都很流行。→ 详细
- 他现场展示的另一个例子是 Frontier Bench（又一个编码类 benchmark）：拿到一张成绩表，横向对比不同的 agent harness、不同的模型、不同的 reasoning effort（推理强度，即让模型多想一会儿还是少想一会儿的档位），一眼看出各自在你的任务上表现如何。他的结论是「当你想把任务定义清楚时，为你自己的任务准备一套 benchmark 会变得极其重要」。→ 详细
- Harbor 的结构很朴素：拿一个 agent 去跑一个数据集，数据集里有一堆任务；任务一般跑在沙箱里（因为数量多、你会想并行）；每个任务都有自己的独立环境。→ 详细
- 一个 Harbor 任务由四样东西组成，这四样是这一节最值得抄走的清单：
- ① environment（环境）：定义 agent 运行的环境。长时运行、更有状态的 agent 需要跟环境交互，所以起一个沙箱，用 Dockerfile（一份声明「这台机器上装什么」的配置文件）定义好独立环境，让它在里面跑。→ 详细
- ② solution（标准答案解法）：用来做 sanity check（合理性自检），他自己说「没那么有意思」。→ 详细
- ③ test（验证器）：他说这个更有意思——测试脚本可以干任何事：跑代码、跑单元测试、跑另一个 LLM 当裁判、跑一个 agent 当裁判。打分规则就写在这里。→ 详细
- ④ instruction.md：就是给 agent 的那段 prompt。→ 详细
- 跑完拿到什么？他展示了 LangSmith（LangChain 做的 evals 和可观测性平台，跟 Harbor 有很好的集成）里的实验列表：能看反馈分数（这个例子里是单一的奖励函数），也能追踪延迟和 token 用量。他强调：「给 agent 做 benchmark 时，你多半不只关心准确率，也关心延迟和成本，所以这些你都会想追踪。」 → 详细
12
observability 被严重低估：agent 出错，多数不是模型不行，是 context 不行
- 「observability（可观测性，即能看清系统内部每一步在干什么的能力）听上去很基础，但我觉得它对 agent 来说真的很重要，而且被严重低估了。」 这是他给这一块下的判断。→ 详细
- 接着是全场排障价值最高的一段推理：agent 出岔子，根子上是某一次 LLM 调用出了问题；而一次 LLM 调用出问题只有两个原因——一是模型不够强，二是这次调用拿到的 context 不够好。「而我的判断是，多数情况下毛病出在第二个上。」 这句话直接改变排障顺序：先查喂进去的料，再怪模型。 → 详细
- 由此推出你必须能看清的东西清单：到底有什么进了模型的 context window、这些 context 又是怎么一步步攒起来的、跑了哪些步骤、调了哪些工具、这段 context 是从哪冒出来的。 「agent 出错要 debug 的时候，这些信息全都至关重要。」→ 详细
- LangSmith 为此做了一种偏「给人看」的友好视图，他说跟你在 Claude Code 里看到的挺像——会把一部分 tool call 折叠起来，界面上显示「七次 tool call」这样的提示，让人一眼扫过去就能看懂。→ 详细
13
trajectory 是给人看的，trace 是给 debug 用的
- trajectory（轨迹） = 你在 Claude Code 里看到的那一长串消息：输入一条 human message → 它发起一堆 tool call（底层也都是 message）→ 给出回复 → 你再输入下一条。他说这种消息 trajectory 正越来越成为这类 agent 的核心部分。但光靠它不足以彻底 debug，所以 LangSmith 还提供完整的 trace（全链路留痕），可点进任一环看清模型内部。两层配套：trajectory 用来快速扫，trace 用来钻进去。→ 详细
14
持续改进 agent 的五步配方，卡点是「反馈从哪来」
- 这一页出自他们团队一位同事在 swyx 办的 AI Engineer 大会上讲过的内容，是一套持续改进 agent 的配方，往大了说只有五步：造一个 agent → 跑起来 → 收集大量 trace → 把 trace 数据筛选整理 → 基于整理出来的数据去跑实验。 他自己也承认「听着简单，底下当然一堆复杂度」。→ 详细
- 整套配方里最关键、也最容易卡住的一环是反馈，而反馈只有两个来源：来自环境，或来自合成。→ 详细
- 关于环境这一路，他说了这一场我认为最反直觉的一句话：「我觉得 agent 设计里最被低估的一件事，其实是 UX 设计，也就是你怎么把 agent 呈现给用户。」 理由是：如果呈现得足够聪明，你能从用户那儿拿到大量反馈。 而现实是——「他们未必会明确去点赞或点踩，几乎没什么人真会那么干。但只要 UX 设计得巧妙一点，你还是能捞到一部分反馈。」 换句话说，UX 在 agent 产品里不只是好不好用的问题，它直接决定了你的数据飞轮有没有燃料。→ 详细
15
合成反馈要便宜：微调 SLM 顶替 Opus 当裁判，简单的直接写代码判
- 合成反馈的做法是在 trace 上跑他们所说的 online evaluator（在线评估器），让它对各种维度做判定。→ 详细
- 成本这一笔账他算得很直白：Gabe 提到过 LangChain 和 Harvey（法律 AI 公司）做过一个实验，把这类 LLM-as-a-judge（拿大模型当裁判，即用一个模型去给另一个模型的输出打分）的成本大幅压了下来。理由是：「你想想，如果系统里每进来一条 trace 都拿 Opus 跑一遍，账单会非常吓人。」 → 详细
- 他给了三档由重到轻的替代方案：① 微调一些 SLM（小语言模型，参数量小、跑起来又快又便宜的那种）专门干这件事（LangChain 自己就这么做的）；② 用现成模型配定制 prompt；③ 如果要测的东西足够简单，直接写代码判定就行——不是所有判分都需要模型。→ 详细
- 拿到数据之后，agent 的三块各有各的更新手段，一一对应：harness → 做 harness engineering（外壳工程）；model → 做 fine-tuning（微调）；context → 做 memory（记忆）。 他补充说 LangChain 想得最多的是 harness engineering 这一块，而同场接下来的 Trajectory 会讲 fine-tuning 那条路——流程其实一模一样：跑 agent、拿 trace、用数据改进系统。→ 详细
16
LangSmith Engine：把数据飞轮本身做成一个 agent
- 他们过去几个月一直在琢磨的问题是：这件事怎么才能尽可能自动化？ 理由很实在——「因为它很棘手，而且极其耗时间。」 人工筛 trace、找模式、提修复，是纯体力活。答案是 LangSmith Engine：「本质上就是一个坐在你的 trace 之上、把这些活儿都干了的 agent」——筛选整理 trace、跑实验、针对 harness / model / context 那三样之一给出修复建议；LangChain 主要聚焦在 harness engineering 这块。→ 详细
- 现场演示：LangSmith 里有个叫 Engine 的标签页，是一个在后台跑的 agent，会生成他们叫 issue board（问题看板）的东西——对应配方里「整理数据」那一环。它底层是「一个能调用我们 LangSmith CLI 的 coding agent」：用 CLI 可以按反馈等条件筛 trace，他们给它一段很长的 prompt 再配几个 sub-agent，让它自己翻数据、找问题、看共性。→ 详细
- 产出长什么样：每条 issue 有描述，还链到对应的 trace 可点进去看佐证；再往下是具体改动——演示里有几处很简单的 prompt 改动、改 context 的一部分、改一些指令，还有往 harness 里加一段代码。他的总结是：飞轮本身特别简单——跑 agent、拿 trace、看模式、修。 → 详细
17
Engine 跑 Engine：issue bench 与那次「Codex 化」sprint
- 现场第一个提问就很刁：「Engine 本身就是个 agent，你们有没有拿 Engine 去跑 Engine 自己？」 → 详细
- 答案是跑了，一直开着。而且 Engine 还接了 Slack，会把关于它自己的报告发过来——他说这就是他们 dogfood（吃自己的狗粮，即自己先当自己产品的用户）的方式。→ 详细
- 他们还给 Engine 专门做了一个叫 issue bench 的 benchmark，同样是 Harbor 格式，不断拿不同的模型、不同的 harness 在上面跑分。他引 Gabe 的话说，有 benchmark 的一个好处是：你可以把一堆不同的 harness 都放上去跑，看看各自擅长什么、不擅长什么。 → 详细
- 然后是全场最有画面感的一个案例：几周前他们把自家的 Deep Agents、Codex、Claude Code 三家全放上去跑了一轮，结果发现 Codex 有个很有意思的做法——它会给自己写一堆小脚本去跑这些 trace，而且用得非常凶，恰恰是这一点让它表现特别好。 于是他们专门做了一个 sprint，自己管它叫 Engine 的「Codex 化（codexification）」，把这个心得直接搬进 Engine 的核心 harness。→ 详细
- 他由此提炼出 benchmark 的第二重用途（第一重是防回归）：「你可以拿各种东西上去跑，看它们真实表现如何，再把好东西吸收回自己的核心 agent harness。」 benchmark 不只是打分表，它是一台从竞争对手身上偷师的机器。→ 详细
18
harness 会收敛还是分化？「我不知道」——以及金融客户为什么不敢用通用 agent
- 第二个提问是这场最大的开放题：harness 最后会收敛成一种形态（用户被教育成按那一套来、模型也针对那一套做到最好），还是走向分化（每家公司都有自己一套、按自己场景优化）？ 他说这问题他们想了很多，还跟 Factory 的 Eno 专门聊过，但「老实说，我不知道答案」。→ 详细
- 他能给的观察有三条：① 通用 harness 已经足够好，至少在起步阶段能应付很多基础任务，所以他建议先从现成的起步——Deep Agents、Codex、Claude Code 之类都行；② 原因是模型现在确实够强了，而那些让模型变强的要素——能访问文件系统、能开 sub-agent 之类——也基本够用了；③ 但场景越 out of distribution，你就越会想去定制 harness，而这是一个连续的光谱：最极端那一头是从头搭一套完整的、针对性极强的 cognitive architecture；另一头是直接用现成 harness；中间还有 hook、middleware 这些手段可以调。→ 详细
- 他在这里补出了自建的第二个理由，而且和「能力」完全无关：可预测性和可控性。 他举了真实客户：「我们有不少金融服务行业的客户，他们必须要可预测。我们把 Deep Agents 这类东西给他们看，他们会说：『打住打住，这 agent 对我们来说太吓人了，我们更想要那种能把每一步都控住的定制 cognitive architecture。』」 也就是说，硬编排除了补能力短板，还在补「合规和可审计」的需求——后一种需求不会随模型变强而消失。 → 详细
- 最后他讲了一个他自己也解释不清的怪现象：OpenAI 和 Anthropic 在编码上都做得非常好，但他们在「怎么改文件」这件事上走了完全不同的路子，差别还挺大；两边各有 benchmark，他记得对方的看法是其中一种做法就是比另一种好、属于严格意义上的更优（strictly superior）——但两条路仍然并存着。→ 详细
- 他的最终判断是「收敛与分化同时在发生」：模型实验室这边多半会收敛（大家看起来都很擅长编码），harness 也会跟着朝「特别擅长编码」收敛；但与此同时又确实存在那些非常细微的差异，「我也解释不清楚」，目前只体现在很小的地方。他给的分化剧本是：万一某家实验室在生物方向猛扎下去，它的 harness 在生物类 agent 任务上变得特别强，那 harness 之间就会开始分化。 → 详细
- 全场的收束句：「所以我的答案还是『不知道』。这个领域变化太快，这也正是 eval 和 observability 重要的原因——我们得有办法把这些都量出来。」 这是整场逻辑的闭环：正因为没人知道哪套 harness 会赢，所以真正的护城河不是押中某一套外壳，而是拥有把任何一套外壳量出来的能力。 → 详细