Visual Studio Code 1.130 的重点不是再增加一个聊天入口，而是调整 Agent 的运行方式和审阅路径：会话可以运行在独立的 Agent Host 进程中，多个 VS Code 窗口能够连接到同一进程；预览中的 Agents 窗口则通过紧凑 diff、文件级统计信息和更清晰的聊天可见性，减少开发者在对话、终端与源码之间来回切换的成本。
Agent 会话开始脱离单个编辑器窗口
过去，一个 AI 会话通常与当前编辑器窗口紧密绑定。关闭窗口、切换工作区或同时处理前后端仓库时，会话上下文容易被窗口边界切断。
1.130 引入的 Agent Host 将会话放到专用进程中运行。多个 VS Code 窗口可以连接到该进程，这改变了 Agent 会话的生命周期：窗口更像客户端，Agent Host 才是实际承载会话的运行环境。
这种设计对以下场景尤其有价值：
- 前端、后端和基础设施代码分别位于不同工作区。
- 开发者需要在主仓库与复现问题的最小项目之间切换。
- Agent 执行耗时任务时，用户仍要打开其他窗口检查代码。
- 同一项修改涉及应用代码、测试和部署配置。
不过，多窗口连接不等于 Agent 自动理解所有工作区。实际使用时仍应明确告诉 Agent 当前仓库、目标文件和验证命令，避免把一个窗口中的假设错误地带到另一个窗口。
审阅 Agent 修改时，重点从“读对话”转向“看变更”
Agents 窗口的改进目前属于预览能力。紧凑 diff 适合快速扫描局部修改，文件级统计信息则帮助开发者先判断变更规模，再决定逐行检查哪些文件。
一个更有效的审阅顺序可以是：
- 先看修改了多少文件，以及每个文件的增删行数。
- 检查依赖文件、配置文件和数据库迁移，因为这些文件的影响通常超过代码行数本身。
- 再阅读紧凑 diff，确认实现没有扩大任务边界。
- 在终端运行测试、类型检查和格式化命令。
- 发现问题后，把具体文件名、错误输出和预期行为放回聊天，而不是只说“修一下”。
文件统计信息只能反映变更量，不能代表风险。删除一行鉴权判断可能比新增数百行测试工具更危险，因此它适合作为审阅入口，而不是批准修改的依据。
可以这样实践：构造一个多窗口审阅项目
下面的示例会创建一个小型 Python 仓库，提交初始版本，再制造一组可供 Agent 或人工审阅的修改。运行前需要安装 Git、Python 3 和 VS Code 的 code 命令行工具。
set -eu
ROOT="${TMPDIR:-/tmp}/vscode-agent-review-demo"
rm -rf "$ROOT"
mkdir -p "$ROOT/tests"
cd "$ROOT"
git init
git config user.name "VS Code Demo"
git config user.email "demo@example.com"
cat > calculator.py <<'PY'
def divide(a: float, b: float) -> float:
return a / b
PY
cat > tests/test_calculator.py <<'PY'
import unittest
from calculator import divide
class DivideTests(unittest.TestCase):
def test_divide(self):
self.assertEqual(divide(8, 2), 4)
if __name__ == "__main__":
unittest.main()
PY
git add .
git commit -m "Initial calculator"
cat > calculator.py <<'PY'
def divide(a: float, b: float) -> float:
if b == 0:
raise ValueError("divisor must not be zero")
return a / b
PY
cat >> tests/test_calculator.py <<'PY'
class DivideByZeroTests(unittest.TestCase):
def test_zero_divisor(self):
with self.assertRaisesRegex(ValueError, "divisor must not be zero"):
divide(8, 0)
PY
printf '\nChanged files:\n'
git diff --stat
printf '\nDetailed diff:\n'
git diff -- calculator.py tests/test_calculator.py
printf '\nClickable terminal references:\n'
printf '%s\n' "calculator.py:3" "tests/test_calculator.py:17"
code --new-window "$ROOT"
code --new-window "$ROOT/tests"
在两个窗口中连接同一个 Agent 会话后，可以用下面这种任务描述约束审阅范围：
审阅当前未提交的修改，只检查以下内容：
- 除数为零时的公开行为是否明确；
- 测试是否能被标准 unittest discovery 发现；
- 不要修改函数名或引入第三方依赖。
先列出问题和对应文件，再提出最小修改方案。验证命令：
python -m unittest discover -s tests -v
这里还有一个值得检查的细节：追加到测试文件末尾的新测试类位于 unittest.main() 调用之后，直接运行文件时可能不会按预期收集该类。它适合用来观察 Agent 是否真正检查执行顺序，而不只是总结 diff。
更智能的终端链接为什么重要
终端输出经常包含 src/app.py:42、测试失败位置、日志文件路径或本地服务地址。更智能的链接处理可以缩短“看到错误”到“打开位置”的路径，尤其适合 Agent 生成命令并由开发者负责验证的工作流。
可以在 VS Code 集成终端中运行下面的命令，观察文件位置和 HTTP 地址的识别效果：
printf '%s\n' \
"calculator.py:3" \
"tests/test_calculator.py:17" \
"http://127.0.0.1:8000/health?verbose=1"
python -m unittest discover -s tests -v
链接识别仍存在边界。容器内路径、远程主机路径、带空格的文件名以及自定义日志格式，可能无法映射到本地工作区。团队应尽量让测试工具输出标准的 文件:行号:列号 格式，并确认点击结果指向正确的远程或容器环境。
升级时应检查什么
采用 1.130 时，可以按以下顺序评估：
- 用
code --version确认桌面端和命令行工具都已更新。 - 在非关键分支试用 Agents 窗口，因为相关改进仍处于预览阶段。
- 用真实的多仓库任务验证 Agent Host，而不只测试单窗口聊天。
- 把测试、类型检查和安全扫描保留为独立的批准门槛。
- 检查远程开发、Dev Container 和 SSH 场景中的终端链接映射。
- 审阅 Agent 访问的工作区和终端权限，避免多个窗口扩大敏感文件的暴露范围。
VS Code 1.130 的实际价值，在于把 Agent 从单个聊天面板推进到更完整的开发工作流中。但独立进程、多窗口连接和快速 diff 都只是提高操作效率；变更是否正确，仍需要可重复的命令、明确的审阅边界和开发者最终确认。