Claude刚发现了工作流，Charlie从那里起步

Anthropic最近在Claude Code中引入了动态工作流，这一举措在开发者社区引起了关注。然而，Charlie Labs的创始人对此持有不同看法：他认为，真正有效的架构不是围绕会话（session）构建，而是以任务（task）和任务树（task tree）为核心。

工作流的真正价值在于承认复杂的软件工程并非线性过程。优秀的工程师会调查、比较选项、检查边缘情况、请求审查、运行测试，并在证据与计划矛盾时调整方向。代理需要具备同样的能力：一个工作单元可以检查数据库层，另一个读取API边界，验证者尝试破坏补丁，最终答案综合所有证据形成交接。

但关键在于，这需要架构层面的支持，而非仅仅提示词技巧。多个工作单元需要生命周期状态、作用域上下文、交接、权限、取消、重试、验证和记录。否则，你得到的只是一个令人印象深刻的群聊，却消耗大量资源。

Charlie从任务出发，而非会话。一个本地聊天或IDE会话对于紧密循环很有用，但在工作需要共享、恢复、审查或跨工具协调时，会话变得笨拙。它们属于一个人、一个时间线、一个转录，协调痕迹是自愿加入的。相反，Charlie将请求本身视为持久对象：一个Slack线程、GitHub评论、Linear问题、定时唤醒或审查请求都成为一个任务。该任务可以创建子任务，每个子任务在有限的角色内运行并返回结构化交接结果。分支、提交、PR、测试输出、评论和后续问题都会出现在团队已经工作的系统中。

当出现问题时，这种差异变得至关重要。如果用户在运行中跟进，任务可以适应；如果验证失败，失败成为交接的一部分；如果工作单元完成，它返回持久标识符而非模糊摘要。会话没有变得更深入，而是工作离开了会话。

反对者可能认为任务树听起来很重——工作单元、交接、验证、持久状态——这似乎只适用于大型迁移，而非小任务。但事实恰恰相反：重工作流模式的对立面并非玩具模式，而是具有更小影响范围的相同系统。例如，在Slack中请求修复一个拼写错误，Charlie可以运行一个狭窄的任务，创建分支，格式化文件，打开PR并报告。请求回答一个GitHub审查评论，它可以保留目标，修补代码，运行相关检查并在原处回复。相同的底层，更小的任务，更快的完成。

因此，“工作流模式”是错误的思维模型。团队不应该决定一个请求是否值得编排——每个请求都值得完成它所需的最小编排：有时是一个工作单元和一个命令，有时是一个工作单元树和验证过程。编排应是底层基础设施，而非升级按钮。

Claude动态工作流对市场而言是一个积极信号，它明确指出了严肃的代理工作需要分解、并行、验证和持久化。但作者认为，讨论应更底层：问题不在于代理是否能在会话内创建工作流，而在于产品是否围绕持久工作构建。Charlie从一开始就基于任务构建：请求成为任务，任务形成树，工作单元运行有界作业，交接保留状态，证据进入可审查的工件，后续请求可在运行中到达，守护进程作为有界激活而非假装永生的后台进程。大工作和微小工作使用相同的机制。工作流不是特性，运行时才是。