前阵子有个做客服助手的朋友跟我说，产品要上“多 Agent 图编排”。他给我看了白板：意图识别、知识检索、回复生成、人工兜底，全都画成节点，箭头绕了一圈又一圈。随后他又说，既然是图，干脆让三个 Agent 分别想回答，再把答案汇总，应该会更聪明。

这句话里其实叠了两件事。

第一件，是系统怎样把活交出去：谁查资料，谁调工具，失败后回哪一步，人要在哪个节点接手。第二件，是面对一个难题时，模型怎样留下几种不同的思路，淘掉差的，把互相补充的部分合成一个答案。两件事都能画成图，图上的箭头也都能分叉、汇合、回环，所以特别容易被混在一起。

混完以后，项目组常常拿错药。明明是检索接口不稳定，却在讨论多开几个思考分支；明明是几版回复各有一半信息，却忙着加队列、加重试。图越画越大，真正的卡点反而没被碰到。

左边这张图，管的是“答案怎么长出来”

Graph of Thoughts（GoT）讨论的是推理过程。论文把模型产生的中间想法看成节点，把它们之间的依赖看成边。它最有意思的地方不是“能分叉”，而是分叉后的想法可以再汇合、比较、修订。

拿一个很日常的任务说。你要给一家杭州的社区咖啡店做一页开业活动文案，手上有老板的要求、附近商圈信息和三条用户评价。直接让模型写一版，当然可以；但你也可以先让它分别尝试三条主线：新客优惠、邻里熟客、周末亲子。接着按“是否说清活动规则、是否符合店的调性、是否有能落地的行动”来筛，再把最好的两条合成一版，最后专门检查有没有遗漏营业时间和限制条件。

这里的节点不是三个员工，也不是三个接口。它们是三份候选表达、一个筛选结果、一次合并后的草稿。你关心的是内容有没有互补，评分标准能不能把空话刷掉，修订是否补上了缺口。没有可靠的判断尺子，分再多的支，最后也只是把三段顺口的话叠在一起。

这正是 GoT 的边界。论文在排序等特定任务上报告过与 Tree of Thoughts 的比较结果，但那不是“图形架构会让所有 Agent 更好”的通行证。它证明的是：当任务能定义中间状态、能比较候选、也允许把候选重新组合时，图状推理多了一种可控制的搜索方式。做不出评价规则的任务，先老老实实走一条清晰的链，往往更省。

右边这张图，管的是“活怎么跑完”

Agent 工作流图是另一层东西。它的节点可能是一个模型调用、一次网页检索、一个数据库查询、一位人工审核者，或者一份已经写好的草稿；边表示谁等谁、谁把产物交给谁、失败时回哪里。

还是那家咖啡店。如果工作流是“收集素材 → 检查活动日期 → 生成初稿 → 店长确认 → 发布”，问题就不在候选文案怎么汇合，而在每一步是否有输入、输出和负责人。活动日期缺失时，是直接停止，还是去问店长？发布接口超时，是重试，还是保存草稿？店长半天没回，系统能不能提醒而不是悄悄发出去？这些都是工作图该处理的事。

这张图的本钱是时间、权限和责任。多一个节点，不只是多一次模型调用，也多一个超时点、一次状态传递和一个可能没人接的异常。它的好处也不是看起来像一个复杂系统，而是能把“谁来验证、失败怎样恢复、什么情况下不能继续”写成可执行的规则。

把两张图并排看，差别就清楚了：

先问的问题推理图工作流图
节点是什么候选想法、中间结论、修订稿Agent、工具、任务、人或产物
真正要优化什么质量、互补性、推理遗漏时延、成本、权限、失败恢复与验收
什么时候该分叉有几条确实不同的解题路径可以并行，且产物之间没有硬依赖
什么时候该汇合有明确规则能合并或筛选候选下游确实需要多个上游结果

两种常见的错配

第一种错配，是把工作流里的每个节点都包装成“会思考的专家”。客服系统已经能稳定查到订单和退款规则，却再加三个角色轮流讨论该不该退款。除非它们掌握了不同证据，或者有一把明确的风险尺子，否则这不是推理升级，只是把一次判断拖成三次等待。该补的可能是规则版本、订单状态，或人工复核入口。

第二种错配，正好反过来。内容团队要从十几份访谈里提炼选题，先让不同人或模型各自找出矛盾、反常点和可验证的故事线，最后再合并。这里如果只画“研究 Agent → 写作 Agent → 发布 Agent”，工作当然会往前走，但最值钱的比较过程消失了。你得到的通常是一篇顺滑的总述，不是经过取舍的判断。此时应当在研究节点里面留下候选、打分和合并的过程，而不是再往外接一个虚假的 Agent。

图不是目的。它只是把原先藏在聊天记录里的选择、等待和责任摆到桌面上。看见哪个变量在起作用，才有资格决定要不要加线。

开工前，先找你的问题属于哪一层

下次有人提出“我们也做个 Graph”，不用先讨论框架。拿一张纸问四句就够了。

  • 现在坏掉的，是答案不够好，还是流程根本没有跑完？
  • 如果要生成多个候选，谁用什么规则判断它们的好坏？
  • 如果要增加一个 Agent 或工具，它拿什么输入，交什么输出，失败后谁负责？
  • 去掉这条分支，系统会少掉一个必要能力，还是只少掉一点“看起来很先进”的感觉？

前三句把手牌摊开：质量问题要先有评分尺子，交付问题要先有状态和责任。第四句最管用。很多图之所以越画越臃肿，是因为每个节点都能讲出一点想象中的收益，却没人算它会带来多少新的等待、调试和维护。

一个实用的顺序是：先把工作流画成最短能交付的一条线，标出输入、输出、验收和失败出口；只有当某个节点确实存在多条值得比较的思路时，再在那个节点内部画推理图。这样，工作图负责把事情送到终点，推理图只在需要动脑的地方展开。

别急着把所有箭头接成一张大网。多数项目最先需要的，不是更复杂的图，而是一句能回答清楚的话：这一步究竟是在帮模型想明白，还是在帮团队把活做完？