选型不是从“用哪个框架”开始。前两问决定这件事是否值得做、需要多强的控制，第三问才轮到技术形态。把顺序倒过来，是大量 Agent 项目返工的根源。
判断顺序：三问不能颠倒
先判断真值与后果，最后才讨论框架。
第一问：真值在哪个系统里？
如果答案不在 ERP、MES、LIMS 或其他受控数据源中，先补数据与系统，不要让模型代替不存在的真值。
第二问：错了谁承担后果，多久才会发现？
客户、监管或财务承担后果且错误延迟暴露的场景，必须设置确定性关卡和人工签核。
第三问：步骤序列是否已知？
步骤已知时，应使用显式 Workflow；只有下一步必须根据运行状态动态判断时，才需要 Agent 循环。
第一问决定：这个 Agent 要不要做
Agent 擅长处理语言歧义、选择工具和组织非结构化信息，但它不能凭空创造业务真值。若报价、库存、批次状态或客户承诺没有可靠数据源，模型只能生成看起来合理的猜测。
识别出“现在不该做 Agent”，不是保守，而是避免把数据债务包装成智能。
第二问决定：关卡应该放在哪里
错误成本不能只看金额，还要看由谁承担、是否可逆、多久被发现。内部草稿当场可见，控制可以更轻；进入客户、审计、生产或付款的结果，必须有确定性校验、权限控制和人工签核。
第三问决定：Workflow 还是 Agent
如果步骤已经明确，例如按固定规则校验、计算、审批和出具报告，就应该把流程显式写出来。让模型在每一步重新决定下一步，不会增加价值，只会增加不确定性。
Agent 循环适用于路径本身未知、需要根据中间结果选择工具或继续探索的任务。即便如此，关键动作仍要受权限与关卡约束。
A / B / C：三种工程形态
A｜显式工作流 + 确定性内核
用于结果进入客户、审计、金额或合规流程的场景。模型只处理语言，大部分控制由状态图、规则和服务承担。
B｜高封装 Agent
用于探索性任务和对内草稿，让模型自主选择工具和迭代路径，错误必须低成本且容易被发现。
C｜不做成 Agent
答案由优化算法、规则引擎或报表唯一确定时，直接使用传统工程方案。
LangChain 与 LangGraph 不是阵营之争
LangChain 和 LangGraph 对应不同抽象层级。LangChain 1.0 的 `create_agent` 是高层入口，运行在 LangGraph 之上；LangGraph 提供更低层的编排、持久执行与控制。
官方迁移文档已将 `langgraph.prebuilt.create_react_agent` 标记为弃用，并建议迁移到 `langchain.agents.create_agent`。因此选型问题不是押注哪个品牌，而是团队是否需要自己控制拓扑、状态和中断点。
治理级别与工程形态是两个维度
L0–L4 回答允不允许、谁签字、数据能到哪里；A/B/C 回答控制粒度和工程投入。两者相关但不能混用。高权限场景通常需要更显式的 A 类架构，低风险探索任务可以采用 B 类；偏离默认组合时，应在 Agent 注册表中写明理由。
避免把企业绑死在单一供应商
- 通过统一模型网关管理供应商与调用策略
- 把业务规则、权限和状态保留在企业可控层
- 为关键模型与工具定义替代通道
- 把供应商切换和区域不可用纳入演练与退出条件
本文来自造达师项目方法与经验沉淀。涉及企业的内容均已匿名化和泛化，不披露客户身份及未经验证的量化结果。内容版本 1.0.0，更新于 2026-08-10。