很多人刚开始学 Agent，会先接触到 ReAct。它的思路很直观：模型先思考，然后调用工具，拿到结果后继续思考，直到完成任务。这是 Agent 最经典的模式。但如果继续往真实业务里走，很快就会发现一个问题：只靠 ReAct 不够。
比如你想做一个客服 Agent。用户问订单状态时，ReAct 很好用，模型判断需要查订单，于是调用订单工具，然后回复用户。但如果用户申请退款，事情就复杂了。退款不是简单查一下工具就结束，它可能涉及订单状态、金额大小、是否发货、是否需要人工审核、是否触发风控。
这时你会发现，Agent 编排的核心问题不是“模型会不会调用工具”，而是：
一个复杂任务，应该由谁决定下一步怎么走？是模型自由决定，还是程序流程控制？是一个 Agent 完成，还是多个 Agent 分工？失败了怎么办？关键操作要不要人确认？
Agent 编排方式，本质上就是在回答这些问题。
一、最基础的问题：模型如何一边思考一边调用工具？
最早我们遇到的问题很简单：大模型本身不能访问外部世界。
它不知道实时天气，不能查数据库，不能读公司内部文档，也不能真正执行代码。要让模型具备行动能力，就需要给它工具。
于是就有了最经典的 Agent 编排方式：ReAct。
ReAct 可以理解为 Reasoning + Acting，也就是“推理 + 行动”。模型先根据用户问题判断下一步要做什么，如果需要外部信息，就调用工具；拿到工具结果后，再继续判断，直到可以回答用户。
flowchart TD
A[用户问题] --> B[LLM 思考]
B --> C{是否需要调用工具}
C -- 是 --> D[调用工具]
D --> E[观察工具结果]
E --> B
C -- 否 --> F[输出最终答案]
比如用户问：
帮我查一下订单 1001 的物流状态。
Agent 可能会先判断“我需要查询订单”，于是调用 query_order(1001)；如果发现订单已发货，再调用 query_logistics(1001)；最后结合物流结果回复用户。
ReAct 的优点是灵活。它不需要你提前写死所有步骤，模型可以根据任务动态决定下一步。所以它很适合搜索、问答、代码辅助、数据查询这类开放式任务。
但 ReAct 的问题也很明显：下一步主要由模型决定，流程不够稳定。
如果只是查订单，这没问题；但如果是退款、审批、医疗、金融、风控，就不能完全相信模型自由决策。因为这些场景里，流程必须可控。
这就引出了第二种模式--Workflow。
二、当流程必须可控时：Workflow / State Machine
在企业业务里，很多任务不是“模型想怎么做就怎么做”，而是必须按照明确流程执行。
比如退款流程，通常不是一句“帮我退款”就直接退款，而是要先查订单，再判断订单状态，再判断是否已发货，再判断金额是否超过阈值，必要时还要人工审核。
这个时候，更适合用 Workflow / State Machine，也就是工作流或状态机模式。
它的核心思想是：
流程由程序控制，模型只负责其中某些节点上的理解、判断或生成。
flowchart TD
A[用户申请退款] --> B[识别用户意图]
B --> C[查询订单状态]
C --> D{订单是否已发货}
D -- 未发货 --> E[自动退款]
D -- 已发货 --> F[提示用户退货后退款]
E --> G{金额是否过大}
G -- 是 --> H[进入人工审核]
G -- 否 --> I[完成退款]
这种模式和 ReAct 的区别很大。
ReAct 是模型主导：模型决定下一步做什么。
Workflow 是流程主导：开发者提前定义好步骤和分支，模型只在需要的地方参与。
这也是为什么 LangGraph 很适合企业级 Agent。它的 State、Node、Edge、Conditional Edge 本质上就是为了表达这种流程：状态里保存订单、意图、金额、审核标记；节点负责查订单、判断规则、生成回复；条件边决定下一步走哪里。
所以，当你的 Agent 开始涉及审批、退款、风控、合同审核、工单流转时，就不要只靠 ReAct，而应该考虑工作流或状态机。
一句话总结：
ReAct 适合开放探索，Workflow 适合确定流程。
三、当用户问题类型很多时：Router 模式
再继续复杂一点，你会遇到另一个问题：用户的问题不止一种。
比如一个客服系统里，用户可能问订单、退款、发票、物流、售后、活动规则。你不可能让所有问题都进入同一个流程，否则系统会越来越乱。
这时就需要 Router，也就是路由分发模式。
Router 的核心是：
先判断用户问题属于哪一类，再分发给对应的 Agent、工具或流程。
flowchart TD
A[用户输入] --> B[Router 意图识别]
B --> C{问题类型}
C -- 订单问题 --> D[订单 Agent]
C -- 退款问题 --> E[退款工作流]
C -- 知识问题 --> F[RAG 知识库问答]
C -- 投诉问题 --> G[人工客服或复杂工单流程]
C -- 其他 --> H[兜底回复]
Router 模式通常是企业 Agent 的入口层。
比如你的 TalkRoom 心理咨询系统也可以这样设计：
flowchart TD
A[用户输入] --> B[Router 判断输入类型]
B --> C{类型}
C -- 普通倾诉 --> D[对话 Agent]
C -- 心理知识问题 --> E[RAG 检索 Agent]
C -- 高风险表达 --> F[风险评估流程]
C -- 阶段性总结 --> G[总结 Agent]
C -- 语音输入 --> H[ASR 转写后进入文本流程]
Router 的好处是让系统结构更清晰。不同任务进入不同流程，而不是所有问题都塞给一个万能 Agent。
不过 Router 一般不会单独存在，它通常和 ReAct、Workflow、RAG、多 Agent 一起使用。比如订单问题走 ReAct 调工具，退款问题走 LangGraph 工作流，知识问题走 RAG，高风险问题进入人工审核。
一句话总结：
当问题类型变多时，不要让一个 Agent 硬扛所有任务，而应该先路由，再处理。
四、当任务很长时：Plan-and-Execute
前面的模式解决了工具调用、流程控制和任务分发。但还有一种任务更麻烦：目标很明确，但过程很长。
比如用户说：
帮我调研 LangChain、LangGraph、DeepAgents、CrewAI，并写一份选型报告。
这个任务不是查一次工具就能完成，也不是一个固定流程。它需要先拆任务，再分别调研，再整理对比，最后写报告。
这时就适合 Plan-and-Execute，也就是“先规划，再执行”。
flowchart TD
A[用户提出复杂目标] --> B[Planner 制定计划]
B --> C[Executor 执行第 1 步]
C --> D[Executor 执行第 2 步]
D --> E[Executor 执行第 3 步]
E --> F{是否需要重新规划}
F -- 是 --> B
F -- 否 --> G[整理结果并输出]
它和 ReAct 的区别在于，ReAct 更像“边走边想”，Plan-and-Execute 更像“先画路线图，再一步步执行”。
比如一个调研 Agent 可能先生成计划：
1. 查询 LangChain 的核心能力
2. 查询 LangGraph 的核心能力
3. 查询 DeepAgents 的核心能力
4. 对比适用场景
5. 写成技术选型报告
然后再执行每一步。
这种模式适合研究报告、竞品分析、旅行规划、论文总结、代码库理解、长文档处理。
但它也有一个问题：计划可能一开始就不准确。
所以更成熟的实现通常会加入 Replan，也就是执行过程中根据新信息重新调整计划。DeepAgents 就明显带有这种思想，它不仅支持任务规划，还支持文件系统、子 Agent 和上下文管理，很适合长任务。
一句话总结：
当任务不是一步能完成时，先规划再执行，会比单纯 ReAct 更稳定。
五、当信息来自知识库时：RAG + Agent
很多企业 Agent 的核心不是执行动作，而是回答知识问题。
比如用户问：
公司报销制度里，出差住宿标准是多少？
模型本身不知道你公司的制度。它必须先检索内部文档，再根据文档回答。这就是 RAG，也就是检索增强生成。
普通 RAG 的流程是：
flowchart TD
A[用户问题] --> B[检索知识库]
B --> C[返回相关文档片段]
C --> D[LLM 基于文档生成回答]
但 Agentic RAG 会更进一步。它不是每次都机械检索，而是让 Agent 判断要不要检索、检索哪个知识库、是否需要多轮检索、是否还要调用其他工具。
flowchart TD
A[用户问题] --> B[Agent 判断是否需要检索]
B --> C{是否需要知识库}
C -- 否 --> D[直接回答]
C -- 是 --> E[选择知识库]
E --> F[检索文档]
F --> G{结果是否足够}
G -- 不足 --> E
G -- 足够 --> H[结合文档生成回答]
比如一个企业助手可能同时有产品文档、售后文档、研发文档、法务文档。Agent 需要先判断用户问题属于哪个领域，再去对应知识库检索。
LlamaIndex 和 Haystack 更偏 RAG，LangChain 也能做 RAG，LangGraph 可以把复杂 RAG 流程编排得更清楚。
一句话总结：
当答案不在模型参数里，而在企业文档里时，就需要 RAG；当检索过程本身也需要决策时，就变成 Agentic RAG。
六、当一个 Agent 不够用时：Multi-Agent
随着任务继续复杂，你会发现一个 Agent 做所有事会越来越吃力。
比如写一份技术报告，一个 Agent 要负责查资料、分析、写作、审稿。如果所有事情都塞给同一个上下文，信息会很乱，角色也不清晰。
于是就有了 Multi-Agent，也就是多 Agent 协作。
它的核心思想是：
把复杂任务拆给多个不同角色的 Agent，每个 Agent 只负责自己擅长的部分。
flowchart TD
A[用户任务] --> B[Manager Agent]
B --> C[Research Agent 查资料]
B --> D[Analysis Agent 做分析]
B --> E[Writer Agent 写文章]
B --> F[Reviewer Agent 审稿]
C --> G[汇总结果]
D --> G
E --> G
F --> G
G --> H[最终输出]
多 Agent 常见形式有几种。
一种是主管-员工模式：Manager Agent 负责任务拆解和分配，其他 Agent 负责执行。
一种是流水线模式：Research → Analyze → Write → Review，每个 Agent 处理上一个 Agent 的结果。
还有一种是辩论模式：多个 Agent 从不同角度提出意见，最后由一个裁判 Agent 总结。
多 Agent 的好处是分工清晰，适合复杂任务；缺点也很明显：成本更高、延迟更高、上下文管理更复杂，而且多个 Agent 可能互相强化错误。
所以企业里不要为了多 Agent 而多 Agent。只有当任务真的需要角色分工时，才有必要引入。
CrewAI、AutoGen、DeepAgents 都偏向支持多 Agent。LangGraph 也可以实现多 Agent，而且流程更可控。
一句话总结：
当任务天然需要分工时，多 Agent 才有价值；否则一个清晰的工作流往往更稳定。
七、当结果需要检查时：Reflection / Critic
即使 Agent 能完成任务，也不代表结果一定可靠。
比如写代码，第一次生成的代码可能有 bug；写报告，可能逻辑不清；做总结，可能遗漏重点。为了提升质量，可以加入 Reflection / Critic，也就是反思或审查模式。
它的流程是：
flowchart TD
A[生成初稿] --> B[Critic 检查问题]
B --> C{是否需要修改}
C -- 是 --> D[根据反馈修改]
D --> B
C -- 否 --> E[输出最终结果]
比如代码 Agent 可以这样设计：
flowchart TD
A[Coder Agent 写代码] --> B[运行测试]
B --> C{测试是否通过}
C -- 否 --> D[Reviewer Agent 分析错误]
D --> A
C -- 是 --> E[输出代码结果]
Reflection 的价值是提高质量，尤其适合写作、代码生成、复杂推理、报告生成。
但它也不是万能的。Critic 本身也是模型，也可能判断错。而且每多一轮检查，就会增加成本和延迟。因此它更适合对质量要求高的任务，不适合所有场景都默认开启。
一句话总结：
当一次生成不够可靠时，可以让 Agent 先做，再检查，再修改。
八、当操作有风险时：Human-in-the-loop
企业级 Agent 最不能忽略的是安全。
很多操作不能让模型直接执行，比如退款、删除文件、发送邮件、修改数据库、发布代码、调整权限、给出高风险医疗或法律建议。
这时需要 Human-in-the-loop，也就是人在环路中。
它的核心思想是：
Agent 可以自动完成大部分流程，但关键节点必须暂停，等待人确认。
flowchart TD
A[Agent 生成操作方案] --> B{是否高风险}
B -- 否 --> C[自动执行]
B -- 是 --> D[暂停并请求人工确认]
D --> E{人工是否批准}
E -- 批准 --> C
E -- 拒绝 --> F[取消或修改方案]
比如代码 Agent 准备删除文件时，不能直接执行；退款 Agent 遇到大额退款时，也不能自动通过；心理咨询系统识别到高风险表达时，更应该进入人工介入或安全提示流程。
Human-in-the-loop 不是降低自动化，而是让自动化更可信。
LangGraph 非常适合实现这种模式，因为它可以在任意节点中断、保存状态、等待人处理后继续。DeepAgents 也内置支持这类能力。
一句话总结：
只要涉及钱、权限、删除、发布、合规和人身安全，就应该考虑人在环路中。
九、当任务由事件触发时：Event-driven Agent
前面讲的多数 Agent 都是用户主动提问，然后 Agent 回答。但真实企业系统里，Agent 不一定只在聊天窗口里工作。
它也可以由事件触发。
比如：
新工单创建后，Agent 自动分类。
用户差评出现后，Agent 自动总结原因。
服务报警后，Agent 自动分析日志。
代码提交后，Agent 自动 Review。
每天早上，Agent 自动生成销售日报。
这就是 Event-driven Agent，事件驱动 Agent。
flowchart TD
A[业务事件发生] --> B[消息队列 / Webhook / 定时任务]
B --> C[触发 Agent]
C --> D[读取上下文和相关数据]
D --> E[执行分析或操作]
E --> F[写回业务系统或通知用户]
这种模式很适合企业自动化、运维、监控、CRM、销售助手、日报生成。
这里的重点不是某个 Agent 框架，而是系统架构。你通常需要后端服务负责接收事件，用 Kafka、Redis Stream、消息队列或定时任务触发 Agent，再用 LangGraph 或 LangChain 执行具体流程。
一句话总结：
当 Agent 不再只是聊天助手，而是业务系统里的智能处理节点时，就会进入事件驱动模式。
十、Harness 到底是什么？
讲完这些编排方式后，还需要补一个最近经常被提到的概念：Harness。这个词直译过来有“马具、挽具、安全带、系带”的意思。它的核心含义不是某个单独工具，而是把一些东西连接起来、约束起来，并让它们稳定工作的一套装置。
比如马车里的 harness，会把马和车连接起来，让马的力量稳定传递到车上；安全带也是一种 harness，它不是发动机，也不是驾驶员，但它让整个系统更安全、更可控。
放到 Agent 里，Harness 也是类似的角色。
LangChain 官方给过一个很简洁的公式：
Agent = Model + Harness
这个公式的意思是：模型本身还不是完整 Agent。只有当模型被放进一套运行框架里，能使用工具、接收上下文、保存状态、执行流程、处理错误、接受人工确认时，它才变成一个真正可运行的 Agent。
所以可以这样理解：
模型是大脑，工具是手脚，编排方式是做事方法，而 Harness 是把模型、工具、状态、记忆、权限、上下文和执行流程连接起来的运行框架。
如果没有 Harness，模型只是一个可以生成文本的模型；有了 Harness，它才变成一个能在系统里完成任务的 Agent。
flowchart TD
A[用户任务] --> B[Agent Harness]
B --> C[模型]
B --> D[工具]
B --> E[记忆]
B --> F[状态管理]
B --> G[权限控制]
B --> H[人工确认]
B --> I[上下文管理]
B --> J[日志观测]
C --> B
D --> B
E --> B
F --> B
G --> B
H --> B
I --> B
J --> B
B --> K[最终结果]
注意，Harness 和编排方式不是一回事。
编排方式回答的是：任务应该怎么组织。 比如 ReAct、Workflow、Router、Plan and Execute、Multi Agent，这些都是编排模式。
Harness 回答的是：Agent 系统怎么运行。 比如怎么保存状态，怎么调用工具，怎么处理失败，怎么做人工确认，怎么管理上下文，怎么追踪执行过程。
所以，编排方式更像方法论，Harness 更像运行时。
十一、为什么 Harness 很重要？
在简单 Demo 里，你可能感觉不到 Harness 的价值。因为 Demo 通常只有一个模型、一个工具、一次调用。
但真实企业项目不是这样。
比如一个退款 Agent，用户说：
我要退订单 1001。
系统可能要做很多事情：先识别用户意图，再查询订单状态，再判断是否已发货，再判断金额是否过大，再决定是否人工审核，最后生成回复并记录整个过程。
这时你需要的不只是一个 prompt，而是一个稳定的运行框架。
flowchart TD
A[用户申请退款] --> B[Harness 接收任务]
B --> C[读取会话状态]
C --> D[执行退款流程]
D --> E[调用订单工具]
E --> F[更新状态]
F --> G[判断风险]
G --> H[进入人工确认]
H --> I[等待人工处理]
I --> J[继续执行]
J --> K[生成回复]
K --> L[记录日志]
没有 Harness，你就要自己处理这些问题：工具调用失败怎么办，用户中途补充信息怎么办，流程执行到一半服务重启怎么办，上下文太长怎么办，危险操作怎么拦截，执行过程怎么追踪，不同 Agent 之间怎么共享状态。
所以，Harness 的本质是把 Agent 从“能跑的 Demo”推进到“能落地的系统”。
十二、用记忆管理理解 Harness
记忆管理很适合解释 Harness。
假设用户说：
以后我写技术博客，希望语言自然流畅一点，不要像知识点罗列。
这句话可能值得长期记住。但“记住”不是一句话就能完成的事情。一个完整的记忆流程至少包括：加载当前会话状态、读取相关历史记忆、组装模型上下文、调用模型生成回复、判断是否产生新记忆、写入长期记忆存储、保存本轮状态。
flowchart TD
A[用户输入] --> B[加载当前会话状态]
B --> C[读取相关历史记忆]
C --> D[组装模型上下文]
D --> E[调用模型生成回复]
E --> F[判断是否产生新记忆]
F --> G[写入长期记忆存储]
G --> H[保存本轮状态]
这里要区分三件事。
第一，记忆策略回答的是：什么值得记。比如用户是否明确要求记住，这个偏好是否长期有效，是否会影响未来回答，是否涉及隐私和安全边界。
第二，存储系统回答的是：记忆放在哪里。比如数据库、Redis、向量库、LangGraph Store，或者用户画像表。
第三，Harness 回答的是：这些记忆如何参与 Agent 的每次运行。比如每次对话开始时，根据 user_id 或 thread_id 找到相关记忆；调用模型前，把相关记忆注入上下文；模型回复后，判断是否要更新记忆；本轮执行结束后，保存短期状态；下次用户回来时，恢复上下文继续对话。
一句话说：
记忆策略决定记什么，存储系统决定放哪里，Harness 决定记忆如何在每次 Agent 运行中被读取、注入、更新和保存。
这也是为什么不能把 Harness 简单理解成“记忆管理流程”或“某段具体代码”。它更准确地说，是把记忆、状态、工具、模型调用这些能力接入 Agent 执行循环的运行框架。
十三、Harness 和 LangChain、LangGraph、DeepAgents 的关系
理解 Harness 后，再看 LangChain、LangGraph、DeepAgents，就更清楚了。
LangChain 的 create_agent 是轻量 Harness。 它帮你把模型、工具、系统提示词和 Agent 执行循环组织起来。你不用自己写“模型什么时候调用工具、工具结果怎么返回给模型、最后怎么输出答案”这些基础流程。它适合快速实现 ReAct 和普通工具调用型 Agent。
LangGraph 是编排型 Harness。 它更关注状态、节点、边、条件分支、持久化、人工介入和恢复执行。它适合复杂业务流程，比如退款审批、风控审核、工单流转、医疗预问诊。
DeepAgents 是复杂任务 Harness。 它在 LangGraph 之上进一步封装了任务规划、文件系统、子 Agent 和上下文管理。它适合研究报告、代码助手、长文档分析、复杂调研这类长任务。
可以这样理解：
flowchart TD
A[Agent Harness] --> B[LangChain]
A --> C[LangGraph]
A --> D[DeepAgents]
B --> E[轻量工具调用]
C --> F[复杂流程编排]
D --> G[复杂长任务执行]
所以这三个框架不是简单的替代关系，而是不同层次的 Harness。
如果你只是想让模型调用工具，LangChain 就够了。
如果你想精确控制流程，LangGraph 更合适。
如果你想做长任务执行，DeepAgents 更省事。
十四、Harness 和编排方式怎么配合？
理解 Harness 之后，要明确一个关系：
编排方式是设计模式，Harness 是运行框架，具体框架是 Harness 的产品化实现。
也就是说，编排方式回答“任务怎么组织”，Harness 回答“Agent 怎么运行”，框架回答“用什么工具落地”。
flowchart TD
A[编排方式] --> B[任务怎么组织]
C[Harness] --> D[Agent 怎么运行]
E[具体框架] --> F[用什么工具落地]
A --> C
C --> E
一个 Harness 可以支持多种编排方式。反过来，一种编排方式也可以在不同 Harness 上实现。
比如 LangChain 的 create_agent 是一个轻量 Harness，适合快速实现 ReAct 和普通工具调用。LangGraph 是一个编排型 Harness，适合实现 Workflow、Router、Human in the loop、Reflection 等复杂流程。DeepAgents 是一个复杂任务 Harness，更偏 Plan and Execute、Multi Agent、文件系统和长上下文管理。
flowchart TD
A[Agent Harness] --> B[ReAct]
A --> C[Workflow]
A --> D[Router]
A --> E[Plan and Execute]
A --> F[Multi Agent]
A --> G[Reflection]
A --> H[Human in the loop]
A --> I[RAG Agent]
所以不要把框架和编排方式一一绑定。更准确地说，是不同框架更擅长承载不同编排方式。
LangChain 更擅长快速工具调用。
LangGraph 更擅长复杂流程控制。
DeepAgents 更擅长复杂长任务执行。
CrewAI 更擅长多角色协作。
LlamaIndex 和 Haystack 更擅长 RAG。
编排方式决定 Agent 怎么做事，Harness 决定 Agent 怎么跑起来，框架决定你用什么代码把它落地。
做选型时，不要先问“用哪个框架”，而要先问：这个任务是简单工具调用、固定业务流程、长任务执行、多 Agent 协作，还是知识库检索？这个问题想清楚了，框架选择就自然了。
总结
前面讲的所有编排方式，本质上都是在解决 Agent 做事过程中的不同问题。
一开始的问题是模型不能行动，所以有了 ReAct。
当流程必须可控时，需要 Workflow。
当用户问题类型变多时，需要 Router。
当任务很长时，需要 Plan and Execute。
当答案依赖企业知识时，需要 RAG Agent。
当一个 Agent 不够用时，需要 Multi Agent。
当结果需要检查时，需要 Reflection。
当操作有风险时，需要 Human in the loop。
当任务由业务事件触发时，需要 Event driven Agent。
而 Harness 解决的是另一个层面的问题：
这些编排方式真正跑起来时，需要一个稳定的运行环境。
最后用一句话收尾：
Agent 编排方式决定任务怎么组织，Harness 决定 Agent 怎么运行，框架则把这些思想落成可用的工程工具。
这样，LangChain、LangGraph、DeepAgents 的关系就清楚了。
LangChain 是轻量Agent的 Harness，适合快速接模型和工具。
LangGraph 是底层编排 Harness，适合复杂流程和状态控制。
DeepAgents 是复杂任务 Harness，适合长任务、规划、文件系统和子 Agent。
当开发Agent系统时，要考虑当前任务需要哪种编排方式？这个编排方式需要什么样的 Harness？哪个框架能最快、最稳地帮我实现它？
参考
docs.langchain.com/oss/python/…
