AI Agent 的未来：Interrupt 2027 会聊什么？—— LangChain 闭幕 Keynote + LangSmith Fleet 发布
Interrupt 26 的闭幕主题演讲。Harrison Chase 开场先自嘲：这是他参加过最酷的技术大会，“而这跟我没有半点关系”——随即致谢幕后团队 Jess、Julia、Jacob、Brianna。他给整场演讲立了一个设定：假装我们已经站在一年后的 Interrupt 2027，回望今天——届时行业会在讨论哪些话题？他先给自己打了预防针：“我会在很多地方猜错，这听起来会很傻很蠢，但希望能让你窥见我们眼中这个行业的走向。“他还交代了两天的分工：昨天整场大会聊的是「今天怎么把 agent 做进生产」，今天这场收官聊未来——「未来的 agent 长什么样」这个问题，本就写进了 LangChain 的 mission 与 vision。前半场是七个前瞻判断；后半场由团队接棒，发布并现场演示了让任何人用自然语言造 agent 的 LangSmith Fleet。
一 · agent 会分化成两类
第一个判断关于 agent 的形态：人们构建的 agent 会分化成两类，而且这个分化已经开始显现。
一类是长时程（long horizon）agent。它们运行数分钟、数小时，未来甚至可能运行数天。它们做代码执行、做规划，会用 sub-agent、multi-agent 系统和 skills，运行的时间跨度越拉越长——outcomes（结果）和 goals（目标）正在成为拉长时程的方式。Harrison 预计这一类会迎来大发展，承担越来越有价值的知识工作。
另一类完全不同：延迟敏感型 agent。对它们来说 latency 是决定性因素。这类 agent 通常长成客户体验类 agent（customer experience agents）——客服、销售，凡是直接和终端用户对话的场景。在这里品牌（brand）很重要，语音成为很有意思的模态，未来视频也可能加入。
两类 agent 底下有一套共享栈（shared stack），但技术上也各有差异。他认为未来一年要想清楚的一个大问题是：这套共享栈到底有多通用，而每一类各自需要的技术部件又有多特殊。
二 · 语音：三明治管线还是原生 voice-to-voice
第二个判断顺着客户体验类 agent 往下走：一年后大家会花多得多的时间谈语音。LangChain 自己正在加大这方面的投入，因为语音对客户体验类 agent 尤其相关，是一个很好的模态。
今天典型的语音管线是一个「三明治」。用户说话，speech-to-text 把语音转成文字，文字交给一个在文本空间里工作的 agent；agent 输出文字，再由 text-to-speech 转回语音，播给用户听。这就是当下主流的 pipeline 方案。
但原生的 speech-to-speech 语音模型正在出现，OpenAI 大约两周前刚发布了他们的 V2。当下的共识是：**对那些真正在意可控性的应用，这些原生模型还不够 steerable（可引导），但预期这一点会改变。**于是语音 agent 的大问题就变成：走 pipeline 方案，走原生 voice-to-voice 方案，还是两者结合？各自的利弊是什么？这会是未来一年语音讨论的主轴。
三 · 所有 agent 都需要 sandbox
第三个判断只有一句话，但适用面很宽：所有 agent 都需要一个 sandbox，长时程 agent 尤其如此。
理由在于「写代码」这个能力的通用性。coding 对很多任务都很好用——不只是写软件，还包括数据分析、网页浏览、图像生成、deep research。
那「给 agent 写代码的能力」到底意味着什么？他转述了昨天一位与会者的视角：为营销团队造 agent 时，可以想象成给这个营销团队配一个软件工程师——那个工程师会造什么？会做哪些 app 来让营销团队的活更轻松？给 agent 写和执行代码的能力，就是这个意思。
这正是 LangChain 昨天发布 sandboxes 的原因。他对进度的判断很克制：agent 本身还很早期，sandbox 更是极早期，只是黎明而已——但未来一年它会被大量讨论。
四 · 开源模型：性能逼近、成本压力、领域训练
第四个判断给开源模型：**未来一年开源模型的使用会显著增长。**他给了三个理由。
第一，性能在逼近前沿。这些未经任何针对性 post-training 的开源基座模型，性能已经接近前沿闭源模型。LangChain 在 Deep Agents 上做过 benchmark，拿闭源前沿模型和开源模型对比：开源在某些地方仍落后，但已经非常非常接近前沿。
第二，成本正在成为越来越大的问题。多个案例里 token 烧得极快，coding agent 尤其如此。开源模型提供了便宜的替代，这会是其增长的一大驱动力。
第三，开源模型可以为你的特定领域训练。随着企业积累起大量 trace、大量 agent 运行记录，这些数据可以用来随时间改进模型——这种 post-training 正是开源模型能做的事。这一条和后面的持续学习直接相关，他在此按下不表，留到后文展开。
五 · Agent 身份：它以谁的名义行动
第五个判断关于一个还很早期、但 LangChain 觉得非常有意思的问题。随着 agent 在真实世界里做越来越多的事、真正采取行动，就绕不开两问：它如何行动？以谁的名义行动？目前能看到两种趋势。
一种是代表个体用户行动。agent 用你的凭证：他举例说，如果一个 agent 有 Slack 权限，我让它去 Slack 查东西，它用的就是我的凭证，能看到的就是我在 Slack 里能看到的一切。换一位同事（比如 Julia）来用同一个 agent，可能得到不同的答案——因为它看到的东西不同。
另一种是固定凭证集（fixed credentials），通常是一个 service account。无论谁与这个 agent 交互，它都用同一套凭证，所有人看到相同的响应。这种模式随着 OpenAI 的一个概念流行起来：agent 是个独立个体，有自己的固定凭证，通过独立渠道暴露出来供人交互。甚至已经有 SaaS 提供方专门让 agent 能轻松自行创建账号，好拥有自己的固定凭证——他觉得这会是一个值得关注的趋势。
他的判断是两者都会存在：既有代表用户行动的 agent，也有持有自己凭证的 agent。真正重要的是精确界定「何时该用哪一种、眼前这个是哪一种」，并把这件事向用户讲清楚。
六 · 持续学习：三层都能改，evals 是梯度
第六个判断是 LangChain 作为一家公司最兴奋的方向之一：持续学习（continual learning），也就是让 agentic 系统随时间改进。要理解它，先要把 agentic 系统拆成三层——每一层都可以被改进。
三层分别是：模型层（model layer），指 Sonnet、GLM、GPT 这类基座模型；harness 层，指连接模型与环境的那层代码，比如 Deep Agents、Claude Code；context 层，指提供给 harness、用来在具体任务上引导它的东西，比如 agent.md 和 skills。他用 Claude Code 说明了后两层的关系：“你不能直接改 Claude Code，但你可以给它 skills、给它 agent.md，把它针对你的任务调好。”
模型层的改进已有实例。Ramp 与 Prime Intellect 上周发布的研究里，他们把一个模型微调到极擅长处理 “Ramp sheets”，延迟极低、准确率极高。用的是开源模型 Qwen 3.5，针对自己的特定领域微调——这就是模型层持续学习的样子，也印证了前面开源模型的第三条理由。
harness 层同样可以学。MIT 与 Stanford 的论文 MetaHarness 用一个 agent 去优化一个 coding harness，在 Terminal-Bench 2 上做优化，结果胜过人工编写的 harness。关键在于它完全不改模型，只编辑 harness：把环境反馈（在 Terminal-Bench 上跑出来的结果）喂给一个专门负责编辑 harness 的 agentic 系统。
这套玩法为什么成立？Harrison 自己的背景是经典机器学习，他用一个类比来解释数据在新旧两个世界里的相似用法。经典 ML 的循环是「模型 + 训练数据 + 梯度下降 → 更新权重」；而在 harness 或 context 层更新 agent 时，虽然不是梯度下降，但你写的 evals 充当了「强制函数（forcing function）」。回到 MetaHarness 的例子：agent 跑 Terminal-Bench 2 拿到反馈，反馈再进入负责更新 harness 的 agentic 系统，evals 就这样提供了类似训练梯度的作用。所以 evals 和 traces 对这种学习极其重要。
LangChain 自己也验证过这条路：完全不动模型、只改 harness，就在 Terminal-Bench 2 上从 top 30 升到 top 5，性能大幅提升。他补了一句，榜单变化飞快，这已是几个月前的数据。他预计会有越来越多公司在模型层、harness 层或 context 层，为自己的用例做这种持续学习。
LangChain 想帮大家做这件事，本场的第一个发布（发布①）由此而来：LangChain Labs——LangChain 内部一个专攻持续学习的研究团队。地基是现成的：LangSmith 里已经沉淀了大量 traces 和与之关联的反馈，无论在模型层、harness 层还是 context 层做持续学习，这都是坚实的起点。接下来他们期待与一批客户在这个方向上合作。
七 · 人人都会造 agent
最后一个判断关于「谁来造 agent」。今天已经能看到：组织里的每个人都在用反馈改进 agent——UX 研究、领域专家、客服、产品、工程师，都在以各种形式参与，或是直接给反馈，或是调 prompt，或干脆在 Slack 里 debug。
而往往是领域专家本人，拥有最好的反馈、最懂 agent 该如何表现。由此他的判断是：**未来领域专家不只是给反馈、再交给另一个团队去改，而是会亲自构建自己的 agent。**LangChain 内部已经出现雏形：过去几个月里，各种不同领域、不同专长的人都造出了自己的 agent。为了讲清这个未来如何在 LangChain 内部成真，他把舞台交给了 Fleet 团队（Brace 讲解，Caroline di Vittorio 随后演示）。
八 · 发布②：LangSmith Fleet——让任何人用自然语言造 agent
Fleet 部分回答的问题是：不写代码的人，怎么造出真的能用的 agent？Brace 的开场白点明分工——Harrison 描绘了 agent 进入工作场景的未来，他来讲 LangChain 今天已经怎么在做了。
先看内部用例。LangChain 的 agent 已经铺到各个团队：人才招聘团队用 sourcing agent 寻访候选人；销售团队用 go-to-market agent 自动化外联和客户情报；营销团队用 Intel bot 研究竞争格局；工程团队用 OpenSuite 自动分诊并修复故障（incident）；放眼全公司，agent 持续运行、监控业务，并在 Slack 里给出实时更新。这些 agent 的共同点是：全部由实际使用它们的团队成员构建，没写一行代码。靠的就是 LangSmith Fleet——一个托管式 agent builder，让任何人只用自然语言就能造 agent。
三年造 agent 的三条经验
Fleet 的设计对应 LangChain 三年造 agent 攒下的三条经验。
经验一：**最适合造 agent 的人，是真正在做那份工作的人。**道理很直接：归根结底，agent 不过是一组 instructions、skills 和 tools 的集合——还有谁比每天做这份工作的人更适合把它编码下来？而且就像人会随时间进步一样，Fleet agent 内建 memory，用得越多就越好用。
经验二：agent 必须能在你工作的地方工作、能访问你在用的同样系统。Fleet 通过 tools 和 channels 解决这件事：
- 内建 200+ 工具，覆盖企业最常见的集成；
- 与 Arcade 的一流合作，开箱再加 7,500 个工具，覆盖集成需求的长尾；
- 支持 MCP，可接入你的自定义工具和专有数据源；
- 原生集成进 Slack、Gmail、Outlook 等，不用学新工作流；同时有完整 UI，可在应用内构建、管理、运行 agent；
- 对开发者开放 Fleet API，可以直接在自己的生产应用里调用。
经验三：**agent 规模化之后，治理（governance）会成为瓶颈。**Fleet 把应对做成了产品能力：
- 协作：像分享一份 Google Doc 一样，直接分享和协作你的 agent 与 skills；
- 凭证与认证管理：连接你所有账号，并按「哪个用户在用」决定哪个 agent 用哪个账号——Brace 补了一句：“相信我，这真的很棘手”；
- 成本：agent 在内部被广泛采用后成本会飙升，所以内建成本追踪与用量控制，可精确查看每个 agent、每个用户花了多少，并设置 spend limits；
- Human in the Loop 是一等公民，可以放心地给 agent 强力工具；
- 与 LangSmith 平台其余部分原生集成，可以看 agent traces，了解 Fleet agent 在底层如何运作；
- Fleet 是开放的：模型无关（开源或闭源模型皆可），构建在开源 agent harness——Deep Agents——之上，且可以把 agent 文件直接下载进你的代码，做任何你想做的修改。
现场 Demo：go-to-market agent
Caroline di Vittorio 现场演示的正是销售团队那个 go-to-market agent。它能基于 CRM、通话录音平台和数据仓库浮现客户情报，能研究客户与联系人，还能起草个性化外联邮件。为此团队把它接入了 LangChain 自己在用的工具——Salesforce、BigQuery、Slack、Gmail 等；为常见研究任务写了若干 sub-agent；又给了它一长串 skills，把那些每次都必须做对的常见任务写成分步指令；还接上了 Slack 频道，不进 UI、直接在 Slack 里 @gtmagent 就能调用。
演示的提问是：“我们和 Pied Piper 这个客户进展到哪了？下一步该怎么走？“agent 跑的这段时间，Caroline 顺带报了它的真实战绩：84% 的 go-to-market 团队成员每周都在用它；lead-to-qualified（线索到合格）转化率提升 240%；平均每位销售代表每月省下 40 小时。这个 agent 的来历本身就是 Fleet 故事的缩影：最初由一位工程师直接用代码搭建；Fleet 建成后，团队在 Fleet 里把它重建了一遍，于是 go-to-market 团队能端到端完全拥有它的实现，而无需写一行代码。
agent 跑完给出结论：Pied Piper 是一个 at-risk（有流失风险）账户，对定价有犹豫，建议通过邮件重新接触对方的 Jared。Caroline 当场让它起草邮件。这里正好落在 Brace 强调的 Human in the Loop 上：在把邮件真正发给一个潜在客户之前，agent 会先回来和人确认，让你复核文案；演示中她顺手让它「把 LangGraph 的大小写改正确」，确认无误后才发出。
像这样每天在用的 agent，很多已经作为预置 agent 直接放进了 Fleet。除了刚演示的 go-to-market agent，还有 software engineer agent：在 Slack 里 @ 它，它会在 sandbox 里写代码，然后给你提一个 PR 等你 merge。用起来只需三步：创建 agent，接上你组织在用的工具，再走一段简短的 onboarding 让它了解你的公司，就能用了。
演示结束，Harrison 回到台上收束全场。Fleet 今天就能试，他自己也在用它做各种任务。团队还临时加了一个限时的免费模型——由合作伙伴 Fireworks 驱动的开源模型。他点明这个选择的用意：践行自己宣讲的开源理念，也体现他们拥有最好的合作伙伴。会场展位有一个很棒的生态，他鼓励大家去交流。Interrupt 26 的主题演讲到此结束。
术语校正记录：①字幕轨开场作 “at LinkedIn”，按语境校正为 LangChain（讲的是自家的 mission 与 vision）；②模型层例子字幕作 “Sonnet, GLM4, GPT-4”，版本号存疑，正文模糊化为 Sonnet、GLM、GPT；③harness 例子字幕在 Deep Agents、Claude Code 之后还列了一个 “pi”，所指无法核实，按「宁可省一句，不猜一句」省去；④”SAS providers” 归位为 SaaS providers；⑤”customer support pokes” 归位为 customer support folks（客服）；⑥字幕中 Harrison 报幕请上的是 Caroline di Vittorio，但先讲解的是 Brace、随后 Caroline 做 demo，frontmatter 按实际发言顺序记录分工。