VS Code 1.142 给了智能体一块画布，审查这件事的含义变了

先看清哪些是预览

画布是预览功能，设置项是 chat.canvases.enabled，适用范围是 VS Code 桌面版、使用 Copilot harness 的本地会话。canvas 扩展在 GitHub Copilot 应用里也支持。

我建议在预览期把它写进工作区设置而不是用户设置：这样一个仓库可以选择开启，而不影响你打开的每个项目。

「画布」到底是什么，用发布说明的原话说：一个跟智能体协作的交互式界面，开在聊天旁边，你和智能体检视并更新同一个产物，而不是只通过提示词来协调。这一句就是全部功能，其他都是实现细节。

为什么这和一个更好的聊天气泡不一样：聊天记录是意图的日志，会衰减；看板是状态。智能体不擅长维护只能靠描述的状态，人也不擅长从散文里读出状态。

// Canvas is a preview, so turn it on deliberately rather than discovering it.
// From the 1.142 release notes:
//
//   setting: chat.canvases.enabled
//   scope:   VS Code desktop app, local sessions using the Copilot harness
//   also:    canvas extensions are supported in the GitHub Copilot app
//
// Put it in workspace settings, not user settings, while it is in preview.
// That way one repository can opt in without changing every project you open.

// .vscode/settings.json
{
  "chat.canvases.enabled": true
}

// What "canvas" actually means here, in the release notes' own words:
// an interactive interface to collaborate with an agent, opened beside chat,
// where you and the agent inspect and update the same artefact instead of
// coordinating only through prompts.
//
// That sentence is the whole feature. Everything else is implementation.
//
// The canonical example is a Kanban canvas: you move cards, the agent breaks a
// feature into tasks, updates status, and adds newly discovered work. Both of
// you are editing one board, in the same place, at the same time.
//
// Why this is different from a nicer chat bubble: a chat transcript is a log of
// intent that decays. A board is state. Agents are bad at maintaining state
// they can only describe, and humans are bad at reading state out of prose.

自己做一个画布时，真正要回答的问题不是布局

每个画布都由一个 canvas 扩展提供。两条路：装一个现成的，或者在聊天里用 /create-canvas 自己建。

建的时候真正要回答的问题：双方都能操作的最小单元是什么？一个只显示智能体输出的画布是个渲染器；双方都能改的画布才是工具。

我想要的画布结构是按责任分的三段：机械检查（机器判定，人只扫一眼失败）、行为证据（机器产出证据，人确认它存在）、判断决定（人决定，智能体记录决定和理由）。

好的画布会让第三段又短又显眼。那才是人真正不可替代的部分，它值得占据聊天现在用来复述「我刚做了什么」的那些空间。

官方那个 Kanban 例子有一个性质值得抄：卡片会移动。移动这个动作很便宜就能观察到，所以智能体说某件事做完了，你能看见它发生了，而不需要读一段描述它发生的文字。

// Every canvas is supplied by a canvas extension. Two ways in: install one, or
// create your own with /create-canvas in the chat.
//
// The interesting design question when you build one is not layout. It is:
// what is the smallest thing both parties can *act* on? A canvas that only
// displays agent output is a renderer. A canvas that both edit is a tool.

// Shape of a canvas definition (per the extension API surface referenced in the
// release notes; check the official docs for the current schema):
{
  "id": "review-checklist",
  "title": "Review checklist",
  "sections": [
    { "id": "mechanical",  "label": "Mechanical checks", "items": [] },
    { "id": "behavioural", "label": "Behavioural evidence", "items": [] },
    { "id": "judgement",   "label": "Judgement calls", "items": [] }
  ]
}

// The three sections are not decoration. They map to who is responsible:
//
//   mechanical   machine decides, human skims the failure
//   behavioural  machine produces evidence, human checks it exists
//   judgement    human decides, agent records the decision and rationale
//
// A good canvas makes the third section short and visible. That is the part of
// review where a person is actually necessary, so it deserves the screen real
// estate that chat currently spends on re-explaining what it just did.

// The Kanban example from the release notes is worth copying for one property:
// cards move. Movement is cheap to observe, so if the agent marks something
// done, you can see it happened without reading prose about it happening.

那个安静的修复，其实比画布省更多时间

1.142 里还有个不起眼的改动：聊天可以在文件夹之间、新的 Git worktree 之间移动，而且不丢历史。

为什么这比听起来重要？审查一个生成改动的标准流程是：开一个 worktree，在那儿看分支，再回到主检出。以前聊天只存在于一个文件夹里，所以你积累的上下文正好活在那个边界的错的一侧。

现在的流程是：开 worktree、在这个窗口里打开那个文件夹、把已有的聊天移过去，于是对话还在，不用重开一个「不知道为什么我在看这个」的新会话。下一个任务，再移到一个新的 worktree。

两个配套习惯：一个任务一个 worktree，用日期命名，合并后删掉；以及不要把一个聊天移进一个你打算悄悄扔掉的 worktree，因为历史跟着聊天走，不跟着文件夹走。

二阶效应才是关键：持久聊天加一次性 worktree，比持久文件夹加一次性对话更符合智能体的实际工作方式。这两者里总该有一个能活过一个任务。1.142 让你能正确地选，而以前你选不了。

// The quiet fix in 1.142 that will save more time than the canvas:
// chats move across folders and Git worktrees without losing history.
//
// Why this matters more than it sounds. The standard workflow for reviewing a
// generated change is: create a worktree, look at the branch there, then go
// back to your main checkout. Until now the chat existed in one folder, so the
// context you built up lived on the wrong side of that boundary.

# The worktree workflow this unblocks
git worktree add ../review-$(date +%Y%m%d-%H%M) -b review/agent-change origin/agent-change
cd ../review-*

# Now: open that folder in the same window, move the existing chat to it, and
# keep the conversation instead of starting a new one that does not know why
# you are there. Then, for the next task, move it again into a fresh worktree.

# Two habits worth pairing with it:
#   1. one worktree per task, named with a date, deleted after merge
#   2. never move a chat into a worktree you intend to throw away silently,
#      because the history moves with the chat, not with the folder

git worktree list
git worktree prune

# The second-order effect is the important one: a persistent chat plus disposable
# worktrees is a much better match for how agents actually work than a persistent
# folder plus a disposable conversation. One of those two should survive a task.
# 1.142 lets you choose correctly, which was not previously possible.

卡片会移动——这个性质很便宜就能观察到，比读一段描述可靠。

企业管控才是能不能落地的分界线

管理员可以强制智能体沙箱和权限策略，并控制开发者能用哪些权限模式。翻译一下：组织设定上限，个人不能自己抬高。对受监管的团队来说，这就是「我们不能用智能体」和「我们能在这些限制里用智能体」之间的区别。

三条我绝对不会省掉的规则。

第一，先拒绝再允许。给智能体默认允许的终端，等于给了一个多绕几步的远程 shell。从什么都没有开始，需要什么再加。

第二，密钥要防读，不只是防写。一个能读 .env 的智能体可以把内容放进 diff 里。

第三，已应用的迁移要禁写。这是唯一一类「看起来没问题」和「确实没问题」会永久分岔的改动。

另外别忘了重新设计的模型选择器：它能在 Copilot 和 BYOK 贡献的模型之间切换，管理 effort 级别和上下文窗口。企业策略、模型选择、上下文预算这个三角决定了会话成本，能在一个地方看到三者很无聊，也极其有用。

// The enterprise controls are the part that decides whether any of this is
// adoptable. Admins can enforce agent sandboxing and permission policies, and
// control which permission modes developers may use.
//
// Read that as: the organisation can set the ceiling, and an individual cannot
// raise it. For a regulated team this is the difference between "we cannot use
// agents" and "we can use agents inside these limits".

// Illustrative policy shape for an agent permission ceiling. Use the official
// policy names from Microsoft's documentation; the structure is the point here.
{
  "agent.permissions.allowedModes": ["readOnly", "workspaceWrite"],
  "agent.sandbox.enforced": true,
  "agent.sandbox.networkAccess": "deny",
  "agent.terminal.allowList": ["npm test", "npm run lint", "git status", "git diff"],
  "agent.terminal.denyList": ["git push", "npm publish", "curl", "ssh"],
  "agent.fileSystem.writeDeny": ["**/.env*", "**/secrets/**", "**/migrations/applied/**"]
}

// Three rules I would not ship an agent without:
//
// 1. Deny, then allow. A default-allow terminal for an agent is a remote shell
//    with extra steps. Start from nothing and add commands as they are needed.
// 2. Secrets are read-protected, not just write-protected. An agent that can
//    read .env can put its contents in a diff.
// 3. Applied migrations are write-denied. It is the one class of change where
//    "looks fine" and "is fine" diverge permanently.
//
// Also note the redesigned model picker: it switches between Copilot and BYOK
// contributed models, and manages effort levels and context windows. Enterprise
// policy plus model choice plus context budget is the triangle that decides
// what an agent session costs. Being able to see all three in one place is
// boring and extremely useful.

两周上线顺序，以及一个必须验证的问题

1.142 里非预览的部分，加上我的采用顺序。Markdown 编辑器的改进讨论最少但会被摸得最多：粘贴图片、重命名文件链接、面包屑导航。

一个合理的两周节奏：第 1 天开 Markdown 改进，零风险立刻受益；第 2 天用上跨 worktree 移动聊天，这会改变你的审查流程；第 3 天定下企业策略的形状，哪怕团队很小；第 5 天在一个仓库里开 chat.canvases.enabled；第 10 天复盘：画布有没有替代掉一次会或一份文档？如果没有，关掉它。没人用的预览功能是技术债。

Copilot harness 这个细节值得知道，因为它解释行为：会话通过 Agent Host 跑，所以可以在后台继续，并且能从编辑器窗口和 Agents 窗口两边访问。微软说正在根据反馈逐步把 Copilot harness 变成新会话的默认，同时在这个 harness 里重新引入了 Ask 作为内置的只读智能体。

最后一个我肯定会去验证的问题：当智能体把一张卡片移到「完成」，它背后有 diff 和测试吗？一块容易更新的看板，也同样容易不诚实地更新。画布让状态可见，但不能让状态为真。机械门禁留着，画布只承载判断。

// Everything in 1.142 that is not preview, plus the order I would adopt it in.
// The Markdown editor improvements are the least discussed and will be touched
// most: pasting images, renaming file links, breadcrumb navigation.
//
// A sensible two-week rollout:
#
//   day 1   Markdown editor improvements. Zero risk, immediately used.
//   day 2   Move chats across worktrees. Changes your review workflow.
//   day 3   Decide the enterprise policy shape, even on a small team.
//   day 5   Turn on chat.canvases.enabled in ONE repository.
//   day 10  Review whether the canvas replaced a meeting or a doc. If not,
//           turn it off. A preview feature nobody uses is technical debt.
//
// The Copilot harness detail is worth knowing because it explains behaviour:
// sessions run through the Agent Host, which lets them continue in the
// background and be reached from both the editor window and the Agents window.
// Microsoft says it is progressively rolling the Copilot harness out as the
// default for new sessions based on feedback, and that Ask has been
// reintroduced as a built-in read-only agent in that harness.

cat > .vscode/settings.json <<'JSON'
{
  "chat.canvases.enabled": true,
  "chat.defaultAgent": "ask"
}
JSON

// The one thing I would verify before trusting a canvas-based workflow:
// when the agent moves a card to done, is there a diff and a test behind it?
// A board that is easy to update is also easy to update dishonestly. The canvas
// makes state visible; it does not make state true. Keep the mechanical gates
// from the previous article and let the canvas carry only judgement.

组织设定上限，个人不能自己抬高：这是能否落地的分界线。