在当前AI技术快速演进的背景下，使用同一大模型的情况下，不同企业构建的agent功能与应用效果差异显著，且差距随时间呈现扩大趋势。这一差异的核心根源在于agent运行系统与模型本身无关，更多依赖于围绕模型构建的系统体系。究其本质，拥有自主可控的agent系统，关键在于构建涵盖工具、治理、上下文与基础设施的完整体系，将行业知识掌握在自己手中，从而实现对agent的有效管控，这才是决定agent应用成败的核心关键。
--91likeyou---
差别出在哪里，LangChain 的联合创始人兼 CEO Harrison Chase 在伦敦的 Interrupt 大会开场时，用一整场的时间回答了这个问题。他的答案很直接：模型只是中间那一块，让 agent 真正管用的，是围在它外面的整个系统。这个系统里装的是你自己的行业知识，所以他认为每家公司都应该把它握在自己手里，也就是他反复强调的 own your in。
下面我顺着这条线，把他讲的内容重新理了一遍：为什么要拥有，拥有的到底是什么，怎样才算拥有，以及 LangChain 为此做了哪些东西。
同一个模型，agent 有的能上线有的不能，差别在模型外面
先看这几年是怎么走过来的。2023 年 LangChain 刚起步，大家做的是 agent 原型，什么都新，什么都在试。2024 年，应用开始上线，但都比较简单，一次模型调用，几次调用串起来，或者一个聊天机器人。2025 年，人们才第一次认真探索 agent。到了今年，agent 在应用层真正活了过来，各个垂直行业都有人在做。
这些 agent 有一个共同点。中间当然是大模型（LLM），可让它们能用的，是模型周围的那一圈东西，包括技能、工具、上下文、各种控制和治理。Harrison 举了三家公司。monday.com 搭了一套靠评测（eval，用来衡量 agent 答得好不好）不断反馈的循环，一点点把 agent 改好。Harvey 针对专门的任务微调模型，所以它靠的也不只是模型，还有一整套微调的体系。Orange 做了一个专用的 harness（包在模型外面的运行框架，决定模型能用什么工具、按什么规则干活），里面带着治理。
这三个例子放在一起，我看到的是同一件事：换成哪个模型，在它们的故事里都不是重点。每家公司都在模型外面加了自己才有的东西，有的是评测标准，有的是微调数据，有的是权限规则。这些东西别人拿不走，也抄不来，因为它们来自公司对自己业务的了解。既然差别出在这一层，接下来的问题就是，这一层应该归谁。
拥有自己的智能，是把通用模型变成自己行业的专家
Harrison 对 own your in 的解释很具体。你拿到一个通用的模型，围着它搭一套系统，让它在你熟悉的领域里真的好用。这个从通用变成专用的过程，就是专业化，发生在三个地方：模型层、harness 层、上下文层。把这三层的专业化握在自己手里，在他看来就是拥有自己的智能。
他看到三个趋势在推着大家往这个方向走。第一是成本。AI 工具被用得越来越多，费用跟着涨，如果整个 agent 系统不在自己的控制之下，费用很容易失控。第二是开放模型越来越多，NVIDIA、Kimi、DeepSeek 都放出了性能不错的开放权重模型，用起来更便宜，还可以在上面继续训练，让它更专。第三是数据的作用，他认为这是最大的推动力：你带来的数据、上下文和知识，决定了一个垂直产品和直接去用 ChatGPT 或 Claude 有什么不同。
我认为这里最容易被误会的，是“拥有”两个字。听上去像是每家公司都要自己训练一个模型，其实不是。Harrison 讲的拥有，是你能决定用哪个模型、规则怎么执行、哪些知识放进去，而且这些决定不会被某一家供应商限制住。训练模型只是其中一种做法，更多公司真正拥有的，是自己那一套评测标准和工作方式。这样想，门槛就没有那么高了，也更接近他的判断：每家公司都应该做到。
那具体怎样才算拥有，他给了三条标准。
怎样才算真正拥有，要同时做到开放、会积累、管得住
第一条是开放，对象有三样：模型、harness 和上下文。模型开放，指的不只是用开放权重的模型，更是可以自由选择，哪个最好、最快、最便宜、最适合你的领域，就用哪个。harness 要开放，也要能控制，因为让通用模型按你的方式做事，靠的就是在 harness 里设规则，如果它调不动，这些规则就设不进去，开源是做到可控的一个好办法。上下文可以来自任何地方，已有的数据源、各种接口、慢慢攒下来的记忆，harness 要能接得上所有这些来源。
第二条是会积累。第一版 agent 做出来不难，但它几乎不可能直接面对几百万用户。所以 agent 的能力要随着时间越变越强，可以靠人用观测工具发现问题再去改，也可以靠记忆让它自己攒经验。第三条是管得住，这对公司内部的 agent 尤其重要：它代表谁在做事，每跑一次花多少钱，现在到底发生了什么，这些都得有答案。Harrison 认为 agent 会大幅改变公司的运转方式，正因为如此，治理必须跟上。
这三条里，我觉得最容易被低估的是第二条。开放和治理，都是搭好一次就能立住的结构，会积累却是一个持续的过程，需要有人每天去看、去改。至于这个过程要怎么组织，他接下来讲到了人、流程和技术三件事。
做这件事要人、流程和技术一起动，最关键的是转得快的循环
想让公司往这个方向走，没有哪一件事能单独做成。先说人，他认为需要三圈人。最里面是核心的生成式 AI 平台团队，他们是 agent 专家，负责把技术搭起来，也常常定好流程给其他人用。中间是各个业务部门的 agent 工程师，把这些技术落到具体的场景里。最外面是不写代码的人。Harrison 特别强调这一圈，因为在一个领域里什么叫做得好，什么叫做得不好，往往是他们最清楚。
流程的核心是迭代。团队做出一个版本，很快测试，很快发给一小批用户，盯着它的表现，再把学到的东西带回去改。他把这个反复转起来的循环叫 flywheel（飞轮），并且认为交付 agent 做得最好的团队，都是把这个循环转得最快的。技术则分成三层：运行时，也就是怎么搭建、怎么部署 agent；观测与评测，让你看见 agent 在做什么、做得好不好；以及最近新加的一层，智能，让 agent 帮着做一部分原本要人来做的改进工作。
这个分法有一个好处，它把“谁来做”和“做什么”对上了。领域专家定义好坏，工程师把好坏写成代码，平台团队保证底下稳。LangChain 在这三层技术上各做了什么，我先从最底下的运行时说起。
agent 要从自己的电脑搬到云端，运行这一层得有人替你搭好
Harrison 把一个 agent 看成三层叠起来：最上面是业务逻辑，中间是 harness，最下面是基础设施。业务逻辑包括指令、工具、技能，还有用来修改 harness 的钩子，这是 LangChain 永远给不了的，只有懂行的人才写得出来。harness 则是模型周围所有把它接到外部数据、计算、上下文和业务逻辑上的东西。
这一层，LangChain 做了一个开源框架叫 Deep Agents，是他们最近推出的，目标是给你一个扎实的基础 harness，方便你修改，也方便往上搭。里面已经带着执行环境，可以是文件系统，可以是完整的沙箱（让 agent 写代码、跑代码的隔离环境），也可以是轻量的代码解释器。上下文管理按公认的好做法来做：支持技能和记忆，对话太长时自动做摘要，特别大的工具结果存到外面，整体结构也考虑了提示词缓存，能省钱，也能省时间。此外还有人工审批的环节，以及规划和子 agent，可以临时拉起一些小 agent 去做具体的事。
再往下是基础设施，也是 Harrison 对未来最明确的一个判断：agent 不会只在你的笔记本上给你一个人用，而是在云端的后台一直运行，主动干活，同时服务很多用户。从本地搬到云端，需要一整套东西，运行 agent 的服务器，安全接入各种工具并管好权限的方式，写代码和执行代码的沙箱，以及控制它能访问哪些模型的网关。LangSmith 里这些都有：部署服务带流式输出、密钥存储和断点保存；工具服务用 MCP 协议（让 agent 连接外部工具的通用协议），处理认证并留下审计记录；沙箱里有一个密钥代理，凭证不会进到沙箱，agent 自己也看不到；模型网关负责故障切换和费用上限。
让每个团队自己挑四五个组件拼起来，还是太慢。所以他们把 harness 和托管的基础设施合成了一个东西，叫 Managed Deep Agents（托管版 Deep Agents）。你只需要写自己的业务逻辑，剩下的都包在里面。
这里面有三处是他特别强调的。一是内置的东西多，agent 被谁触发（Slack、Teams、新邮件、GitHub 的新事件），要接哪些工具，对应的认证怎么做，都有现成的集成。二是部署很简单，一条命令 mda deploy 就能放到云端，而且他们让 agent 在沙箱外面运行，把沙箱当成一个工具来连，在他们看来这比把 agent 整个放进沙箱更合适。三是方便治理：agent 以谁的身份行动，可能是它自己，也可能是正在使用它的人；有什么权限，能调用哪些工具、哪些模型，最多花多少钱，进来的数据怎么保护，追踪和评测也都在里面。
他还展示了 LangChain 自己用的两个 agent。Open SWE 是编程 agent，不只写代码，还负责审代码、排查故障，以后还会做测试，已经开源。GTM Agent（市场与销售 agent）暂时没有开源，支撑着市场、销售和外联的很多工作，一直在线，还会主动找人，比如提醒 Harrison 当天有个大会。它能做调研、做外联，也能在沙箱里生成成果物，再给出可以直接打开的链接。这类深度接入业务上下文的内部 agent，在我看来，正好把前面说的“管得住”落到了具体的工作里。
agent 的运行记录是一种新数据，评判和存放都要重新想
agent 能跑起来之后，积累的前提是看得见。Harrison 认为，agent 的 trace（运行轨迹，记录 agent 每一步做了什么）是一种新的数据：层层嵌套，单条内容很大，查询方式和以前不同，还夹着多种形式的内容。它的价值也不一样，里面是自然语言，装着用户的意图、逻辑上的失误，以及人们到底在怎么用这个 agent，用对了还是用错了。
LangSmith 就是围绕这种数据做的平台，核心是他们自己做的数据库 SmithDB。他把和普通日志的不同分成四个方面来讲，写入、存放、查询、查看，我也按这个顺序说。
先看写入。轨迹里有很多自然语言的线索，可以用模型或者代码做在线评测，来判断系统表现得怎么样。以前这种评判多半交给最强的大模型，最近出现了 Jev 这样的决策模型，便宜也高效得多。它不生成文字，只做选择：你把状态交给它，再给一组问题和每个问题的候选答案，它从里面挑。所以又快又省。LangSmith 现在可以把 Jev 当评委用，有直观的标准答案类型，可以自定义选项，也可以给不同选项打不同的分。我认为这个思路对的地方在于，评判成千上万条记录这件事，本来就不需要一个能写长文章的大模型，需要的是稳定、快、成本低。
再看存放。agent 的轨迹里有大量敏感数据，这是它和普通日志最大的不同。所以 SmithDB 的部署方式很灵活，可以在云上，可以在自己的机房里，也可以用新推出的 BYOC（自带云）模式，数据全部留在你这边，控制面由 LangChain 管。最近还加了一个按角色控制的权限（RBAC），可以单独管理谁能看到输入和输出。工程师能看到一条轨迹的骨架，调用了哪些工具、用了多少 token（模型处理文字的计量单位）、延迟多少，能了解系统整体是否健康，但看不到里面的内容，因为敏感信息就在那里。接下来还会有更细的按属性控制的权限（ABAC）：给轨迹打上元数据标签，再设置策略，只有特定的人才能看特定的轨迹。Harrison 也承认，这类权限通常不会让人兴奋，但要处理这么多敏感信息，它是绕不开的。
存放的格式也有新做法，叫 LangSmith Trajectories（轨迹视图）。它把轨迹默认显示成一串消息的样子，需要时仍然能点进去看全部原始细节。格式统一了，排查起来更快，领域专家也更容易进来看和标注，而且这个格式和模型后训练用的格式很接近，将来拿去训练也方便。
在一大堆记录里找出奇怪的用法，再按公司自己的方式看
数据存好了，接下来是怎么查。大多数人用 agent 的方式都很普通，但总有少数人用得很奇怪，要把这些找出来，靠传统日志是找不到的，因为出错的地方不会留在日志里，只会留在语义里。LangSmith 已经有全文搜索，也能按元数据和大块内容做筛选，Harrison 最期待的是新做的 AI Search（智能搜索）。
用法是直接输入一句话，比如“用户被 agent 的回答弄糊涂了”。后台会一边返回结果，一边实时交给决策模型判断，给出每条记录符合这句话的信心程度，还会在记录里把有证据的地方标出来。他特别说明，这不是把一句话转成结构化查询，而是把这句话当作提示词，直接在所有结果上跑一遍，同时可以和别的筛选条件配合。
最后是查看。因为 agent 在很多领域里工作，不同领域想看数据的方式也不一样。所以 LangSmith 推出了 Custom Apps（自定义应用）：你可以用自然语言对着一个编辑界面提要求，后台有一个 agent 去翻文件、改界面，生成一个完全自定义的 HTML 前端，保存成整个组织都能用的视图。法律团队有法律团队的看法，财务团队有财务团队的看法，大家本来就会自己跟 AI 说几句话，让它写出界面（俗称 vibe coding），Harrison 的想法是把它放进 LangSmith 里，让这件事在被管理的前提下发生。LangSmith 的设计系统也已经开源，生成的页面风格会保持一致。
这样看，从写入到查看，LangSmith 想做的都是同一件事：让 agent 留下的这批新数据，能被快速、安全、按各家的需要读懂。读懂以后呢，还得有人去改。
看见问题只是第一步，Engine 要做的是接着去修
Harrison 认为，能看到轨迹现在已经是基本要求了，难的是后面几步：从一大堆记录里找出问题，看懂问题，再把问题修好。问题要修好，首先得知道错在提示词、上下文、模型还是检索；修完之后，还要避免同一个问题反复出现：这次修好了，两个月后因为改了别处的提示词，它又冒出来。
手动做，就是转前面说的那个循环。LangChain 几个月前推出了 LangSmith Engine，想用更自动的方式做这件事。Engine 是一个主动的 agent 工程师，在后台跑在轨迹之上，监控问题，把问题归类并诊断，再通过 PR（代码合并请求）提出修复。它还会生成新的测试数据和评测，如果接着部署服务，还能触发一次部署。大约一周前上线的 Engine v2，加了几项新能力。
第一项是主动验证自己的修复。这只在用 LangSmith Deployments 时可用：Engine 改完之后，会拉起一个预览部署，在上面重新测试之前发现的问题还会不会出现，这样就能拿出证据，说明修复确实有效。第二项是红队测试，也就是主动攻击自己的 agent。这和前面不同，它不只是看轨迹，而是自己想出新的探测方法，发给系统，看它怎么反应，按几种不同的策略找问题。找到之后会列出发送的提示词、实际的输出、本来应该有的输出，评判的理由和下一步建议，还可以点进去看对应的轨迹，证明这些问题真的会发生。
还有一项是今天刚发布的，我觉得最有意思。Harrison 观察到，agent 在运行的时候，往往自己就知道哪里不对，与其以后再重新发现，不如让它当场说出来。所以他们给 agent 加了一个自我报告的工具，agent 在运行中遇到问题，可以调用它，附上遇到了什么和它认为哪里出了错，这条记录会挂在对应的轨迹上，当晚 Engine 运行时就会读到。事后从外面分析，和当事人当场记下，是两种不同的信息，当场记下的这一条，是事后分析拿不到的。
他同时说 Engine 更便宜、更快，找修复和修问题的能力也更强，并且用编程基准做过测试。自托管的客户也可以在最新的 v7 版本里使用自带密钥。到目前为止，Engine 已经扫描了超过 7000 万条轨迹，发现了超过 2.1 万个问题，很多增长最快的公司都在用。在 Harrison 看来，团队做 agent 的速度，基本上就受限于这个循环转得有多快，这正是 Engine 想要缩短的部分。
我自己的一点思考
把整场内容连起来看，我觉得 Harrison 其实只在讲一件事。运行时、数据平台、Engine，是三个产品，也是同一条线上的三段：先让 agent 跑在你能控制的地方，再让它留下的记录能被读懂，最后让这些记录自动变成改进。三段加起来，就是他说的开放、会积累、管得住。
我认为这条线最有价值的地方，是它把一个很容易含糊的问题问清楚了。很多公司在问用哪个模型，Harrison 要大家问的是另一个问题：我对自己业务的了解，现在放在哪里？是在别人的提示词里，在一个换了版本就失效的配置里，还是在我自己的评测、我自己的 harness、我自己的数据里？放在前者，模型一换就要重来；放在后者，模型换成谁，都是你的。
当然，这是 LangChain 自己的一套做法，用不用它的工具是另一回事。可那三条标准，任何一家要把 agent 放进生产的公司，都绕不开。agent 能越用越好，靠的是每一次出错都有人记下来、改掉，和模型本身有没有变聪明关系不大。
模型可以换，你对自己行业的了解换不掉，把它握在自己手里。
题图来自Unsplash，基于 CC0 协议
🔥 热词：#agent与模型的区别 · #agent和模型的关系 · #agent模型用什么搭建 · #agent换模型会有影响吗 · #agent模型有哪些 · #agent换模型再换回来能恢复吗 · #agent和大模型谁的前景发展更好 · #agent和模型