VS Code 1.131增强了多Agent任务的可观察性开发者不用打开每个子代理的完整对话就能直接查看其使用的模型、运行时间和当前工具调用。但“看得见”不等于“结果可信”。本文结合真实开发流程说明如何拆分子任务、识别异常运行并设置人工验收关卡。以前使用AI编程最大的问题往往不是它不会写代码而是它工作时像一个黑盒。任务简单时这个问题并不明显。让AI修改一个函数、补一组测试开发者等几十秒就能看到结果。但当任务开始变复杂主代理把代码分析、测试验证和文档检查分给多个子代理之后问题就来了哪个子代理还在运行它使用了什么模型为什么一个简单任务跑了十几分钟它现在是在搜索代码、执行命令还是反复尝试同一个操作多个子代理的修改会不会发生冲突VS Code 1.131开始把这些原本藏在后台的信息摆到开发者面前。这看起来只是一次界面更新实际上触及了多Agent开发能否真正进入日常项目的核心开发者不仅要会分派任务还必须能监督任务。一、VS Code 1.131具体增加了什么根据VS Code 1.131官方更新说明开发者现在可以在Agents窗口的主对话中直接查看运行中子代理的三项信息子代理使用的模型子代理已经运行的时间子代理当前正在调用的工具。如果发现某个子代理行为异常还可以点击它在另一个对话中打开完整执行过程同时保留主任务窗口。这意味着开发者不再需要在多个会话之间不断切换才能判断任务是否仍在正常推进。与此同时VS Code正在围绕Agent Host重构Agent会话。Agent会在独立进程中运行同一个会话可以连接到多个VS Code窗口。官方目前提到的Agent Harness包括Copilot、Claude和Codex。需要注意的是相关能力仍在逐步推出。部分Agent Host功能需要启用{chat.agentHost.enabled:true}实际可用范围还会受到VS Code版本、账号、扩展、组织策略和渐进式发布进度影响。二、为什么“看见子代理”很重要假设我们需要给一个旧项目增加订单导出功能。表面上这是一个功能需求。真正执行时至少可以拆成四部分分析现有订单数据结构实现导出接口补充权限及边界测试更新接口文档。如果让一个Agent从头做到尾执行过程容易变长上下文也会越来越杂。主代理可能因此将任务拆给多个子代理子代理A负责代码分析子代理B负责测试子代理C负责文档主代理负责合并结论。拆分可以提高并行效率但也增加了新的风险。子代理A可能因为找不到入口文件而在整个仓库中反复搜索子代理B可能在依赖不完整的环境里持续重跑测试子代理C则可能根据已经过时的代码生成文档。最终三个子代理都显示“已完成”并不代表三份结果可以直接组合。因此多Agent工作流至少需要两种能力执行能力能把任务拆开并并行完成监督能力能及时发现某个子任务正在偏离目标。VS Code 1.131补强的主要是第二部分。三、模型、耗时和工具调用分别能说明什么1. 模型检查任务和能力是否匹配不是所有子任务都需要使用相同模型。代码检索、格式整理和简单文档生成可以交给速度较快的模型架构分析、复杂调试和高风险修改则可能需要推理能力更强的模型。查看模型信息的意义不是单纯比较谁更强而是判断当前子任务是否使用了与其难度和风险相匹配的模型如果一个只需检索配置文件的任务使用了高成本模型并且长时间没有结果可能说明任务拆分得不够清楚。2. 运行时间发现卡住而不是正在思考运行时间长不一定代表任务复杂。一个子代理长时间运行可能有多种原因搜索范围过大测试命令无法结束缺少依赖或环境变量权限不足反复修改同一处代码目标和验收条件不明确。因此不能简单规定“超过五分钟就停止”而应结合任务类型设定预期时间。例如定位一个配置项通常应较快执行完整测试套件可能需要更长时间分析大型仓库依赖关系耗时还会继续增加。时间本身不是结论而是触发检查的信号。3. 当前工具判断Agent到底在干什么当前工具调用往往比进度条更有价值。如果任务目标是补充单元测试子代理长时间停留在代码搜索阶段说明它可能没有找到正确入口。如果任务只是分析问题却开始执行写文件、安装依赖或外部请求就要检查它是否超出了授权范围。建议重点留意三类情况同一个工具连续重复调用工具行为与当前任务明显无关任务接近完成时仍在进行大范围搜索或修改。这些情况未必代表出错但值得打开子代理的完整对话进行检查。四、推荐采用“主代理—子代理—人工验收”三层结构不要让多个子代理直接把结果推向生产环境。更稳妥的结构是主代理负责拆分和汇总 ↓ 子代理分别分析、实现和验证 ↓ 开发者进行人工验收 ↓ 确认后合并结果主代理负责协调但不应自动获得最终决定权。人工验收至少要检查修改范围是否符合要求是否触碰无关文件测试是否真正执行成功是否新增未说明的依赖是否改变接口、数据库或配置文档描述是否与代码一致是否保留明确的回滚方式。这套结构的关键原则是看见运行状态不等于自动相信运行结果。五、分派任务前先写一份Task Contract多Agent任务失控很多时候不是Agent能力不足而是任务边界没有写清楚。在启动任务前可以先给主代理一份简化的Task Contract目标 为订单模块增加CSV导出功能。 允许修改 src/order/export/ tests/order/export/ 禁止修改 数据库结构 登录和权限模块 现有接口返回字段。 子任务 1. 分析订单字段与敏感信息 2. 实现CSV生成逻辑 3. 补充单元测试 4. 更新接口说明。 停止条件 需要新增生产依赖 需要修改数据库 测试环境无法运行 发现需求与现有权限规则冲突。 验收要求 原有测试全部通过 新增测试覆盖空数据、特殊字符和无权限场景 提交修改文件清单 提供回滚方法。这份合同不需要写得很长但必须回答四个问题要做什么哪些地方可以改哪些地方不能改遇到什么情况必须停止并询问任务边界越清楚子代理并行工作的收益越大。六、发现异常后不要只让Agent“继续”当某个子代理运行时间异常最常见的处理方式是再发一句“继续”。这通常解决不了根本问题。更有效的做法是根据当前工具调用重新约束任务。情况一长时间搜索文件补充明确入口停止全仓库搜索。 只检查 src/order、tests/order 和 docs/api 三个目录。 先输出可能相关的文件清单不要修改代码。情况二测试反复失败要求先分类停止重复执行完整测试。 先判断失败属于代码错误、依赖缺失还是环境配置问题。 只输出证据和建议不继续修改。情况三修改范围不断扩大重新锁定边界当前任务不允许重构公共模块。 撤回对共享工具类的修改在订单模块内部完成最小实现。监督不是不停打断Agent而是在它偏离任务时及时缩小搜索空间。七、哪些任务适合交给子代理适合并行拆分的任务通常具有三个特征输入边界清楚输出可以独立验收子任务之间写入冲突较少。例如分别分析前端、后端和测试代码一个代理实现功能另一个只做安全审查分别检查依赖、配置和文档对多个候选方案进行独立评估。不适合直接并行拆分的任务包括多个子代理同时修改同一核心文件需求还没有明确就开始大范围重构涉及生产数据库、密钥或权限调整无法通过测试或清单独立验收的任务。多Agent不是把一个模糊任务复制三份而是把一个明确目标拆成三个可验证结果。八、VS Code这次更新解决了什么又没解决什么VS Code 1.131解决的是运行过程缺乏可见性的问题。它让开发者更容易知道谁在运行用了什么模型已经运行多久当前正在做什么。但它没有自动解决以下问题任务拆分是否合理子代理结论是否正确修改能否安全合并测试是否覆盖真实风险最终结果是否应该进入生产环境。换句话说可观察性是治理多Agent工作流的基础但不是质量保证本身。常见问题VS Code 1.131会自动启动多个子代理吗不一定。是否产生子代理取决于当前Agent、任务、功能开放范围和相关配置。1.131主要增强了对运行中子代理状态的展示。所有用户都能立即看到这些功能吗不一定。VS Code官方说明相关能力会逐步推出部分功能还与Agent Host、扩展版本及组织策略有关。能看到工具调用后还需要检查代码吗需要。工具调用只能说明Agent正在执行什么操作不能证明操作正确更不能替代代码审查和测试。多Agent一定比单Agent快吗不一定。只有能够独立执行、独立验收且冲突较少的任务才适合并行拆分。拆分不当反而会增加协调和合并成本。结语AI编程正在从“一个聊天窗口生成代码”走向“多个Agent共同完成复杂任务”。当任务规模扩大后开发者的工作也会变化不再只是写提示词而是设计任务边界、观察执行状态、处理异常并验收结果。VS Code 1.131把子代理的模型、耗时和当前工具摆到主对话中是一个看起来不大、实际很关键的变化。因为多Agent开发真正需要解决的第一件事并不是让Agent跑得更多而是让开发者知道它们正在做什么。