Visual Studio Code 1.131 把几项原本分散在扩展、独立对话或编辑模式里的能力进一步收进工作台：运行中的 subagent 有了更清晰的状态展示，语音输入不再依赖 Speech 扩展，Markdown 则新增混合编辑器。它们指向同一个变化：开发者可以在更少切换上下文的情况下，观察代理、输入意图并编辑文档。
Subagent 不再是不可见的后台任务
使用多个 subagent 并行处理代码搜索、测试分析或文档整理时，真正让人不安的通常不是等待，而是不知道后台正在做什么。VS Code 1.131 增强了 running subagents 的可见性，无需打开某个 subagent 的对话，就能直接查看三类信息：
- 当前使用的模型；
- 已经运行的时间；
- 正在进行的工具调用。
这些信息能帮助开发者快速判断任务是正常推进、卡在耗时工具上，还是使用了不符合预期的模型。尤其在代理会读取大量文件、执行命令或调用外部工具的项目中，工具调用记录也构成了一层必要的审计线索。
不过，可见性不等于完整隔离。团队仍应检查代理准备执行的高风险操作，并把凭据、生产环境配置和破坏性命令排除在默认工作流之外。运行时间很长也不一定代表异常：大型仓库搜索、依赖安装和完整测试都可能自然耗时。
语音输入进入工作台
1.131 加入了实验性的内置语音输入，因此不必再单独安装 Speech 扩展。它更适合输入自然语言意图，例如描述重构目标、补充验收条件，或者在代码审查时口述一组修改要求。
语音输入并不会消除确认步骤。文件名、命令行参数、API 名称和相似的英文标识符容易出现识别偏差。一个稳妥的工作方式是：用语音描述目标，用键盘校对精确标识符，再让代理或编辑器执行修改。
可以采用下面这种结构化口述方式，减少代理对范围的误判：
目标：为用户查询接口增加分页。
范围：只修改 src/api/users.ts 和对应测试。
约束：保持现有响应字段兼容，不新增运行时依赖。
验证：运行用户接口测试，并报告失败用例。
内置语音输入目前属于实验性能力。正式纳入团队流程前，需要在实际办公环境中验证麦克风权限、语言识别质量、噪声影响以及敏感信息处理规则。
混合 Markdown 编辑器解决两种编辑需求
Markdown 的常见矛盾是：源码模式适合精确控制语法，渲染视图适合检查最终阅读效果，但在两者之间频繁切换会打断写作。1.131 新增的混合 Markdown 编辑器值得关注，因为它试图让结构化源码编辑与更直观的内容处理共存。
这类编辑方式对 README、架构决策记录、发布说明和包含代码块的技术文档尤其有价值。采用前仍要关注几个边界：复杂 HTML、嵌套列表、表格、扩展 Markdown 语法以及格式化工具是否会保持原文稳定。关键文档应继续通过 Git diff 检查，避免编辑器在视觉上正常，却产生了大范围无意义改写。
建一个最小工作区实际验证
下面的示例会创建一个包含标题、任务列表、表格和代码块的 Markdown 文件。它不依赖尚未公开说明的内部 API，可以直接用于比较源码编辑、混合编辑以及 Git diff 的结果。运行前需要安装 VS Code，并确保 code 命令已加入 PATH。
mkdir -p vscode-131-check
cd vscode-131-check
git init
cat > README.md <<'EOF'
# VS Code 1.131 编辑检查
## 验收清单
- [ ] 在混合 Markdown 编辑器中修改本段
- [ ] 检查表格是否保持稳定
- [ ] 编辑代码块并核对源码
| 能力 | 检查内容 |
| --- | --- |
| Subagent | 模型、运行时间、活动工具调用 |
| 语音输入 | 专有名词和文件路径的识别准确度 |
| Markdown | 列表、表格和代码块是否被意外改写 |
```js
function greet(name) {
return `Hello, ${name}`;
}
console.log(greet("VS Code 1.131"));
EOF
git add README.md git commit -m "Add VS Code 1.131 editor fixture" code .
在 VS Code 中使用新编辑方式修改 `README.md` 后，可以运行：
```bash
git diff --word-diff -- README.md
检查重点不是页面是否好看，而是未触碰的表格分隔符、代码围栏、列表缩进和换行有没有变化。团队还可以选一个低风险代理任务，观察其模型、运行时间和活动工具调用是否足以支持日常诊断；语音输入则应使用不含凭据和客户数据的提示词进行测试。
升级时按风险分层
VS Code 1.131 的三项变化分别影响代理监督、输入方式和文档编辑，适合分开评估：
- 先在非关键仓库观察 subagent 状态，确认展示的信息能否帮助识别长任务和异常工具调用。
- 把语音输入视为实验功能，只用于低敏感度内容，并保留人工校对步骤。
- 用受 Git 管理的 Markdown 样本测试混合编辑器，重点检查 diff，而不是只看渲染结果。
- 保留现有扩展和工作流的回退方案，确认新内置能力稳定后再清理重复工具。
这次更新最实际的价值不是增加三个孤立入口，而是减少开发者在代理对话、输入扩展和 Markdown 预览之间来回切换。是否立即全面采用，仍应由仓库规模、安全要求和文档复杂度决定。