GTD 配 Agent：流程图先焊死，LLM 只管节点里的判断

大纲

上周翻一个老硬盘，翻出一个 .mm 文件——FreeMind 的思维导图格式，创建时间是 2009 年。那会儿我刚读完 David Allen 那本《Getting Things Done》，照着书上的框架，拿鼠标一边想一边画了这张图：步骤、决策行动的四个标准、工作任务的三个模式、六个层次。

下面这张图你可以展开拖一拖、缩放——这是 2009 年原封不动的样子：

十七年过去，这张图上的东西我一个字没改过——该收集的还是收集，该澄清的还是澄清。变的只有一件事：现在可能真有样东西，能替我把这套流程跑起来，不用全靠自己每天翻来覆去地念叨。那样东西是个 LLM agent。

可我刚要动手设计的时候，先踩了一个坑：本来想把整套方法论"讲"给 LLM 听——写一段很长的 system prompt，把五步法、四个标准交代清楚，然后把每一条输入丢给它，让它自己判断该归到哪个篮子。想到一半觉得不对：这跟过去把任务攒在自己脑子里，没什么本质区别，只是换了个脑子继续攒。

AI 能分担哪类脑力劳动，我在前两篇里已经聊过——事务管理哪几步能交给 AI、秘书型 AI 的五项职能。这篇想聊清楚的是另一件事：怎么把一套流程方法论，变成一张 agent 真能照着跑、出了错能查到哪一步的控制流程图。拿我自己画的一张 GTD 工作流草图来拆。

把方法论讲给 LLM 听，为什么会乱

我干了十几年后端，有一段时间专门做电话路由——一通电话进来，该往哪条链路转、要不要走加密通道、断了要不要重试，全靠一台路由引擎按规则判断。那套引擎里全是判断节点和动作节点：判断节点决定往哪儿走，动作节点真正去拨号、转发、挂断。规则写得再死板，有一个好处：出了问题，能顺着节点一级一级查，查到底是哪条规则判错了。

把同一套思路搬到 GTD 身上，问题就浮出来了。如果把整个 GTD 流程讲给一个 LLM 听——一段很长的 prompt 交代清楚五步法、四个标准，然后把每条输入原样丢给它，让它从头到尾自己判断该怎么走——这台"路由引擎"就没有节点了，只剩一个即兴发挥的大脑。同一条邮件，这次判断"能做"，换个措辞或者换个模型版本就可能判成"先放一放"，而你根本没法追：是哪一步判错了？没有节点，就没处查。

之前聊 AI 事务管理的时候提过一条坑：别让 AI 替你做判断。 这篇想往前走一步——不是不能让它判断，是判断得有边界，边界画在哪，图说了算，不是 LLM 自由发挥说了算。

拆流程图：三类节点各管一段

把 GTD 那套"收集 → 澄清 → 组织 → 回顾 → 执行"画成一张能跑的图，大概是这样：

flowchart LR
    %% Input sources
    Email[Email]
    IM[IM message]
    Oral[Oral message]
    Meeting[Meeting]
    Call[Call]
    Bug[Bug]
    Task[Task]

    %% Inbox and initial decision
    Inbox[Inbox]
    Actionable{action-able?}

    Email --> Inbox
    IM --> Inbox
    Oral --> Inbox
    Meeting --> Inbox
    Call --> Inbox
    Bug --> Inbox
    Task --> Inbox

    Inbox --> Actionable

    %% Non-actionable paths
    Actionable --> Trash[trash]
    Actionable --> Archive[archive]
    Actionable --> Someday[some day]

    %% Actionable path
    Actionable -->|Y| NextAction[next action?]

    %% Next action choices
    NextAction --> Do[do]
    NextAction --> Delegate[delegate]
    NextAction --> Defer[defer]

    Delegate --> Waiting[waiting]

    %% Deferred tasks
    Defer --> Plan[plan]

    %% Planning options
    Plan --> ReadWrite[read / write]
    Plan --> FollowUp[follow up]
    Plan --> ScheduleMeeting[schedule meeting]
    Plan --> More[...]

    %% Timer workflow
    ReadWrite --> Timer[on timer]
    FollowUp --> Timer
    ScheduleMeeting --> Timer
    More --> Timer

    %% Recurring execution
    Timer --> Do

这张图里的每个方框和菱形，说到底只分三类：判断节点要出一个是非题或选择题的答案，交给 LLM；动作节点真去做一件事（发消息、建任务、删一条记录），交给 Tools/Skills；调度节点跟内容无关，纯粹是时间到了该干嘛，一个 cron 就够。一条条过。

Inbox 之前的七路输入（Email / IM / Oral / Meeting / Call / Bug / Task）汇到 Inbox，这一步是动作节点，不是判断节点。各种格式不一样——邮件是邮件，口头是口头，Bug 是 Bug——这里要做的是把它们搬到同一个地方，格式统一。LLM 能帮的是把"口头"这种非结构化输入转成文字、顺手提炼几个关键字段，这是体力活，不是判断活。

Actionable? 是第一个真正的判断节点。给 LLM 一条 Inbox 条目，让它回答一句话：这事需要我做点什么，还是纯信息、垃圾、以后再说？这是语义判断，写死的规则做不到（"标题带 FYI 就归档"这种规则太糙），恰好是 LLM 擅长的。

不需要行动的三条分支——trash / archive / someday——看着是动作节点，但执行权不能直接交给 LLM。它判断错一次，一封重要邮件就真被删了。可行的做法是把"判断"和"落地执行"拆成两步：LLM 给建议，真正删除或归档走一次需要人确认的 tool call，或者干脆做成软删除，标记一下，不真删。这跟之前讲秘书型 AI 时的立场是一回事：静音权和删除权，永远留在人这边。

Next action? 是第二个判断节点，也是 GTD 里最难啃的一步——很多人卡在 Inbox 里的东西，卡的不是"要不要做"，是"下一步具体该干嘛"想不清楚。这正是 LLM 的强项：拿一条模糊的意图，反问几句，拆成一个具体到能直接动手的下一步。

Do / Delegate / Defer 三条路，待遇完全不同。Do 是人的事，LLM 不该越俎代庖替你拍板"现在做"还是"等会儿做"。Delegate 是一个动作节点——生成一条委托记录、@某人、发一条消息，这是实打实的 tool call。Defer 进入 Plan。

Delegate → Waiting 不是一个节点，是一个状态，需要被定期检查——这条等待是不是该跟进了。这就是 on timer 存在的理由：不是 LLM 该操心的事，是调度该操心的事。图省事让一个常驻对话"记得"去跟进，其实是把调度节点的活硬塞给了判断节点，多出一份没必要的不确定性。

Plan → read/write / follow up / schedule meeting / …… 这些都是动作模板，每一种对应一个预先定义好的 skill：写文档的 skill、发起会议的 skill、设提醒的 skill。LLM 在这一步的角色是"选对模板、填好参数"，不是"随手发明一个新流程"。

On timer → 循环回 Do，调度触发，进入下一轮执行——这才是整张图真正跑起来的地方：它不是一次性的清单处理，是一个会反复转的 loop。

三类节点，各找各的执行者

把上面拆的东西收进一张表：

这跟经典的 workflow engine（BPMN 那一套）思路是相通的，区别只有一处：过去判断节点里写的是正则和规则表，现在可以换成一次 LLM 调用——但骨架、节点边界、谁来执行哪个动作，从第一天就不该交给 LLM 自由发挥。

回头看 2009 年那张老图，"组织"那个环节底下分出的"下一步行动 / 形成项 / 等待处理 / 将来处理"，其实已经是这三类节点的雏形——只是那时候没有 LLM，这四条全靠人脑一条一条过一遍。十七年过去，方法论没变，变的是终于有东西能替我们守住判断节点以外的那堆体力活。

老实说：这还是张图，不是跑起来的系统

把丑话说在前面：这套拆解目前还停在设计阶段，没有一行真的跑起来的代码。下一步要做的，是把图里每个动作节点对应到一个具体的 skill——该用什么工具查日历、该用什么接口发消息、Waiting 的检查周期设多长——这些都还没定。

但"先把图画清楚，再决定每个节点用什么实现"这个顺序本身没错。连流程图都说不明白，直接去写一段很长的 system prompt，大概率写出来的东西经不起第一次追问：这条消息它凭什么归档了？答不上来，就说明判断节点和动作节点之间的边界，从一开始就没画清楚。

总结：给 Agent 自由，不如先给它一张图

GTD 这套方法论，十七年前靠人脑手动跑，现在想交给一个 agent。但"交给 agent"不等于"把方法论讲一遍让它自由判断"——那只是换了个脑子继续攒事情，责任一样追不到底。真正该做的，是先把流程焊成一张图，分清楚哪些是判断节点、哪些是动作节点、哪些是调度节点，再决定每一段该交给 LLM、Tools/Skills，还是一个最朴素的 cron。

如果你也想拿 agent 接手一套方法论——不管是 GTD 还是别的——先别急着写 prompt。拿张纸，把流程画出来，标好每个节点是判断、动作还是调度。画不清楚，说明自己也还没想透。

扩展阅读

• AI 时代的事务管理：从"催我自己"到"指挥助理"
• 比起让 AI 写代码，我更想让它替我干些脏活杂活
• 《Getting Things Done》, David Allen

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。 欢迎在我的个人网站 https://www.fanyamin.com 访问原文并评论。