VS Code 已成为现代软件开发领域最具影响力的工具之一。而随着 AI 辅助编程时代的来临，VS Code 也开始引领软件编写方式的深刻变革。
行业巨变的当下，编程的本质也正在快速转变，开发者与工具的交互方式已经发生明显变化：AI 不再只是提供代码补全，而是逐渐参与到开发流程的更多环节中。从最早的代码补全实验，到 ChatGPT 出现后引发的新一轮界面设计与交互探索，VS Code 团队也在不断调整编辑器的设计思路。作为微软 VS Code 团队的工程经理，Kai Maetzel 见证并参与了这一转变的全过程。
在本期 Software Engineering Daily 播客中，Kai Maetzel 与主持人 Kevin Ball 回顾了 VS Code 的发展历程，并分享了团队在 AI 编程、智能体开发以及开发者工具设计方面的实践与思考。例如，如何在代码补全中平衡提示频率与开发者体验，如何设计能够与 IDE 深度协作的智能体，以及在智能体开发逐渐兴起的背景下，开发工具可能出现的演进方向。
以下为完整的访谈内容，经 InfoQ 翻译并进行了不改变原意的编辑：
主持人（Kevin Ball，现任 Mento 工程副总裁）：Kai，欢迎参加本期节目。咱们就从你的背景经历说起吧，包括你领导 VS Code 团队的整个历程。
Kai Maetzel： 其实我的职业生涯起步很早。我的第一份实习工作就在 DevTools 开发工具部门，之后也一直深耕于此。十年前我加入微软时，正是看中了 VS Code 项目的发展潜力——当时团队就预见到，它一定能在市场上引发轰动。从零起步到现在，我们的用户群体已达 4400 万。
主持人：记得 VS Code 刚推出那会，我还想着“怎么又来了款 IDE？”结果它最终席卷了整个市场。
Kai Maetzel： 这么想也正常，这可是个根深蒂固的市场—— 编辑器历史悠久，IDE 多种多样。但我们所有人似乎又都很纠结，总觉得已有的编辑器不够让人满意。比如“这个功能用这个做超级快，那个功能用那个做效果不错，麻烦的是启动太慢，界面又太花哨"等等，反正是各有问题。我们真正要做的就是寻找中间的黄金平衡点。
也就是说，我们面对的实质上是这样一个问题：一端是轻量化编辑器，另一端则是功能完备的集成开发环境。二者中间的平衡点在哪里？这正是我们努力探索的方向，好在 VS Code 确实精准命中了靶心。
AI 补全如何改变代码编辑体验
主持人：一点没错，而且你们已经领先了一段时间。但如今科技行业正经历剧变，编写代码的本质似乎正在快速转变。我特别想深入探讨你们对此的思考路径。初步将 Copilot 引入 VS Code 肯定只是起点。那么 VS Code 究竟经历了怎样的旅程，才引领我们进入这个智能编码的新世界？
Kai Maetzel： 当人们回顾历程时，很容易忘记一路走来自己的认知和心境发生了哪些变化。短短六个月之前我们对于编程本质的认识，跟当下相比已经天差地别。前几天跟其他人交谈时，对方提到“60 天前”，结果我震惊地回应说“啊？我以为那已经是大半年前的事了。”一切都发展得太快了，感觉时间都被压缩了似的。
首先向大家交代相关背景：最初我们 VS Code 团队是和 GitHub Next 团队合作的。GitHub Next 本质上属于内部研究部门，他们和 OpenAI 关系密切——AI 智能感知建议功能就是由此诞生的。
其他领域对 AI 的应用早有尝试，所以我们做的也不完全是新鲜事。比如把同类功能集成在代码辅助之类的模块当中，加上一个星标来说明：“这部分是 AI 建议，其余部分则来自语言服务器等。”这是第一阶段的思路，但后来我们意识到必须改变这种模式，必须构建全新的用户界面。于是我们开始全力推进 Ghost Text 的开发。
我们很早就实现了多行代码补全功能，但很快发现无人使用——因为大家不想打断编码流程去审阅代码。于是我们决定倒退一步，转而追求“更精简的补全方案”。补全功能的整个演进历程基本就是这样推进。随后，ChatGPT 横空出世。
ChatGPT 发布后不久，我们就在 VS Code 团队内部发起了一场黑客马拉松，四天时间尽情用这些新模型和新方法打造我们认为可行的东西。这段经历非常有趣，也很快让我们明白：这种能力绝不能只是附加在工具边缘，它必须真正融入工具本身。
AI 必须渗透到每个细节。以 VS Code 的命令面板为例：当你输入内容时，优秀的 AI 应当智能解析真实意图而非字面含义，同时又必须在“用户坚持字面输入”与“避免过度猜测”之间找到平衡点。当然，此外还有性能考量。VS Code 的每个环节都突然变得至关重要，比如 AI 响应不够快等问题。但有一点已经非常明确，AI 必须成为核心体验的一部分。
对我们来说，后续的讨论也非常有趣。当时 GitHub Copilot 已是成熟品牌。VS Code 本身无需登录即可启动，但使用 GitHub 功能则需要登录。GitHub 早已具备计费体系等完整生态，更拥有成熟的品牌认知。该如何平衡扩展功能与核心功能的边界耗费了我们相当长的时间。
聊天功能也涉及诸多问题。不仅要考虑可用模型种类，更要评估这些模型的实际能力——例如能处理多少上下文窗口等。初创公司思考这些问题的方式，与成熟盈利企业的思路截然不同。
微软当然有自己的考量。例如我们花了很长时间才说服团队：“必须采用更大上下文窗口，4K 窗口根本无法高效工作。”初期面临的都是这类前所未有的挑战，对整个公司来讲都算相当陡峭的学习曲线了。
好在随着时间推移，我们逐渐摸索出方向。我们不敢说已经找到了终极正确的路线，但应该算是掌握了核心要义。回顾过去一年，我们推出了编辑功能，推出了名为 NES 的标签页切换模型。我们构建了智能体循环，将 GitHub Copilot 编码智能体等云智能体整合进来，现在还有 Copilot CLI。所有这些都被集成到 VS Code 界面中，通过智能体会话视图实现协同。目前我们正积极优化智能体会话视图，希望进一步完善其使用体验。
类似这样的变化可以说一刻不停。与此同时，竞争格局在转变，模型能力也是一日千里。现在最重要的不仅是能力本身，更涉及运行时长、响应速度——比如首次生成 token 的时间。在用户逐步掌握使用技巧的过程中，该如何在恰当时机采用最优模型组合？这是个动态性极强的领域。
主持人：确实如此。这里我想多聊几句，你提到从最初探索高级标签补全（AI 驱动而非仅依赖语言服务器）时，就必须权衡展示程度与开发者调整空间的关系。那该留多少空间让开发者自行修正方向？
我认为 AI 模型的精妙之处在于能构建意图驱动的界面——既能预判用户操作意图加速引导，又可能出现判断失误。因此我很好奇，随着你们逐步叠加这些功能（从聊天式编程到智能体编程等技术演进），要如何把握这个关键平衡点：“我们能为你做很多事，但如何确保每个环节都是正确的选择？”
Kai Maetzel： 首先得承认，这确实是个尚未解决的问题。没想到吧，这事儿现在还悬着呢。咱们以标签补全功能为例，比如 NES（下一条编辑建议），始终存在两个核心问题：应该向用户展示什么内容？应该以怎样的频率展示？用户实际采纳提示的概率又有多高？用户主动忽略提示的概率呢？这一切共同构成了操作空间。正如先前讨论的，我们得在编辑器与 IDE 之间寻找平衡点。
我们先确定思路的两个极端：一端是立即向用户展示模型提出的全部建议，此时接受率绝对值会持续攀升，但用户的烦扰感也会同步加剧。因此必须精确把握提示频率——到底要以怎样的频率向用户展示建议？其中用户未主动拒绝而默认接受建议的比例又是多少？要想精准把握这种显性接受与显性拒绝的平衡点，必须得持续进行精细调校。因为用户会逐渐形成预期——初次使用 NES 的用户与资深用户也将具有截然不同的认知。
用户的打字速度等因素也有影响。例如等待多长时间才显示建议？慢速打字者可能经常被模型建议打扰，而快速打字者则因建议迟迟不出现而焦躁——他们希望一气呵成地输入。只需按 Tab 键确认输入——因为他们能预判模型的预测结果。这需要持续优化。我们通过精细的仪表板追踪各项指标，反复调整参数后进行 5%用户测试，观察实际交互行为的变化。
增加显示内容是否带来正向/负向效果？用户按 Esc 键的频率如何？这些数据非常有趣。例如上次统计显示 Esc 键使用率仅约 3%，但询问用户时他们却坚称“我的 Esc 键都按冒烟了”——数据却证明事实并非如此。这确实非常耐人寻味。因为归根结底，开发者的幸福感至关重要。这种幸福感源于多重因素：你对生产力的感知、思维的流畅度、专注程度以及烦扰程度等。要真正实现这一点，需要持续不断的优化过程。
主持人：完全同意。作为资深 Vim 用户，我必须说一句：用 VS Code 的时候确实感觉总在按 Esc。
Kai Maetzel： 没错，感知跟现实就是会有错位。
主持人：有个疑问——你提到不同打字速度或经验水平会影响体验。那调整这些参数时，变化是面向全局的吗？你们有没有设计自适应系统？比如打字速度快的人能获得更快速的补全？具体如何实现？
Kai Maetzel： 目前主要还是全局设置。但我们正在研究如何将打字速度编码到模型输入中，使其能真正考虑这个因素。
主持人：明白了。实际应用的仍然是全局模型，但打字速度将成为基于用户特征开发的输入参数。很有意思。那么你提到的特征空间里，打字速度是否代表用户的新手程度，或是某种以特定方式编码的用户特征？
Kai Maetzel：我们目前还没找到能准确体现用户经验水平的好办法。工作区倒是个重要参考指标，但它未必能揭示用户是否初次接触该特定工作区。要建立完整的用户画像相当复杂，因为我们每个人在浏览不同仓库时都会经历不同阶段。比如打开 Rust 仓库时，我可能比浏览 TypeScript 仓库时速度更慢、更谨慎。在理想状态下，这些因素也应纳入我们的设计考量——虽然目前尚未实现，但我们正在思考这些方向。
从聊天式编程到智能体开发
主持人：除了编辑建议功能外，你们在探索基于聊天的开发模式乃至日益普及的智能助手循环开发模式时，在交互性方面又做了哪些权衡取舍？
Kai Maetzel：这么说吧，最初所有工具（包括我们自己的）的聊天界面都很精致。你看着它们会感叹：“哇，这功能真厉害！”但实际使用体验又达不到这份预期。
主持人：太对了，我用 AI 也有这种感觉。
Kai Maetzel： 我们耗费数年优化流程，比如将某项交互从 3 秒缩短到 2 秒。我们所做的一切，都是为了让用户保持流畅状态。但在进入聊天界面时，理想情况下回答生成也需要 20 秒，有时甚至可能耗费几分钟。
用户忍受这种延迟的唯一理由，就是最终结果要比自己操作更快更好。这就是甘愿承受些许折磨，只为换取更优结果。这正是我们开展此类聊天交互时的初始基准。但不知道大家有没有感觉到，现在的情况已经悄然改变了。
首先，我们拥有更快速的模型了，人们也发展出不同的交互模式。例如：一种模式是使用高速模型进行研究。你主动去尝试，通过交互摸索目标方向。在完成这种主动研究之后，我们已经大致明确了需求，能将其转化为合理的提示词，再交给后台智能体执行——这是第一种模式。
另一种思路，或者说行为模式则几乎与此相反：人们会说"不，我要运行多个探索性异步智能体。我只给出大致目标，具体方案由它们负责制定。"这种方式耗时较长，通常采用体量更大、速度较慢的模型生成方案。把初步成果稍作调整后，再切换到速度更快的实现模型。之所以这样做，是因为你深知 AI 无法全程精准执行，需要人工介入辅助。完成 90%之后，再手动处理剩余的 10%完全可行。毕竟从 92%推进到最后 8%的差异并不显著，正因为如此，人们才愿意接受不够精密的模型。
很明显，这两种工作模式截然不同：一种追求同步性、速度、探索与思考的全程掌控；另一种则采用交互式推进——先完成初步构思，再进行委托与复核。前者由于最初就已明确行动方向，后续复核时需要调整和变更的部分会更多。而另一种模式中，模型负责代理决策，我则协助执行，这使得整体复核工作量大幅减少——二者的差异颇为耐人寻味。
你提到的这种权衡确实存在——交互性与非交互性的取舍。我们实现了多种定制智能体模式：例如纯询问模式（仅执行指令而不作修改）、自定义编辑模式（可限定修改范围）以及智能体模式。我们正在探索一种新的交互模式，希望模型或智能体变得高度可控。当你要求“修改这个文件”时，它只会修改目标文件，而不会去修复其他五个文件导致编译错误——因为控制权完全掌握在你手中。
但关键在于，这种模式必须极其快速。我们已经在规划模式下发布了规划智能体。其中存在各种权衡取舍，且我们始终在持续学习。但这就像开发工具的传统困境——不同类型的开发者有不同需求和偏好，必须为每个人提供恰当的工具组合，让他们找到舒适的工作状态。
主持人：让我们深入探讨一下，你刚刚提到这些不同模式的可操控性存在明显差异，对吧？Sonnet 喜欢编辑所有文件，它就是喜欢交流，其他模型则不然。但你们在智能体框架中做了大量工作，特别是如何定义这些智能体。能不能再具体聊聊？编码工具可以说是当下最先进的智能体，那你们要如何构建？定义这类智能体（如询问智能体）的技术栈是什么？
Kai Maetzel： 这才是核心所在，而且我估计你已经听到过不少答案了。智能体循环其实没那么复杂。就像你给它一堆工具，再教它如何使用这些工具。大多数操作指南其实都包含在工具说明里，有时也会另行说明。每种模型都有特定倾向，分别对应不同的提示词指引。
比如有些模型需要你明确告知“请定期向用户更新进度”，而另一些模型在收到此类指令时会终止循环——Codex 就是典型案例，它在需要向用户更新时会主动停止。虽然存在这些差异，但大模型的核心原理始终如一。接下来你需要明确指导智能体。其中一个有趣的难题在于：任务到哪一步才算是完成？在哪个时间点可以判定任务结束？以上便是整个流程的基础框架。
当你调用自定义智能体时，我们允许你定义该智能体可使用的工具集。这些工具可能来自不同来源：VS Code 内置工具、用于定义工具的扩展程序，甚至可以安装 MCP 服务器，总之工具集相当庞大。
因此在自定义代理文件中，你可以明确指定必须提供的具体工具。之后就是我们惯用的受 Markdown 启发的语法。你可以通过它定义智能体的具体操作方式。很多人见过 Claude Skills 的实现形式，其实所有定义都具有高度可比性，这种特性很关键。它本质上是个 Markdown 文件，可引用其他指令文件来指定工具的使用规则和适用场景。
例如你可以这样写：“我已经在工作区里，说明我定义好了所有环境。我希望你使用测试运行工具，而不是手动执行 npm run tests 或 cargo test 之类的命令。” 有时候需要明确说明这些要求，但有时模型也会自行推断——比如假设你的测试用例有误。有趣的是，那是我第一次意识到模型竟能如此智能。它们几乎重写了测试用例来确保结果为真。虽然实现方式有些晦涩，但核心逻辑很明确：我当时开心得不得了，因为所有测试都顺利通过了。你也可以提出明确的要求，比如：绝不触碰测试文件，那边确定没问题。重构时或许需要调整，但断言本身不可更改。规则就是这么简单明了。
但实际投入大量工作后，我们又开始思考：“工具使用需要多少操作指引？需要提供多少指导？”整个评估体系需要在其中发挥关键作用——具体运行了哪些评估指标？运行多少次？运行频率如何？如何准确评估结果？整个过程跟其他领域截然不同。
比方说，我们会运行行业标准的 SWE 基准测试作为评估指标之一。我们不仅关注问题解决率——毕竟解决率只是从 A 到 B 的过程，这个过程可能极其混乱。我们关注的是从 A 到 B 的速度。你实际调用了多少工具？达到目标时消耗了多少 token？是否调用了我们认为应该用到的工具？
以终端工具为例：若作为后台智能体运行，你完全可以使用该工具完成任务，这无可厚非。但若在 VS Code 中作为前台智能体运行，用户期望在发现测试失败时，能直接在测试资源管理器中定位失败项并点击查看。此时就该启用该工具。若存在监视任务，就不该耗费大量轮次去推测如何构建名为“监视任务”的项目，因为肯定是要的。我们会在实际运行后对这类评估做对比。此外还有后续微调工作：词汇替换、工具分类归档等操作，这些细节也会切实影响最终效果，背后需要投入大量工作。
主持人：没错，这个看似简单的封装器内部其实暗藏玄机。我想深入探讨几个点。首先如你所说，不同模型间似乎存在倾向差异——比如调用工具的方式、与用户交互的频率等。我的界面只有个简单的模型切换器，实际操作完全不可见。你们是否针对不同模型定制工具描述、核心代理指令等细节，以确保行为一致性？具体实现机制是怎样的？
Kai Maetzel： 我们的项目有两种状态：当前运行状态和短期期望状态。毕竟我们是开源项目，你可以直接查看代码库。比如在 VS Code 运行时，我们的日志视图会完整记录模型调用过程，每个细节都清晰可见。你甚至能通过具体词汇进行验证——这在日常使用中就能体现。
当前阶段，我们为每个模型家族都设计了特定提示词，有时还会进一步精细化。有时我们会更细致地对模型版本进行说明。我们会严格区分 GPT5、GPT5 Codex、GPT5.1 Codex。由于迭代速度极快，我习惯称其为五代而非 5.1 版。但从行业角度看，不同模型在主提示词文件生成时确实存在差异。随后我们会根据具体模型选择适配的工具、补充额外指令等等。
我们还尝试定制工具描述之外的指令，只是目前尚未实现——我们还没有编码模型能明确指出“这种工具描述在特定模型中效果更佳”。但我们已经多次讨论过这个问题了，只是始终未能推进到“即将实现”的阶段。在最近的迭代计划中，我们再次提起这个话题，我强调：‘十二月初发布时应该可以做到’，即实现模型特异性工具描述——通过提示词文件覆盖默认设置，明确指示“当此工具出现时应采用该描述”。
智能体如何理解代码：上下文与工具
主持人：另一个细节是为智能体构建上下文的方式——比如在特定仓库环境中操作时，需要处理哪些元素。除了工具之外，还有人会预先注入不同长短的上下文信息。这可能不仅限于系统提示词，还包含大量附加内容。你认为应该如何正确地向智能体呈现信息，使其从一开始就朝着正确方向发展，而不是完全依赖按需调用工具？
Kai Maetzel： 这里有几个关键点，我就先从工具说起吧。如今大多数模型都是用特定工具集训练的，所以开箱即用就掌握了一套工具。比如 GPT 模型必须具备应用补丁功能，字符串模型则拥有字符串替换功能。这类基础工具是它们各自必备的。于是新的问题来了：在这些基础工具之外，模型的泛化表现能达到什么水平？
说到这里，工具的重要性已经非常明确了。同时我们还需考虑上下文：当前提示词在何种环境中执行？是前台智能体还是后台智能体？这是第一个问题，关注的是工具在提示词中如何具体呈现。再者，假设我们手头有若干 MCP 服务器。有些服务器仅配备一、两款工具，而另一些则搭载数十种工具。多数模型对提示词中能够容纳的工具数量存在限制——通常是 128 项。除此之外，还需要考虑实际投入的 token 数量。
对于那些使用频率极低或仅在特定场景下启用的工具，你愿意消耗多少 token？我们的解决方案是：将 MCP 服务器提供的所有工具进行虚拟分类，每个分类都作为独立工具存在。我们将这些工具交给模型。当模型决定调用某个虚拟工具时，我们便立即将其展开。但权衡取舍也随之而来，因为一旦展开……
主持人：KV 缓存等资源就马上被耗尽了。
Kai Maetzel： 正是如此。某些模型支持将这项操作置于提示词末尾，而另一些则不支持。此时必须立即做出权衡，这也正是大量评估测试介入的环节——你需要在所有不同配置下运行测试。这涉及优化决策的权衡，比如： “即便缓存偶尔失效一两次，长期来看仍可接受”，或者你认为“其实可以使用更长的提示词”，因为能让缓存命中率提高到 87%（或其他数值），这样的价值交换可以接受。
这种权衡取舍在其他上下文部分也同样存在，根本不存在真正稳定的状态。当然也有一些相对稳定的要素——比如用户身份、用户运行的仓库环境。但问题在于：关于项目本身，究竟需要提供多少信息？
比如我们设置了这样的前缀，表达 "这差不多就是用户眼中看到的项目形态”，这还算是合理的 token 消耗。但在此之上还有动态包含的内容——当存在 AGENTS.md 文件时，我们会执行自定义指令，这些指令支持多种定制方式、处于特定位置。在自定义指令文件开头可以声明适用范围，通过通配符模式指定“某个测试文件夹中的 TypeScript 文件”这类具体应用场景。
此外还有另一种机制，可以明确描述自定义指令适用的具体语言环境。我们会收集这些规则并将其纳入提示词系统。我认为这个过程最具价值，因为它确保用户能自主掌控代码库的 AI 预处理程度。只要用户的预处理质量够好，智能体就能极快定位目标位置，明确起点与搜索范围。
主持人：或许我们可以聊聊智能体组件与 IDE 本身的交互机制。你之前提到过几个实例：若智能体在前台运行，应使用能连接 IDE 组件的工具，确保其在正确环境中运行而不再依赖终端。但您向智能体公开的 IDE 接口范围有多大？如何区分智能体引发的变更与人工操作引发的变更？
Kai Maetzel： 关键在于你如何与它交互，对吧？最直接的方式就是在 VS Code 中运行一个前台智能体。这个前台智能体具备丰富的功能集：它能监控终端操作，读取终端选定内容，还能运行工具、监视任务等等。我们还为其配备了专业编辑工具，能够在特定时间点运行快照功能，这样就能向你展示所有彼此关联的差异对比。我们为前台智能体准备了相当丰富的工具集。
而后台智能体则截然不同，我们为其提供的功能大幅精简。为什么要区别对待？首先，若在前台运行智能体，用户自然期待其响应速度要快。这涉及交互体验，毕竟没人愿意枯坐两分钟而无所事事，大家都希望快速获得结果，对吧？同时还要确保这些操作，本质上正确反映你希望执行的扩展行为。
但当你把任务移到后台运行时，显然希望它在任何情况下都别搞乱你的 UI 状态。我们之前多次提到测试运行器的例子，你绝不希望它干扰到测试运行器，更不希望它擅自打开终端导致鼠标突然点击错误位置，对吧？
你实际使用的工具集各不相同。云端智能体又是另一种模式。后台智能体仍在本地设备运行，所以会受到合盖操作影响；而云端智能体则不然。关键在于：该智能体实际运行于何种容器化环境？你使用的具体项目是什么？它能否在该容器中成功构建？能否在容器内执行测试？有时候可以，有时候会出问题，诸如此类。所以云智能体为此配备的工具明显更为精简。不好意思有点跑题了，能不能再复述一下问题？
主持人：我的问题其实是：您如何看待这些交互？虽然已经解释了很多，但这让我产生一个疑问——不同工具的公开程度差异，究竟会多大程度影响智能体的执行效果？试想同一条提示词在 IDE 环境、后台智能体和云环境中的呈现，可能导致截然不同的编码行为。
Kai Maetzel： 我认为模型选择对实际结果的影响更大。我们真正想做的是在用户体验与智能体成功之间取得平衡。正如我们所说，终端工具能执行终端命令，能实现很多功能。你无需编辑器来重定向输入并输出注释。有了编辑器，它就能向文件系统执行写入。
要让智能体成功完成从 A 到 B 的任务，其实并不需要一大堆工具。当然，差异也是客观存在的。例如，行业可能发布待办事项工具以实现智能体长期运行、自我组织等功能。但若深入思考，你会发现实现成功其实并不需要太多工具——这是其一。
当我们将智能体置于前台并赋予更多工具时，智能体跟环境的相关度就会更高。例如，我们可以向智能体提议“或许可以安装这个扩展以提升用户体验”。但在 VS Code 里，我们会提供现成的工具。比如你搭建新项目时，会说“我想完成这项任务，请帮我创建这个工作区”。或者你发出指令，但没安装对应的 Go 扩展。这时智能体会主动提示： “顺便提醒，需要安装 Go 扩展吗？”这本质上是根据用户所处环境提供适配体验的差异。
这其实也会影响你与智能体的交互方式。对于后台智能体，我并不希望有太多交互。在这种场景下，我需要上下文隔离，甚至希望它能在沙箱环境中运行，这样就不会被工具调用打扰——比如必须手动批准工具调用这类操作。但对于前台智能体，情况则完全不同——用户往往尚未明确具体操作目标，至少在我的观察到中存在大量这类使用场景。人们讨论代码时，通常会进行选择性操作，比如“帮我修改这部分”，这类指令通常很简短。
有时用户会启动 NES 开始修改，却中途放弃，转而切换到前台说“帮我补全”。这种情况需要快速响应，即仅处理当前文件中的剩余部分。或者当用户创建新测试用例时，这些测试用例生成通常耗时不长。当然，还是要具体情况具体分析。但多数时候流程很简单：先把任务推入后台，稍后回来复盘。而现在更常见的作法是立刻处理，当场运行测试且随即复盘。这样能杜绝作弊行为，确保测试不会预先适应实际行为模式。
这两种交互模式有着显著差异。前台化测试的本质是短时交互行为——讨论代码、标记代码、收集所需上下文，这些操作都高度依赖代码本身。而后台智能体则不同，你必须在启动测试时就做到精准定位，结束后若需复盘也仅是补充性操作。两者对准备程度和预期效果的要求截然不同。
我想强调的是：说起代码讨论，指的是那些确实关注代码的用户，比如需要指导软件架构、推行特定模式等工作的项目。而另一种情境则是，你压根不在意代码形态，而纯粹以结果为导向。顺便说一句，这些界限在同一个项目中也会来回转换。
主持人：完全同意。我只关注核心架构，至于这个工具嘛……随它去吧，我不在乎。
Kai Maetzel： 没错，正是如此。有趣的就在这里。我认为整个行业可能还没充分讨论过：如何让代码库具备 AI 就绪性？以我们的项目为例，最初的代码提交距今已经十年往上，我们随后在此基础上持续迭代。要让代码库具备 AI 兼容性，必须重新审视核心抽象层——这些基础架构绝不能随意更改。只有在系统明确提示后，才有必要加以修改。
但正如你所说，还有些外围组件更加灵活性。比如某些工具，你可能只想在特定场景下使用。而现在，工具的应用已经越来越泛化。你甚至可能直接提交提示词文件来生成新工具。这完全是两种不同的概念。现在我们需要思考什么不可触碰，什么属于外围领域，哪些需要关注，哪些可以忽略。大多数人非常喜欢用测试驱动开发来处理这类问题。测试对我而言就是实现环节的提示词文件，这种模式极具灵活性，而且不同用户的处理方式差异很大。
主持人：我很好奇，当我们讨论这些不同的操作模式，以及我们在不同模式间流转时，如何将它们串联起来？我举个例子，很想听听你的见解。我大多采用交互式工作模式：边思考边实践，突然灵光乍现、想到一种可能效果很好的处理方式。
这时我会启动预先定义的研究型提示词。我会启动后台智能体，下达指令“去我的代码库中研究这种方案的实现效果，用 Go 语言写份分析报告。”它会自动执行任务，而我继续推进主线工作。随后我需要将结果提取回交互模式——目前我只能通过分支之类的方式实现。但我好奇 IDE 是否存在某种机制，比如把想法注入栈中，然后随时弹出到交互式环境里。
Kai Maetzel： 这里涉及的思考方式是不一样的。而且有意思的是，我们有个原型设计，虽然还没实现，但类似的讨论也出现过——主要是关于何时切换回后台智能体或者云智能体的问题。你的情况类似，因为这取决于输出结果。我关注的是云智能体生成了什么，你关注的则是查看分析结果、需要审阅哪些内容等等。
你的思路是：启动任务后，总会有需要返回处理的节点。因此需要系统发出“已准备就绪，可供审阅”的提示信号。但有趣的是，单纯查看有时候还不够，可能需要涉及全面调查。比如以交互的形式确认“已准备就绪，可前往查看”。随后还需反馈：“已经实际执行，结果确实良好”。所有这些环节的结果都要明确可控。
仔细想想，这跟现有技术也差不多。比如邮件管理工具之类，它们的特性都相当相似。我们产品的独特之处在于：在与聊天窗口等交互时，虽然可以清理掉显示内容。但你始终清楚后台任务的位置，知道哪些已准备就绪可供查看。你不需要查看运行了什么、操作了什么，就能确定自己需要的结果已经生成完毕。
我刚才提到过一套原型设计方案，就是将这类提示直接置于标题栏顶端——它能以覆盖层的形式实时弹出，你只需瞥一眼就能获取信息。这是一套以提示信息为中心的布局方案。不确定我描述的这个界面最终是否采用，但无论采用何种方案，这种“周边感知”功能绝对不可或缺，能够实时提示其他任务已准备就绪。
当然还会有其他平替方案，毕竟我们常常过于专注于自身工具，忘记查看提示信息。但这里的核心逻辑始终不变：在需要协助时，直接点选即可。集成工具和其他工作环境会明确告知：我们与你智能体间已经建立 Slack 频道。它还会在完成后自动弹出提示。这套方案将会无缝融入你的其他工作流程。
这方面其实很值得深入探讨。有些操作需要在 IDE 里处理，有些需要通过 github.com 通过 GitHub 实现。但这种场景边界并不重要。如果将智能体视为参与者，那其实已有许多为参与者量身定制的工具。因此我们需要拓宽解决这类问题的思维方式。
未来 IDE：安全、扩展与开发模式演进
主持人：非常赞同。这正好引出下一个话题——Visual Studio Code 一直以高度可扩展性、插件为核心、开放性著称。在 AI 这个新领域下，这些特性将如何体现？是否需要做出调整？之前你提到了 MCP 服务器，这确实是交互的一种方式。这个领域是否也在发生变化？
Kai Maetzel： 其中很多部分是存在交集的。一方面，过去要为 VS Code 添加新功能就必须编写扩展程序，但现在也许可以直接调用大模型执行部分操作。之前提到，只要提供自定义提示词文件就能实现某项功能，据此启动后台研究智能体。现在我们既能添加自定义提示词文件，又能在 IDE 交互模式下直接操作。若再配合键盘快捷键支持，瞬间就实现了无需编写扩展的全新可扩展性。
这又要分开来看，某些场景仍需依赖扩展程序，但另一些场景下，你无需编写扩展程序便已拥有高度灵活性。这本身就改变了可扩展性的定义。而 MCP 服务是近期出现的新概念，而且很有意思，因为 MCP 规范的覆盖范围极广。但最有趣、最常用的特性，是它能实现工具调用功能。这相当于提供了完整的工具托管环境。
关于这个问题，某些方面的答案已经非常明显，目前做断言还为时过早。比如 Anthropic 前段时间就刚发布了相关观点，是关于程序化调用 MCP 工具的讨论。但在我看来，我们本质上还是在创建不同的 API。问题在于：为何不直接将其归入 API？普通 API 与 MCP 服务器之间何必要刻意区分？很明显，二者正在逐渐融合。MCP 就是你发布的另一种 API，仅此而已。这样定义才合乎逻辑。
但必须承认，智能体的自主性会带来更严重的安全影响。你需要思考如何实际控制这些智能体：允许哪些行为，禁止哪些行为，身份管理、智能体权限设置等所有环节都需纳入考量。当前我们的做法是为部分场景创建沙箱环境。
但变化已经开始发生。语言这个东西理解空间很大，提到“7 号上下文”可能是要引用这部分信息，也可能想表达“7 号上下文有问题”。我举个例子：你正在注册网站，页面上滚动显示 Markdown 文件。虽然可以设置数据清理机制，但任何机制都可能被绕过。现在，你有一个 MCP 服务器能自动检索这些文档片段，将其放入提示词中，之后它就开始构建并执行代码等等。因为整个过程会自主执行，就必须关注数据源污染的可能。你可能得控制所有入口点，但这又会大大影响用户体验。
主持人：确实是这样。本质上，所有大语言模型都是另一种形式的计算行为——它们采用词汇编程而非传统编程。因此任何 MCP 服务器都在向你的设备注入运行代码。你信任它吗？你信任所有能向其中注入内容的人吗？
Kai Maetzel： 没错。这正是核心问题所在。以 VS Code 为例，我们实际采用的工具审批机制会高度关注输入/输出环节。你刚才提到的正是这个环节：“你是否同意执行这条命令？”如果 MCP 服务器在本地运行，那一般采取本地操作的形式。它可能安装软件包，可能会使用 UVX 或者 NPX 命令。
一旦你同意执行这个命令，那么本次会话、本次调用中该如何处理？是否存在特定模式的命令需要批准？要做好这类配置还有很大空间。在此之后发起调用，假设指向的是远程 MCP 服务器，那表达的就是允许调用该服务器。
但现在，算出来的响应结果将以摘要形式或原始形式写入聊天历史记录。我当时就想："这该怎么办，难道真要审查所有返回的内容？"这不现实，但又不得不做，最好是采用专门的安全模型来执行此类监控。总之新的难题再来了。
而且这还只是单向聊天。如果进一步转到终端执行命令时，难道要每条终端命令都请求许可？比方说在执行之前，先读懂这个终端命令的含义。如果终端命令确实安全，就执行它。同时也要赋予用户控制权。比如企业环境中的用户可能需要考虑哪些工具无需每次显式授权即可调用，这跟我们在云端租用的虚拟机上运行特定场景的情况截然不同。
主持人：那我就好奇了，这是否意味着未来所有开发都将转移到容器或虚拟机内部进行？
Kai Maetzel： 如果把逻辑推演到底，我认为你的猜测很有道理。但即便如此，仍需管控容器的输入输出。比如获取网页时——比如当你说“我需要最新版本的 Node”时，系统就会立即在终端执行安装命令。
我们都希望确保安全，希望能够关上大门。但我的观点是，即便将这些内容封装在容器中，问题依然存在，只是这里可以更有效地控制环境。但我们仍需思考如何打造良好的用户体验，如何让这一切变得清晰易懂等等。先澄清一点，我们之前讨论的所有问题，都只限于涉及一、两个后台智能体。但现在需要将这个数量乘以 100，那问题性质就截然不同了。我们必须全面解决这些问题。
以云端智能体为例，假设你在 GitHub 上整理代码，将大量问题分配给 Copilot，或者启用了自动分类功能。你会说：“帮我对某些问题进行自动分类。”之后你收到这些 PR 请求，接着需要审核这些 PR。审核五到十条还好，具体取决于规模。但如果每天要审核 200 条的话……
主持人：过去这半年，我审核的代码量多到记不清了。简直荒谬，太疯狂了。我正好引出了我想在最后探讨的方向——咱们这期访谈也差不多快结束了——你认为未来一、两年间，这个领域会如何发展？咱们别展望太远，因为正如你强调的，变化实在太快。但 VS Code 以及整个代码编写管理生态会怎样？我这么说是因为，或许我们真正要做的不是编写代码，而是管理代码的生成或编写过程。你认为未来会如何发展？有哪些新事物即将出现？
Kai Maetzel： 我不敢说自己能预见两年后的景象，因为我们可能很快就会抵达某个意想不到的境地。但随着对交互模型这一活跃研究领域的探索，我希望能尝试不同实现方式，观察用户实际接受度。比如使用比例如何变化。初期用户会频繁使用 Tab 键切换，如今比例明显下降。当然，这取决于用户经验水平和代码实现的具体环节。正如你所说，有些功能是绝对不可触碰的禁区，而其他部分则存在灵活性。所有这些因素都在影响交互模型的设计。
这种变化会始终存在，但我们终将找到解决方案。不同领域会涌现出各种新思路。我认为核心问题在于如何有效利用智能体。这同样是个难题，因为人们总说“我们可以并行运行多个智能体”。没错，但关键是在哪种场景下使用？以 VS Code 项目为例，到时候我们每月可能得处理 3000 个问题。
主持人：这里说的是两年后的情况，对吧？
Kai Maetzel： 差不多，每月 3000 个问题已经非常夸张了，这还是仅基于人工处理的情况。现在加入 AI 后，这个数字必然要提升。那么并行处理能力能提升多少？因为存在不同执行模块，作为团队成员，每人可以负责一部分作为专属任务，每个标签下可以运行多个智能体，这没问题。但若要创建新功能，而非在后台运行多个任务，那复杂度就完全不同了。因为按步骤一、二、三线性推进更容易理解，而“步骤 1 之后还有 2A、B、C、D”这种分支逻辑明显要复杂得多。
主持人：这会触及认知上限的。
Kai Maetzel： 完全正确。作为人类，哪怕能保证产出代码都拥有良好质量，我们也几乎是整个链条中最薄弱的环节。这种趋势已然显现，关于如何真正驾驭这种级别的并行性，我认为还有很多工作要做。
我认为这是最终必然要面临的局面，想想现实世界中那些大规模的运维场景：当你需要进行变更时，比如要引入某个新的垂直功能，却发现它实际涉及数十个仓库、不同服务的部署，以及各种相关环节。这种情况下，你几乎必然要制定计划，类似项目规划，还需要部署智能体。其中一种方案是采用单仓库模式，仅运行一个智能体。
但更可能的情况是保持分布式架构，多数项目都更需要这样的处理方式。此时需要部署多个智能体实例，由主智能体向其他智能体分配任务。这些智能体在运行时需要相互通信，需要汇报当前位置。汇报内容不能再是简单的 Markdown 文档，可能需要追溯到“真正的变更追踪器”、“关联问题列表”等环节，甚至需要在规划看板上查看才能理解全貌。
这涉及诸多环节，而人始终是链条中最薄弱的环节。成功关键在于透明度，比如智能体的实际进展如何等等。我认为这个领域还有大量工作需要推进。还有另一个方面，这也是我个人最困扰的点：人们总爱夸大其词说“现在随时随地都能编程。” 没错，想到创意就用手机输入发送，快速查看原型效果，确实存在这类场景。
但这只是替代方案，而且只是换了个平台。我不太理解不用笔记本电脑，偏要用手机或者其他移动设备，到底有多大的意义。或许语音功能在这方面能发挥重要作用，但就个人来讲，我绝不会在手机上审查代码。
主持人：没错，我正想说，快速检验原型效果是很棒，但在手机上审查代码实在痛苦。
Kai Maetzel： 没错。我再聊最后一点。其实仔细想想也不意外，我们喜欢创造性工作，但哪些环境更适合发挥创造力？我发现我们仍停留在非常传统的协作模式。我们当然可以和 AI 助手建立 Slack 频道进行互动，但更重要的是，人类真正喜欢的是哪种方式？我们喜欢围着仪表板协作，聚在一起共同完成任务，桌面上则摆放着材料供我们讨论时翻阅。这类场景该如何复现？
大家还记得微软曾推出过的 Studio PC 吧，屏幕很大而且可以平放。现在你可以用类似设备在屏幕上绘图，尤其在 UI 开发时，直接在屏幕上勾勒设计方案，边画边问智能体： “这个元素该往这边挪点，你觉得怎么样？”突然间，你就成了绝对的交互中心，人类最喜欢这种被关注的感觉了。这种交互能释放大量多巴胺。它还能通过语音、多模态输入等方式获得强大的 AI 支持。这个过程可以涉及代码，也可以不涉及，只是在幕后确实由代码来支撑。总之这种体验会非常好，我能清晰预见这种模式。未来我们也必将看到更多类似应用涌现。
主持人：我觉得这是个绝佳的切入点。
原文链接：
https：//softwareengineeringdaily.com/2026/01/06/vs-code-and-agentic-development-with-kai-maetzel/
