Chat 能表达意图，但很难承载长期执行
GitHub 这篇文章指出了 Agent 产品越来越明显的 UX 问题：任务一旦变长，聊天记录会混在一起包含指令、日志、修正和决策。信息并没有消失，但“做到哪一步、哪里被阻塞、什么已经验证、哪里必须由人批准”会越来越难从滚动记录里重新拼出来。
Canvas 的定位因此不是简单的可视化组件，而是人与 Agent 共用的持久化工作面。Agent 可以持续更新状态，人则能够直接检查、调整、批准或重定向，而不必每次都从历史对话重新恢复上下文。
两个案例背后是同一套工作流设计
Java Modernization Studio 把评估、规划、迁移、验证和发布就绪等阶段明确展示出来；Site Studio 则把相同理念用于内容迭代，让章节状态、草稿值和审阅循环不会在多轮对话中漂移。领域不同，但都依赖“状态必须独立于单次聊天回合存在”。
GitHub 总结出的可复用模式包括四点：清晰定义工作流状态、突出真正重要的决策、及时持久化进度与草稿、保留明确的人类审批点。它把“Prompt 一轮一轮聊”升级为可治理的协作系统。
成本本身也是产品设计变量
作者还给出了少见的成本信息：Site Studio 大约花费 2,000 AI credits，Java Modernization Studio 约 3,000。文章并没有回避这类界面的前期投入，而是强调重复工作流可以通过减少重复提示、上下文丢失、来回确认和返工逐渐收回成本。
因此 Canvas 是否值得做，不应只看界面是否更漂亮，而要看它是否真正降低了协调成本、提高了审查质量，并让 Agent 执行更可预测。
本文为 AI 智库基于 GitHub AI & ML Blog 原文整理的编辑摘要；涉及产品能力、价格或可用性时，请以原始来源的最新说明为准。 GitHub AI & ML Blog