照着流程图做 Agent，是第一个死因

> **企业 AI 化的四层工程体系 · 第 ③ 篇** > 从业务流程到 Agent 设计：三步拆解法 --- ## 引言：照着流程图搬，是大多数 Agent 项目的第一个死因 场景你一定熟悉：老板或客户拍板——"把我们的招投标分析流程 Agent 化"。 团队领了命，第一反应往往是去找现成的流程图或 SOP，然后照着上面的步骤，一步一步搬进 Agent：第一步读文件，第二步做分析，第三步出报告。逻辑严丝合缝，看起来天经地义。 可做出来的东西，总是脆得让人崩溃。它会漏掉招标文件里的硬性资质要求，会给出离谱的报价建议，会在最关键的判断处胡说八道。团队反复调 prompt、加规则，效果时好时坏。 问题出在哪？**不在模型，也不在 prompt，而在最开始那个动作——"照着流程图搬"本身就是错的。** 因为一张给人看的流程图，记录的是人的**动作**，而不是人的**认知**。流程图上那个写着"审核"的方框，背后藏着一个老员工调了五份资料、凭十年经验做出的判断——而这些判断，流程图上一个字都没有。你照着搬，搬走的只是动作的空壳，把最值钱的认知丢在了原地。 这就引出本系列第三篇的核心命题，请记住这句话： > **AI 化不是"自动化流程"，而是"重建认知流程"。** 这篇文章要解决的，正是那个最关键、却最常被跳过的问题：**当你用上一篇的矩阵锁定了一个值得做的业务流程，你该如何把它从一段模糊的业务语言，拆解成一张清晰的 Agent 设计图？** 答案是一套三步拆解法。我们会拿"招投标分析"这个活生生的例子，从头到尾走一遍。 --- ## 一、先想清楚：自动化 vs 重建认知，差在哪 在动手之前，必须把"自动化流程"和"重建认知流程"这两件事的区别，刻进脑子里。它们听起来像，实则天差地别。 **自动化流程，是保留流程、替换执行者。**它默认现有的步骤是对的、是完整的，只是把执行的人换成机器。它问的问题是："这一步原来谁来做？现在让机器做。"——本质是搬运。 **重建认知流程，是重新设计判断本身。**它不预设现有步骤是对的，而是回到源头问：这个任务的目标到底是什么？要做出好的判断，需要哪些信息？判断在哪几个点发生？哪里最容易错、错了不可逆？——本质是重构。 打个比方。自动化流程，像是给一个老师傅的手装上机械臂，让机械臂重复他的动作；可老师傅之所以是老师傅，靠的从来不是手快，而是脑子里那套看不见的判断。重建认知流程，则是要重新培养一个"新员工"的判断力——你得先搞清楚老师傅到底在判断什么、凭什么判断，再把这套认知用工程的方式重新搭起来。 为什么这个区别如此致命？因为**人的流程里，藏着大量"隐性认知"**——那些没写进 SOP、靠经验和直觉完成的判断。一个有经验的招投标专员，读招标文件时会下意识地核对资质门槛、嗅出隐藏的废标条款、对照公司过往的中标率——这些动作，在流程图上可能只是"初审"两个字。 你若只是自动化那两个字，得到的是一个不会判断的空壳。你若重建认知，才能得到一个真正能干活的 Agent。 让这件事再具体一点。一个老练的招投标专员，拿到招标文件的头十分钟里，脑子里其实在并行做好几件事：他会下意识地翻到资质要求那几页，核对公司有没有踩中某条硬性门槛（一旦不满足，后面全是白费）；他会凭经验嗅出那些"看似普通、实则是为某家对手量身定做"的废标条款；他会回想起去年那个类似的标，我们报价多少、最后输在了哪；他甚至会判断这个甲方的付款习惯值不值得投入。这一连串判断，在公司的 SOP 上，可能只浓缩成"初审"两个字。**那两个字底下，是这个专员十年攒下来的认知。** 如果你只是把"初审"这一步自动化——让模型读一遍文件、输出个摘要——你丢掉的恰恰是最值钱的那部分。重建认知，意味着你要把这个专员脑子里那串看不见的判断，一条条地显性化、结构化，再用工程的方式重新搭起来。这很难，但这才是 Agent 化的真正工作量所在。 而重建认知，需要方法。这套方法，就是接下来的三步。 --- ## 二、三步拆解法总览 把一个业务流程重建成 Agent 的认知，分三步走，每一步回答一个问题： - **第一步，任务结构拆解**：把流程摊平——这件事到底由哪些基本环节构成？ - **第二步，识别认知节点**：在摊平的结构上标注——哪些环节真的需要"脑子"？ - **第三步，定义 Agent Loop**：把这些认知装进一个会循环、会自我修正的闭环。 一句话概括：**先摊平，再找出哪里需要脑子，最后把它装进闭环。**  三步走完，你会得到四张关键的图——它们就是从"业务语言"到"工程蓝图"的翻译产物。下面我们拿招投标分析，一步一步拆。 --- ## 三、第一步：任务结构拆解——把流程摊成四种基本元素 任何认知任务，无论看起来多复杂，本质上都是同一个过程的展开：**拿到信息 → 加工 → 判断 → 产出。**所以拆解的第一步，就是把流程摊平成四种基本元素： - **Input（输入）**：这件事需要哪些原始信息？ - **Transformation（转换）**：信息要被怎样加工、提取、整理？ - **Decision（决策）**：在哪里需要做出判断？ - **Output（产出）**：最终要交付什么？ 注意，这一步**不要管"现在的流程是怎么做的"，只问"这件事的本质结构是什么"**。这正是"重建"而非"搬运"的开始。 我们把"招投标分析"摊开看看： - **Input**：招标文件本身、公司的资质与能力库、历史投标记录与中标率、竞争对手信息、相关行业的合规要求。 - **Transformation**：解析招标文件、提取硬性要求与评分标准、从能力库中检索匹配项、汇总历史相似项目。 - **Decision**：要不要投这个标？我们满足硬性资质吗？报价定多少有竞争力又不亏？最大的风险点在哪？ - **Output**：一份投标可行性分析 + 报价建议 + 风险提示。 把这些摊开、连起来，就得到了第一张交付物——**task graph（任务图）**。它是后面一切工作的地基。  到这里，模糊的"招投标分析"已经变成了一张有结构的图。但这张图还只是"骨架"——它告诉你有哪些环节，却还没告诉你**哪些环节真正需要 AI**。这是第二步要干的事。 --- ## 四、第二步：识别认知节点——找出"哪一步真的需要脑子" 这是整套方法里最关键、也最考验功力的一步。你要在 task graph 上，给每个环节贴上标签，标出四类"认知节点"： - **决策点（decision points）**：人在这里"判断"什么？这是需要 LLM 的地方。 - **工具点（tool points）**：哪一步需要调用外部数据或能力（检索、查询、计算、调 API）？ - **信息点**：哪一步需要把特定的上下文喂进来才能判断？ - **失败点（failure points）**：哪一步最容易出错？哪一步的错误不可逆、代价最大？ 这些被标注出来的节点，就是 Agent 真正的 **action points（行动点）**。而标注的过程，会逼出一个绝大多数团队都搞错的关键认知： > **不是每一步都需要 LLM。** 回想上一篇我们引用过的那条铁律——在成熟的 Agent 系统里，**LLM 扮演的是一个"结构化转换函数"：自然语言进，结构化数据出；而它周围的一切，都是普通的、确定性的软件。**所以 LLM 只应该出现在"需要判断、需要语言理解"的**决策点**上；至于检索、计算、调 API 这些**工具点**，全都该交给确定性代码，而不是让模型去"想"。 把这条想明白，你就不会再犯那个昂贵的错误——给每一步都套上一次大模型调用。模型该出现的地方很少，但每一处都至关重要。 这里要专门提醒两类最容易被搞错的节点。 一类是**信息点**，它常常被并进决策点而被忽略。一个决策点能不能判得准，前提是它拿到了对的信息。比如"判断是否值得投标"这个决策点，背后需要喂入：硬性资质的核对结果、历史相似项目的中标率、当前的竞争格局。如果你只是把整份招标文件一股脑塞给模型让它"自己判断"，它会因为信息过载而判错——这正是后面 Context 工程要解决的问题。所以标注时，每个决策点都要配套问一句：**它判断时，到底需要哪些信息点支撑？** 另一类是 **decision 点和 tool 点的混淆**。看一个容易踩的例子："核对公司是否满足某条硬性资质"——这一步到底是决策点还是工具点？答案是：**如果资质要求是明确、可机器比对的（比如"注册资本≥5000万"），它就是工具点，用确定性代码查库比对，绝不该交给 LLM 去"判断"**；只有当要求模糊、需要语义理解（比如"具备类似规模项目的成功经验"）时，它才升格为决策点。**判据是：这件事能不能被确定性地算出来。能，就是工具点；不能、要判断，才是决策点。**把本可以确定计算的事交给模型去"判断"，是可靠性的头号杀手。 还有失败点，它的关键属性是**不可逆性**。同样是出错，有的错可以重来（检索失败，再检一次就行），有的错一旦发生就无法挽回（误判了硬性资质，整个标直接作废）。标注失败点时，最该盯的就是这些不可逆、高代价的环节——它们是后面校验和人工兜底必须最重的地方。 这里还有两条来自一线的工程纪律，必须在拆节点时就守住： **第一，按信息边界切节点，不要按拟人化角色切。**很多团队会把流程拆成"高级分析师 Agent""报价专家 Agent""风控 Agent"——听着很专业，但如果它们共享同一个庞大的上下文，这种拆法毫无意义：scope 并没有变小，只是同一个大任务套了更多 Agent、更多开销。「12-Factor Agents」社区把这点说得很直白。正确的切法，是按**信息的隔离边界**——这个节点需要哪些信息、产出哪些信息——来划分，而不是按拍脑袋想出来的"职位"。 **第二，工具点的数量要克制。**实测数据显示，当一个节点可用的工具从 3 个涨到 12 个时，模型选对工具的准确率会从 95% 暴跌到 70%。所以在标注工具点时，原则是"每个决策点只暴露它真正需要的那几个工具"，宁可拆成多个聚焦的子节点，也不要堆一个工具大杂烩。 现在，我们给招投标的 task graph 标上节点：  看这张图，你会立刻发现重点在哪：真正需要 LLM 判断的，只有"是否值得投""报价与风险"这两个决策点；解析和检索是确定性工具；而"硬性资质判断"被标成了**失败点**——因为这里一旦误判，整个标就废了，不可逆。这意味着，工程上必须在这个点设最强的校验。 **这张标注图，就是第二、第三、第四张交付物的来源：decision points、tool points、failure points。**它把"哪里要 AI、哪里要工具、哪里要兜底"一次性讲清楚了。 --- ## 五、第三步：定义 Agent Loop——把认知装进闭环 有了节点，最后一步是把它们装进一个会循环、会自我修正的闭环。原始的循环骨架是这样的： > **观察 Observe → 检索 Retrieve → 思考 Think → 行动 Act → 校验 Validate → 重复 Repeat** 但这里有个极其重要的工程认知，必须讲清楚，否则又会掉回"让 LLM 自由发挥"的坑里：**这个 loop，不是让大模型自己漫无目的地循环，而是一个由你的代码显式掌控的控制流。** 这正是上一篇 workflow 与 agent 之分的落地。「12-Factor Agents」里有一条核心原则叫"掌控你自己的控制流"——意思是，循环、终止、状态更新这些骨架，应该写在你的代码里（一个显式的 OODA 式闭环），而不是嵌套在 prompt 里求模型自觉。**模型负责在决策点上"思考"，但"什么时候停、要不要重试、状态怎么更新"，由你的工程来决定。** 一个工程化的 Agent loop，每一轮要做的是：观察当前状态 → 检索这一步判断所需的信息（喂给决策点）→ 让 LLM 思考并产出结构化决策 → 执行对应的工具行动 → 校验结果 → 更新状态 → 判断是继续、还是终止。 这个 loop 里有三个企业必须显式设计的"开关"： - **终止条件（termination condition）**：什么情况下算做完了？什么情况下该停手？ - **循环预算（loop budget）**：最多循环几轮、最多花多少 token？防止成本失控。 - **失败恢复（error recovery）**：第二步标出的失败点在这里被处理——当一个动作失败时，把错误信息喂回上下文让模型自我修正（self-heal）；但要设计三振机制：连续失败几次就 reset、reframe 或升级给人，绝不无限重试。 把这三个开关落到招投标的例子上，就不再抽象了：**终止条件**可以定为"已对所有硬性要求完成核对、且报价与风险结论已产出并通过校验"；**循环预算**可以设为"最多 8 轮迭代、单次任务 token 上限 X"，逼近上限就强制收尾或升级；**失败恢复**则区分对待——检索类的可重试失败，喂回错误重试两次；而"硬性资质核对"这种失败点，一旦校验不通过，不重试、直接升级给人确认，因为这里赌不起。**这三个开关，就是你把"重建的认知"真正变成"可靠的系统"的地方。** 还要记得上一篇那条复利衰减：链路太长，可靠性会指数级崩塌。所以如果一个 loop 超过了 3–10 步的理想区间、逼近 20 步上限，就该把它拆成几个职责单一的子 loop，用确定性代码串起来——而不是让一个 Agent 硬扛二十步。 招投标分析的 loop，大致长这样：  至此，三步走完。招投标分析这个模糊的业务流程，已经变成了一套可以工程化实现的 Agent 设计。 --- ## 六、四张图：从业务语言到工程蓝图的翻译产物 回过头看，三步拆解真正的交付物，是四样东西——它们是企业做 Agent 化之前**必须先做出来**的，也是从业务语言翻译成工程蓝图的成果： 1. **task graph（任务图）**：流程摊平后的结构骨架。 2. **decision points（决策点）**：哪里需要判断——也就是 LLM 该出现、且唯一该出现的地方。 3. **tool points（工具点）**：哪里需要外部能力——工具的接入点，且要克制数量。 4. **failure points（失败点）**：哪里会崩、哪里不可逆——校验和兜底必须最强的地方。 这四张图为什么重要？因为它们不是纸上谈兵，而是**直接对应到本系列要拆解的四层 runtime**。换句话说，这一步是你第一次把上一篇那张"同心圆"的工程蓝图，和你自己的业务真正接上：  - **task graph** 决定了 **Loop 层**的结构——整条闭环怎么走。 - **decision points** 决定了 **Context / Prompt 层**要喂什么——每个判断点需要哪些信息才能判得准。 - **tool points** 决定了 **Harness 层**要接哪些工具、怎么编排。 - **failure points** 决定了 **Harness 的校验兜底**和 **Eval** 要重点盯哪里。 所以这一篇是整个系列的"桥"：往前，它承接了"为什么做、做什么"的战略；往后，它为"Context、Harness、Loop、Eval 怎么做"的工程铺好了地基。**没有这四张图，后面的工程就是无的放矢。** --- ## 七、回到核心：为什么这叫"重建认知"，而不是"自动化" 走完三步，我们再回到开头那句命题，你应该能更深地体会它了。 如果你把招投标分析"自动化"，你会得到一个照着原 SOP 一步步执行的空壳——它保留了人的动作顺序，却丢掉了人的判断。 而你把它"重建认知"之后，会发现一个有意思的现象：**拆解出来的 Agent 流程，往往和原来的 SOP 长得不一样了。**比如，人可能习惯先粗读全文再细抠条款，而 Agent 的最优设计可能是先用确定性工具精准提取硬性要求、立刻在失败点做校验，再进入判断——因为 Agent 的认知方式和人不同，它的可靠性来自工程结构，而不是经验直觉。 这就是"重建"的含义：你不是在复刻人的流程，而是在**为一个新的认知主体，重新设计它该如何思考、信息从哪来、判断在哪发生、错了怎么办。** 三步拆解，本质上就是在做这件事： - 任务结构拆解，重建的是"这件事的本质结构"； - 识别认知节点，重建的是"判断到底发生在哪、需要什么"; - 定义 Agent Loop，重建的是"思考如何在闭环中持续、可靠地进行"。 把这三步做对，你交出的不是一个脆弱的 demo，而是一张经得起工程实现的设计图。 --- ## 结论：先画出四张图，再写第一行代码 这篇文章想留给你的，是一个朴素却被反复忽略的工作纪律： > **做 Agent 化，别急着写代码，先把四张图画出来——task graph、decision points、tool points、failure points。** 而画这四张图的方法，就是三步拆解：先摊平结构，再找出哪里需要脑子，最后把认知装进闭环。贯穿其中的那句核心命题，值得你贴在工位上： > **AI 化不是自动化流程，是重建认知流程。** 如果你是技术决策者，现在就可以做一个练习：**拿出上一篇用矩阵选出的那个"金矿"流程，照着三步走一遍，先交出四张图，再决定动不动手写代码。**你大概率会发现，光是这个拆解过程，就已经让团队对"这个 Agent 到底该怎么设计"有了远比之前清晰的共识。 最后，留一个问题，作为下一篇的引子： 你已经标出了所有的决策点，也知道每个决策点需要"喂对的信息"才能判得准。可问题来了——**到底该喂什么信息进去？喂多了模型会"读着读着就丢了"，喂少了它又判不准；信息从哪检索、怎么组织、怎么压缩，才能让每个决策点都拿到刚好够用的上下文？** 这正是决定一个 Agent 成败的、最被低估的一层。业界一个被反复验证的发现是：大多数 Agent 的失败，是 context 的失败，而不是 model 的失败。如何设计这套"信息流系统"，正是本系列**第④篇《从 Prompt 到 Context：Agent 工程真正的决定项》**要深入的硬骨头。 我们下一篇见。 --- *本文为「企业 AI 化的四层工程体系」系列第 ③ 篇。前两篇回答了"为什么做"和"做什么"，这一篇是承上启下的"桥"——教你把一个业务流程拆解成 Agent 设计图。从下一篇起，我们将从内到外，逐层深入这套设计图背后的工程实现。*