程序、模型、RAG、Tool、Workflow、Agent 与人的分工
一句话收获：不是把任务全部 Agent 化，而是让每类能力承担适合的部分。
这个场景在解决什么问题
目标（goal）是根据任务性质形成"最小充分架构"——用最少的组件把事情做对。观察方式是沿着确定性、时效、行动、路径、责任这五个维度来分配能力。值得单独学，是因为很多人一上来就"全部 Agent 化"，结果成本高、难验证，而正确做法是让每类能力只承担它最擅长的部分。
先理清这条判断链（文字版）
先看哪些规则该交给程序，再看语义、知识、行动三件事怎么拆开，接着看固定流程与需要动态判断的流程怎么分工，最后看哪些高责任判断必须留给人。判断链是：
- 把确定性的规则（权限、状态、计算、不变量）交给程序执行。
- 把语义理解交给模型、知识检索交给 RAG、改变现实的动作交给 Tool，三者分开。
- 固定顺序交给 Workflow，只有下一步依赖环境反馈时才用 Agent。
- 把确认事实、授权、例外、独立验收、接管这些高责任判断交给人。
逐层详解
第 1 步：确定规则交给程序
原文：权限、状态、计算和业务不变量由程序执行。
白话：凡是能明确写出来的规则——谁能做什么（权限）、数据处在什么状态（状态）、数字怎么算（计算）、业务上绝不能被破坏的约束（不变量）——统统交给程序执行。
类比：像工厂流水线上固定的螺丝机，每次都拧到指定扭矩，不靠工人凭手感——确定的事交给机器最稳。
举例：报销系统里，"单笔上限 5000""审批人必须是直属上级""预算余额不足不能提交"，这些硬规则全部写在程序里强制执行。
为什么重要：可明确编码的规则需要稳定和可测试——能写死的规则就该稳定、可测试，交给程序最合适。
怎么验证（证据点）：
- 条件明确：规则的条件能说清楚。
- 结果确定：给定条件，结果确定。
- 失败可定位：出错能精确找到是哪条规则。
别踩的坑（边界）：程序不适合开放语义理解——"用户这句话什么意思"这类开放问题，程序硬编码做不来。
落地检查：确定性越高，越不需要模型自由判断——落地时自问：这事确定性有多高？越高越该交给程序，别让模型自由发挥。
第 2 步：语义、知识与行动分开
原文：模型处理开放语言，RAG 提供组织知识，Tool 读取或改变现实。
白话：三件事拆开——模型负责理解开放的语言（判断），RAG（检索增强生成）负责提供有组织的知识（依据），Tool 负责读取或改变现实世界（行动）。
类比：像一个顾问团队——模型是"动脑的判断者"，RAG 是"随时查资料的资料库"，Tool 是"动手办事的手脚"，脑子、资料、手脚各司其职。
举例：客服 Agent 里，模型理解用户"我要退款"这句话，RAG 检索出公司退款政策作为依据，Tool 调用退款接口真正把钱退掉——判断、依据、行动三分离。
为什么重要：三者分别解决判断、依据和行动——判断靠模型、依据靠 RAG、行动靠 Tool，混在一起就会乱。
怎么验证（证据点）：
- 候选判断：模型给出候选判断。
- 来源引用：RAG 给出可引用的知识来源。
- 工具回执：Tool 执行后有回执证明动作发生。
别踩的坑（边界）：检索到规则不证明动作已经发生——RAG 找到了"退款政策允许退"，不代表退款这个动作真的发生了。
落地检查：知识和行动不能混为一体——落地时严格区分"知道了什么"和"做了什么"，别把检索结果当执行结果。
第 3 步：Workflow 与 Agent 分工
原文：固定顺序交给 Workflow，下一步依赖环境反馈时才使用 Agent。
白话：如果流程是固定顺序（第一步做完做第二步，路径可预知），就用 Workflow（固定流程编排）；只有当"下一步走哪条路"依赖环境反馈、需要动态判断时，才用 Agent。
类比：像取外卖——"下单→支付→取餐"是固定流程，照着走就行（Workflow）；但"今天吃什么"要根据天气、心情、预算动态决定，才需要动脑（Agent）。
举例：一个内容发布流程"生成→审核→发布"顺序固定，用 Workflow 编排即可，便宜好验证；而"自动处理客户投诉"每一步要根据客户反馈决定下一步，才需要 Agent。
为什么重要：不必要的开放路径会增加验证和运营成本——能用固定流程的地方硬上 Agent，只会让验证和运维更贵更难。
怎么验证（证据点）：
- 路径可预定义：流程路径是否能提前定死。
- 反馈是否改路：环境反馈会不会改变下一步路径。
- 停止条件：有没有明确的停止条件。
别踩的坑（边界）：流程中使用模型节点不等于整个系统是 Agent——一个固定 Workflow 里就算用了几个模型节点（比如某步用模型生成文案），整个系统也不能叫 Agent。
落地检查：动态性只放在必要位置——落地时把"动态判断"只放在真正需要它的环节，其余能固定的都固定。
第 4 步：人承担高责任判断
原文：人确认事实、授权、例外、独立验收和接管。
白话：高责任的判断留给人——确认事实真假、授予关键权限、处理例外情况、独立验收结果、必要时接管系统，这些都得人来干。
类比：像手术室里，AI 可以分析影像、给建议，但最终"下刀不做"的决定和责任在医生——高责任判断必须人扛。
举例：报销 Agent 里，AI 可以整理发票、生成报销单建议，但"这笔特殊出差费用能不能特批"的例外授权、最终放行和验收，由财务负责人完成。
为什么重要：责任主体需要证据、否决权和时间——要担责的人必须手里有证据、有说"不"的权力、有时间做判断。
怎么验证（证据点）：
- 证据充分：给到人的证据足够做判断。
- 影响范围明确：这个决定影响多大范围，说清楚。
- 决定可追溯：谁做的决定、为什么做，能追查到。
别踩的坑（边界）：机械点击确认不构成人类监督——人只是无脑点"同意"按钮，不算真正的监督。
落地检查：人的责任位置必须具体——落地时把"人到底在哪个环节、负什么责"写得具体，不能笼统说"有人监督"。
落地可行性小结
本场景涉及的技术栈：程序（后端规则引擎/权限系统）、模型（LLM 语义理解）、RAG（检索增强生成）、Tool（外部工具调用）、Workflow（固定流程编排）、Agent（动态决策循环）、人（责任判断）。落地动作：先按"确定性"维度把规则分给程序，按"判断/依据/行动"把模型、RAG、Tool 拆开，按"路径是否固定"决定用 Workflow 还是 Agent，最后把高责任判断明确落到具体的人。常见坑：一是全部 Agent 化导致成本失控；二是把检索结果当执行结果；三是用机械点击冒充人类监督。检查点：确定性规则是否都在程序里、知识和行动是否分离、动态性是否只放在必要位置、人的责任位置是否具体。
回顾
- 确定性越高的规则越该交给程序，不需要模型自由判断。
- 模型管判断、RAG 管依据、Tool 管行动，三者不能混为一谈。
- 固定顺序用 Workflow，只有下一步依赖环境反馈时才用 Agent，动态性只放必要位置。
- 人承担确认事实、授权、例外、独立验收和接管，机械点击不构成监督。