智能体工作流画布：让代理工作可见、可操控、更省钱

2026 年 8 月，GitHub 官方博客发表了一篇关于 Canvases（画布）的文章：聊天界面擅长表达意图，但代理一旦开始真正干活，聊天就退化成一条长长的指令、日志、转向和修正的滚动条——计划、决策点、验证和审批时刻全都埋在里面。Canvases 让开发者与代理在一块持久、共享的表面上协作，把工作变成可见、可操控、可审批的过程。本文用 Java 现代化改造工作室的真实案例，拆解画布模式的核心代码。

聊天表达意图，画布承载执行

一、为什么聊天不适合承载代理执行

聊天的优势在于意图：问题还模糊时，你可以在里面思考、细化、指挥。但代理开始干活后，重要信息只是「技术上存在」，全被埋没了。GitHub 的作者给出了判断标准（代码示例2）：任务有副作用、多步骤、或需要审批时，就应该用画布承载。如果团队回答「什么跑过了、改了什么、验证了什么」需要翻聊天记录，你已经在付出协调税。

# Chat is great for intent; canvases are great for state.
# Rule of thumb:
#   ambiguous problem  -> chat (think, refine, direct)
#   agent doing work   -> canvas (persist, inspect, approve)

def should_use_canvas(task):
    return task.has_side_effects or task.multi_step or task.needs_approval

# If you're auditing "what ran, what changed, what was validated",
# and you have to scroll chat history — you're paying a coordination tax.

二、画布的本质：持久且显式的状态

代码示例1 展示了一个画布状态对象：阶段、状态、产物、门禁、决策、阻塞项。Java Modernization Studio 把评估、规划、迁移、验证门禁、上线就绪拆成显式阶段，团队不再靠解析叙述历史来猜进度，而是直接读操作状态。画布让状态持久化，人类可以检查和引导，代理可以更新和推进，双方不需要反复重放上下文就能保持一致。

# A canvas is a durable, shared state object for an agentic workflow
CANVAS = {
  "id": "java-modernization-42",
  "phases": [
    {"name": "assessment", "status": "done",      "artifacts": ["report.md"]},
    {"name": "planning",   "status": "in_progress","artifacts": ["plan.md"]},
    {"name": "migration",  "status": "queued",     "artifacts": []},
    {"name": "validation", "status": "queued",     "gates": ["tests_pass", "review_approved"]},
    {"name": "ship",       "status": "queued",     "gates": ["staging_verified"]},
  ],
  "decisions": [],
  "blockers": [],
}
# Instead of reconstructing state from a chat scroll, teams read this directly.

三、检查点审批：代理继续跑，人类来掌舵

代码示例3 是画布工作流的核心循环：代理在每个阶段完成后把产物写回画布，工作流检查该阶段的门禁（比如 tests_pass、review_approved），不通过就把阶段标记为 blocked 并通知人类。这样人类审阅者只关注高信号判断，代理在检查点之间持续推进——这正是「人机协同」在 2026 年的标准形态。

# Checkpoint approval: agents keep moving, humans steer
class CanvasWorkflow:
    def __init__(self, canvas):
        self.canvas = canvas

    async def advance(self, phase, agent_result):
        self.canvas.phases[phase]["artifacts"].append(agent_result)
        gates = self.canvas.phases[phase].get("gates", [])
        for gate in gates:
            if not await self.check_gate(gate):
                self.canvas.blockers.append(f"{phase}:{gate}")
                return "blocked"          # pause, notify human
        self.canvas.phases[phase]["status"] = "done"
        return "ready"

# Humans see operational state directly instead of parsing narrative history.

四、把成本做成可见状态

代理产出速度可以超过人类的审查速度，此时可见性本身就是成本控制。代码示例4 按阶段汇总 token 成本：哪个阶段最烧钱一目了然，不需要等月底账单。Site Studio 的例子同样说明问题：内容型工作流里草稿反复修订，如果状态不持久，每个迭代都要重建上下文，进度和信心一起流失。

# Make cost visible per phase: cheap to audit, easy to steer
def phase_cost(canvas, usage_log):
    return {
        phase["name"]: round(sum(
            call.cost for call in usage_log
            if call.phase == phase["name"]
        ), 4)
        for phase in canvas.phases
    }

# When agents can outpace human review, visibility is the cost control.
# Expensive stages show up immediately, not after the invoice.

五、给团队的落地清单

第一，为每个多步代理工作流定义画布状态模式（阶段、产物、门禁）；第二，把审批点做成显式门禁而不是口头约定；第三，把成本按阶段写进画布；第四，聊天留给意图，画布留给执行；第五，从小工作流开始试点——比如文档同步、低风险维护更新，跑通后再扩展到迁移类大工程。

六、总结

Canvases 回答的是 2026 年代理工作流最贵的问题：我们进行到哪一步了？做了什么决定？什么被阻塞了？哪里还需要人工审批？把状态显式化、持久化，代理与人类的协作就从「重放上下文」升级为「共享操作视图」——更快、更可审计、也更省钱。