LangChain拆解自改进智能体：模型、框架与上下文的三重进化

LangChain团队在近期分享中提出了一个贯穿其产品路线的核心命题：构建能够随时间自我改进的AI智能体。虽然完全自动化的自改进仍被视作遥远的"北极星"，但这条路径正在深刻影响LangChain对智能体架构、数据基础设施和评估体系的思考方式。

智能体的三个可改进维度

在讨论"自我改进"之前，LangChain首先拆解了智能体的构成。他们认为一个智能体由三部分组成：模型、harness（框架外壳） 和上下文。

模型是智能体的核心推理引擎，负责所有决策；harness是围绕模型构建的系统，决定模型能看到什么、执行模型决定的动作、观察验证结果并将数据持久化——LangChain的deep agent、Claude Code、Codex都属于这一层；上下文则是被引入模型的文本、文件、知识和工具。

这三层恰恰对应了三条改进路径：更新模型权重、修改harness代码或提示词、优化上下文内容。改进的驱动方式也可以分层——从完全由AI工程师手动主导，到人在回路中审批后台进程的提议，再到理想中的全自动化。

模型改进：SFT已成熟，RL上限更高

在模型维度，LangChain观察到两种主流路径。监督微调（SFT） 适用于分类、提取、摘要等定义狭窄的任务，流程是收集trace、筛选优质样本、训练模型。据分享，LangChain近期推出了LangSmith微调功能（以CLI形式呈现），与LangSmith交互拉取轨迹数据、过滤并格式化后，交给Fireworks或BaseShift等提供托管SFT API的模型提供商。

对于驱动智能体的核心模型，更复杂的任务开始转向强化学习（RL）。RL不是简单地喂轨迹，而是给出一批任务让智能体rollout、实时打分、反向传播更新，再继续rollout。LangChain指出，SFT有大量托管服务可选，而RL目前缺乏真正优秀的托管方案，复杂度和成本都显著更高，但上限也更高。无论哪种方式，模型更新几乎总是由人发起，因为数据准备和训练决策目前难以完全自动化。

监督微调（SFT）与强化学习（RL）的核心区别在于学习信号来源。SFT 是“模仿学习”：给定输入和人工标注的理想输出，用交叉熵损失训练模型复制该输出，本质是让模型学会“标准答案长什么样”。RL 则只给任务和奖励函数，让模型自己采样多条轨迹（rollout），根据每条轨迹的得分（如任务是否完成、答案是否正确）用策略梯度类算法提升高得分行为出现的概率。SFT 的瓶颈在于标注数据覆盖不到模型从未见过的状态，且会学到标注者的偏差；RL 能让模型在探索中超越示范数据，因此上限更高。但 RL 需要可自动化的奖励信号、大量采样算力和稳定的训练基础设施，工程复杂度远高于 SFT，这也是托管 RL 服务稀缺的原因。

rollout 与反向传播：在智能体 RL 中，一次 rollout 指让模型在环境中完整执行一个任务（可能包含多轮工具调用），记录整条 trajectory 及其奖励；随后用这些轨迹计算策略梯度并反向传播更新模型参数，再进入下一轮采样。由于每次更新后模型行为会变化，旧轨迹可能失效，因此需要反复“采样—更新”循环，这也是 RL 成本高昂的关键。

Harness改进：从代码审查到自动化PR

Harness本质上是代码和逻辑，改进方式是查看trace、识别问题、修改代码、提示词或工具。由于这类改动影响所有用户，通常需要人在回路中审查。LangChain的尝试是LangSmith Engine——一个运行在trace上的后台智能体，将问题聚类、提出修复方案、提交PR、添加测试和评估数据点。其本身不过是一个沙箱中的deep agent，带有CLI连接和专门的子智能体与技能。

你可能没注意到，这个流程的"自动化"目前仍停留在提议层面，审批环节保留在人类手中，这也是LangChain反复强调的务实态度：先把闭环跑通，再逐步移交控制权。

上下文改进：最容易也最依赖领域知识

上下文只是文本，更新成本最低，因此可以在核心智能体、用户、组织等不同层级上维护随时间演进的记忆。LangChain举了两个外部案例：数据分析智能体Hacks构建了统一的上下文层，后台运行审查智能体分析交互、找出上下文缺口并提出修复；营销智能体Profound则持续将数据综合为品牌级记录，并收集交互产生的个人记忆。LangChain自身的开源项目Open Wiki走的是类似思路——分析代码仓库生成知识库，并读取Codex或Claude Code的trace，定位卡点后反馈回知识库。

LangChain认为，三条路径的共同基础是trace与evals。改进循环中最难的部分往往不是技术实现，而是决定"该记住什么、不该记住什么、如何记忆"，这高度依赖具体领域和提示词设计。

Trace：智能体时代的新型数据

LangChain对trace的层级做了清晰定义：单次模型或工具调用是run，run的序列构成trace，多个trace组成thread，而trajectory是对thread的标准化视图。关键在于，无论微调模型还是用编码智能体调试代码，都需要精确的输入输出与事件序列。

他们认为trace是一种新型数据，会暴露传统日志看不到的语义级失败——逻辑错误藏在对话上下文中。这正是LangChain自研SmithDB的原因：一个专为智能体可观测性构建的数据库，其AI过滤器允许用语义问题筛选trajectory，底层逐条评分判断是否符合条件。

SmithDB 的 AI 过滤器解决的是传统数据库难以回答的“语义查询”问题：例如“找出所有智能体误解用户意图的轨迹”。传统方案只能按关键词或元数据过滤，而 AI 过滤器会调用模型对每条 trajectory 逐条打分或判断是否符合语义条件，再返回匹配结果。其代价是查询成本随数据量线性增长，因此通常配合粗粒度预过滤（时间、工具类型、错误码）缩小候选集。这种“用模型查询模型产生的数据”的模式，是把非结构化交互日志转化为可检索资产的关键一步。

trajectory 与 trace 的区别：trace 是原始事件序列（模型调用、工具调用、输入输出），trajectory 则是经过标准化和富化的视图，通常补充了任务目标、最终结果、奖励或评估标签，便于训练和评估直接消费。把原始 trace 加工为 trajectory，本身就是一个需要领域知识的数据工程环节。

Evals：AI时代的产品需求文档

LangChain用一句话概括evals的地位："evals是新的PRD。"在AI领域边缘案例过多，最能描述"什么是好"的方式往往就是评估集本身——包括应该响应什么、不应响应什么。构建evals的难点有三：想不出真实输入（用户提问常出乎意料，因此trace至关重要）、定义好答案的标准（精确匹配、正负标准、工具调用顺序、环境最终状态）、以及搭建模拟环境避免评估冲击生产系统。

发现错误同样分层：查看生产trace依赖问题已经发生，领域专家手动测试成本高昂。LangChain推出的红队测试则试图主动发现问题，例如发送语义相似的两个查询，若回应语义不同则说明其中一个有误，以此锚定正确答案。这类方法无法在智能体运行时实时进行，但提供了参考点。

模拟环境（simulation environment） 在评估智能体时不可或缺，因为智能体的动作会改变外部状态（写数据库、发邮件、调用付费 API）。若直接在评估中调用真实系统，既可能污染生产数据，也导致评估不可重复。模拟环境提供沙箱化的工具实现和可重置的初始状态，使同一评估用例可以反复运行并比较结果。难点在于模拟器要足够真实以反映真实失败模式，又要足够轻量以支持高频回归测试。常见做法是录制真实工具响应做回放，或为关键依赖编写带状态机的 mock。

改进飞轮与北极星

把上述环节串起来，就是一个高层抽象：运行智能体→获取反馈（人类或评审员）→深入trace→转化为evals数据点→提出修改（模型权重、harness代码或上下文）→验证提升且不回退。这个飞轮的终极形态是智能体自己发现错误、创建评估点、提出并生成修复方案——LangChain坦言这仍是一个充满细节的北极星愿景，但正是它指引着当下的工程投入。

对于正在构建智能体的团队而言，这次分享的实际价值在于提供了一个可操作的检查清单：你的模型选型是否匹配任务复杂度？harness是否具备执行环境、上下文管理和人在回路能力？上下文层是否在持续沉淀而非一次性注入？trace和evals是否构成了改进闭环的数据底座？这四个问题的答案，基本决定了一个智能体能否走出"一次性交付"，走向持续进化。