编排模式

编排模式是 Harness 中“上下文与工具”层面的组织方式——它决定了上下文如何在 LLM 调用之间流动、工具如何被调度、以及 agent 的执行路径是预先设定还是动态生成。根据 Anthropic 与数十个团队合作构建 LLM agent 的经验，最成功的实现往往不是使用复杂的框架，而是采用简单、可组合的模式。

在构建 LLM 应用时，应遵循“从简单到复杂”的原则：首先考虑单个 LLM 调用——如果通过优化提示词和上下文示例就能解决问题，就不要引入 agent 系统；当需要多步骤处理时，对于可以清晰分解为固定子任务的场景，考虑使用工作流；只有当需要动态决策和灵活的执行路径时，才使用自主 agent。需要记住的是：agent 系统通常会用延迟和成本换取更好的任务性能，应该谨慎权衡这种交换是否值得。

工作流模式：确定性的编排

工作流（Workflow）是通过预定义的代码路径来编排 LLM 和工具的系统。它的执行路径是确定性的，由开发者预先设计好——每一步做什么、下一步去哪里，都是代码写死的，LLM 只在每个节点内部负责理解和生成。

以一个订机票 agent 为例，工作流可以设计为四个固定节点：核实用户身份 → 搜索可用航班 → 完成付款 → 确认预订。每个节点内部可以使用 LLM（例如用自然语言理解用户的出行需求），但节点之间的流转顺序是代码固定的——系统不会在付款完成之前去预订座位，也不会在身份核实之前开始搜索航班。

工作流模式有两个核心优势。第一是严格的流程控制：开发者可以确保关键步骤不被跳过或乱序执行，例如“付款前不能预订”这类业务规则通过代码强制执行，不依赖 LLM 的判断。第二是安全性：由于执行路径是确定的，提示注入或模型犯错最多只能影响当前节点内部的处理，无法让 agent 跳到不该执行的分支——攻击面被限制在单个节点内。工作流的主要局限是缺乏变通性：当出现预设流程未覆盖的情况时（例如用户在付款环节临时想改签），固定的节点路径无法灵活应对，只能走预设的异常处理分支或将控制权交还给人类。

自主 Agent：动态自主决策

当工作流的固定路径无法满足需求时，我们就需要自主 Agent（Autonomous Agent）。自主 agent 与工作流的核心区别在于：执行路径不是预先定义的，而是 agent 根据环境反馈实时决定的。

仍以订机票为例：自主 agent 不需要预定义四个固定节点。用户说“帮我订下周三去上海的机票”，agent 会自行决定先搜索航班、发现需要登录、于是先核实身份、再回来搜索、发现最便宜的航班需要转机、主动询问用户是否接受、用户说不要转机、agent 调整搜索条件……

这意味着自主 agent 需要具备自主规划的能力——自主决定执行步骤，还需要能识别失败、调整策略，而不只是在出错时停下来。但自主性不等于无限制——必须设计明确的停止条件（任务完成、达到最大迭代次数或遭遇不可恢复的错误），否则 agent 容易陷入死循环或过度执行。从实现角度看，自主 agent 本质上就是在一个循环中使用工具的 LLM，通过持续获取环境反馈来推进任务——这正是前面介绍的 ReAct 循环。它特别适用于开放式的问题——这类问题难以或不可能预测所需的步骤数量，典型场景包括 Coding Agent 解决 SWE-bench 任务、Computer Use、以及需要迭代搜索和分析的研究任务。不过，自主性也带来了更高的成本和潜在的复合错误风险，因此部署时必须在沙盒环境中充分测试，设置适当的护栏和监控机制，并在关键决策点考虑加入人机协作的检查点。

两种模式的选择与混合

实践中，工作流和自主 agent 并非非此即彼——很多系统会混合使用两种模式：关键的、有严格合规要求的流程用工作流来确保可靠性，需要灵活决策的部分切换到自主模式。例如 n8n 这类可视化工作流平台，可以在同一个系统中同时使用工作流节点和自主 agent 节点。

随着“模型即 agent”趋势的深化，框架的核心价值已经不再局限于“编排 LLM 调用”——模型越来越能自主决策，但围绕模型构建的上下文管理、工具生态、安全约束和错误恢复等 Harness 工程反而变得更加重要。选择框架时，关键考量不在于框架本身的复杂度，而在于它能否以最小的抽象层让你专注于业务逻辑。

相关阅读

• Harness 工程——编排模式是 Harness 里“上下文与工具”的组织方式。
• 委派模式——把编排从单 agent 扩展到多 agent 的判断框架。