【Agent智能体设计与工作流实战：从任务拆解到可靠执行】如何把业务需求拆成智能体能力：区分模型判断、工具操作与人工确认

如何把业务需求拆成智能体能力：区分模型判断、工具操作与人工确认

客服负责人提出一个需求：

“用户问订单问题时，让 Agent 自动判断情况，能处理的直接处理，处理不了再找人工。”

这句话对产品经理来说很自然，对工程师来说却远远不够。

因为“自动判断”“直接处理”“找人工”分别对应完全不同的系统能力：

• 模型判断：理解用户意图、判断信息是否足够、选择下一步。
• 工具操作：查询订单、读取库存、创建工单、修改数据。
• 人工确认：在退款、取消订单等高风险动作发生前暂停，让人决定是否继续。

如果没有把三者拆开，最终很容易出现两类问题：

一类是 Agent 什么都要问人工，自动化价值很低；另一类是 Agent 拿到了过大的工具权限，把“判断应该怎么做”直接变成了“自己有权做什么”。

本文用一个虚构的订单异常处理 Agent作为完整案例，从一条业务需求开始，把它拆成模型能力、工具能力和人工确认三个部分，并最终形成一份可以交给产品、算法和工程团队共同使用的能力设计表。

一、先明确一个核心原则：判断权不等于执行权

智能体（Agent）可以理解为：

能够利用模型理解上下文、调用工具、根据中间结果决定下一步行动的应用系统。

这里最容易产生误解：

Agent 能判断某件事情应该发生，不代表 Agent 就应该拥有执行这件事情的权限。

例如：

用户： “我的订单两天没到，帮我看看。” Agent 判断： “需要查询物流。” 这是模型判断。 Agent 调用： query_logistics(tracking_no) 这是工具操作。 如果物流异常： “需要退款。” 这是模型判断。 但如果退款属于高风险动作： ```text 模型判断 ↓ 需要退款 ↓ 人工确认 ↓ 批准 ↓ refund_order()

这里就形成了三个不同的责任层次。

这个分层非常重要。

OpenAI 当前 Agent 文档也把 Agent 的指令、工具、Guardrails（护栏）以及人工审批视为不同的运行组成部分；其中人工审批可以在工具真正执行前暂停运行，让人批准或拒绝敏感操作。(OpenAI Developers)

二、从一句业务需求开始拆

假设产品需求是：

“用户投诉订单没有收到时，Agent 自动查询订单和物流。如果确认是物流异常，可以帮用户创建售后工单；如果涉及退款，则交给人工确认。”

这是一个比较典型的 Agent 需求。

但它仍然不是工程规格。

我们把它拆成五个问题：

因此，业务需求真正需要转换成的是：

业务目标 ↓ 判断任务 ↓ 工具任务 ↓ 人工决策点 ↓ 停止条件 ↓ 验收标准

而不是直接写成一条很长的 Prompt。

三、第一层：什么应该交给模型判断

模型最适合承担的是语义理解和需要上下文判断的决策。

在我们的订单案例中，可以让模型判断：

1. 用户到底想解决什么

例如：

“我那个订单怎么还没到？”

模型可以识别为：

intent = order_delivery_issue

而不是让业务代码通过几十条关键词规则判断。

2. 用户有没有提供必要信息

例如：

“我的订单有问题，帮我看看。”

模型可以判断：

intent = order_delivery_issue order_id = null

然后进入：

要求用户提供订单号

而不是随便猜一个订单。

3. 下一步应该查询什么

例如：

订单状态 = shipped tracking_no = DE20260928001

模型可以判断：

下一步需要查询物流。

于是调用：

query_logistics( tracking_no="DE20260928001" )

4. 现有证据是否足够

例如物流返回：

{"logistics_status":"exception","exception_code":null}

模型可以判断：

已知存在异常，但没有足够证据判断具体原因。

于是可以进入：

create_ticket

但不应该自己补出：

“包裹已经丢失。”

四、第二层：什么必须变成工具

如果一个动作涉及外部真实数据，就不要让模型“想象自己完成了”。

例如：

查询订单 查询物流 查询库存 创建工单 退款 取消订单 修改地址

这些都应该通过工具完成。

工具的核心意义不是“让 Agent 更强”，而是：

把模型的语言决策连接到可验证的真实系统操作。

例如：

query_order(order_id)

返回：

{"order_id":"A20260928001","order_status":"shipped","tracking_no":"DE20260928001"}

模型只能根据这个结果判断下一步。

而不能自己生成：

order_status = delivered

来假装系统已经查询过。

五、第三层：什么必须交给人工

最简单的判断方法是看这个动作是否具有：

• 较高业务风险；
• 不可逆性；
• 财务影响；
• 权限影响；
• 用户权益影响；
• 模型难以独立验证的后果。

例如：

这里最重要的不是“所有写操作都必须人工确认”。

而是：

根据动作风险设计人工确认点。

OpenAI 当前 Guardrails 与 Human Review 文档明确把取消、编辑、Shell 命令、敏感 MCP 操作等具有副作用的动作列为适合在工具执行前进行人工审批的场景。(OpenAI Developers)

六、建立完整的能力拆分表

现在把前面的业务需求转换成工程设计。

假设案例输入为：

customer_id = C10001 user_message = “我的订单 A20260928001 两天没收到， 如果真是物流问题就帮我处理一下。”

全部数据均为虚构。

对应能力可以设计成：

到这里，业务需求已经从一句话变成了一个能力图谱。

七、不要让模型直接决定工具参数

这是进一步拆解时很容易遗漏的一点。

假设退款工具：

refund_order( order_id, amount, reason )

模型判断：

用户应该退款。

并不意味着模型可以直接决定：

amount = 99999

更合理的流程是：

模型判断： refund_required = true ↓ 系统读取订单真实金额： order_amount = 199 ↓ 人工确认： 是否退款 199 元？ ↓ 批准 ↓ refund_order( order_id="A20260928001", amount=199 )

也就是说：

模型可以提出动作建议，但关键参数应该尽可能由可信数据源提供。

这也是为什么 Agent 系统不能只设计 Prompt。

八、把一个完整 Agent 拆成三种节点

现在可以把整个案例组织成：

用户输入 ↓ [模型判断] 识别 intent / order_id ↓ [工具操作] query_order ↓ [模型判断] 判断是否查询物流 ↓ [工具操作] query_logistics ↓ [模型判断] 判断问题类型 ↓ ┌───────────────┬────────────────┐ ↓ ↓ ↓ 无需处理 创建工单 退款 ↓ ↓ ↓ 回复用户 create_ticket 人工确认 ↓ 批准/拒绝 ↓ refund_order

这就是业务需求转 Agent 架构时最实用的一张图。

九、完整示例：订单异常处理 Agent

9.1 输入

{"customer_id":"C10001","user_message":"我的订单 A20260928001 两天没收到，如果真是物流问题就帮我处理一下。"}

9.2 工具定义

本文采用平台无关的工具设计，不是 Dify、扣子或其他平台的可直接导入配置。

query_order

输入： order_id 输出： order_id order_status sku tracking_no order_amount

query_logistics

输入： tracking_no 输出： tracking_no logistics_status last_event event_time exception_code

create_ticket

输入： order_id reason 输出： ticket_id

refund_order

输入： order_id amount reason 输出： refund_id

这个工具属于高风险写操作。

因此不能由模型直接执行。

十、模型需要输出什么

不要让模型每一步都输出一大段自然语言。

可以设计结构化中间结果：

{"intent":"order_delivery_issue","order_id":"A20260928001","next_action":"query_order","reason":"用户要求调查订单未收到问题"}

查询订单后：

{"order_id":"A20260928001","next_action":"query_logistics","reason":"订单状态为 shipped，存在物流单号"}

物流异常后：

{"issue_type":"logistics_exception","evidence_level":"insufficient","next_action":"create_ticket"}

如果发现用户要求退款：

{"refund_required":true,"next_action":"human_approval"}

这样比：

“我认为接下来应该查询物流……”

更容易被系统验证。

OpenAI 当前安全文档也建议在 Agent 工作流中使用结构化字段限制不可信文本对后续节点的影响，并通过 Guardrails、工具确认等方式降低意外工具调用风险。(OpenAI Developers)

十一、模型判断、工具操作、人工确认的责任边界

可以进一步明确三者的责任。

模型负责

理解 分类 判断 规划 选择下一步 解释结果

工具负责

读取真实数据 执行真实操作 返回真实结果 执行权限检查

人工负责

高风险决策 模糊业务判断 特殊例外 不可逆操作 超出自动化范围的处理

因此，一个比较合理的 Agent 架构是：

┌──────────────┐ │ 模型 │ │ 理解/判断/规划 │ └──────┬───────┘ │ 决定调用哪个能力 │ ┌────────────┴────────────┐ ↓ ↓ ┌──────────────┐ ┌────────────────┐ │ 工具操作 │ │ 人工确认 │ │ 查询/写入系统 │ │ 高风险决策/审批 │ └──────┬───────┘ └───────┬────────┘ │ │ └────────────┬────────────┘ ↓ 返回真实结果 ↓ 模型判断

十二、什么时候应该增加人工确认

可以用一个简单的四维判断法。

维度一：是否产生真实副作用

例如：

查询订单 → 没有副作用 创建工单 → 有业务写入 退款 → 有财务副作用

副作用越强，越应该考虑确认。

维度二：是否容易撤销

查询 → 可忽略 创建工单 → 通常可以关闭 退款 → 可能涉及资金处理

越难撤销，越需要控制。

维度三：是否影响用户权益

例如：

退款 订单取消 价格修改 账号权限修改

这类动作不能仅因为模型“觉得应该做”就自动执行。

维度四：模型能否自行验证结果

如果模型无法可靠判断：

“这个退款是否真的应该执行？”

那么应该把决策点交给人工。

OpenAI 的实践指南也建议针对工具的读写性质、可逆性、权限要求和财务影响进行风险分级，并在高风险动作上加入人工干预。(OpenAI)

十三、人工确认不是“让人重新做一遍”

设计得好的 Human-in-the-loop（人在环路中）并不是：

Agent 做一步 ↓ 问人 ↓ Agent 做一步 ↓ 再问人

这样自动化价值会快速下降。

合理的方式是：

Agent 完成低风险调查 ↓ 形成结构化决策请求 ↓ 人工只确认关键动作 ↓ 批准/拒绝 ↓ Agent继续执行

例如退款审批界面只需要给出：

订单：A20260928001 退款金额：199 元 原因：物流异常 证据：物流状态 exception，连续两次异常记录 动作：退款 199 元 [批准] [拒绝]

而不是把整个 Agent 的上下文重新交给人工阅读。

如果使用支持审批中断的 Agent SDK，人工审批可以作为一次暂停，批准或拒绝后从原运行状态继续，而不是重新开启一个全新的任务。(OpenAI Developers)

十四、失败案例：模型判断正确，但工具权限不够

假设用户说：

“物流异常，直接给我退款。”

模型判断：

{"refund_required":true}

这个判断本身可以是合理的。

但系统发现：

refund_order ↓ needs_human_approval = true

于是：

模型判断 ↓ 退款需求成立 ↓ 触发人工确认 ↓ 人工拒绝

最终：

Agent： 当前订单符合退款处理条件，但退款需要人工确认。 本次暂未执行退款。

这里不能因为模型判断正确，就绕过人工。

这体现了一个重要原则：

模型判断是决策建议，工具权限才是执行边界。

十五、边界案例：工具能做，但业务不应该做

假设模型判断：

用户想修改收货地址

系统存在：

update_address()

但业务规则规定：

订单已经 shipped → 不允许自动修改地址

因此：

模型： 需要修改地址 ↓ 业务规则： order_status = shipped ↓ 禁止调用 update_address ↓ 转人工

这说明：

工具存在 ≠ 当前任务允许使用工具。

工具本身是能力，业务规则决定能力什么时候可以被使用。

十六、失败案例：模型不知道答案时不能自行补全

物流工具返回：

{"logistics_status":"exception","last_event":"运输异常","exception_code":null}

模型可能很容易生成：

“包裹可能因为地址错误导致运输异常。”

但这只是推测。

正确处理应该是：

物流状态： exception 异常代码： null 证据： 不足 ↓ 创建工单或转人工

因此，能力拆分时还需要定义：

模型可以推断什么，必须引用什么数据，什么情况必须拒绝推断。

十七、把需求直接转换成一张“能力设计表”

以后拿到类似需求，可以直接使用下面这个模板。

这张表比一份“Agent Prompt”更适合产品、工程和测试共同使用。

十八、再加一列：失败之后怎么办

真正进入工程设计后，建议进一步增加：

失败去向

完整版本：

这时候，一个业务需求已经基本变成了 Agent 的可执行规格。

十九、如何判断拆分是否合理

不要问：

“这个 Agent 看起来聪不聪明？”

应该问下面这些可验证的问题。

问题一：模型是否承担了应该由程序完成的事情？

例如：

判断订单金额

如果订单系统已经有真实金额，就不应该让模型计算或猜测。

应该：

订单系统 → order_amount

模型只负责判断：

是否需要退款

问题二：工具是否承担了模型应该判断的事情？

例如工具：

decide_if_customer_is_angry()

这类接口往往会把本来属于模型的语义判断硬编码成工具。

更自然的方式是：

模型： 判断用户情绪/意图 工具： 读取订单

问题三：人工是不是被安排在真正需要决策的位置？

如果每个查询都需要人工：

query_order → 人工 query_logistics → 人工 create_ticket → 人工

Agent 基本没有自动化价值。

反过来，如果退款也完全自动：

refund → 无人工

则需要重新评估风险。

二十、四类验收测试

Agent 能不能正确完成业务，不应该只看最后一句回复。

OpenAI 当前 Agent 评估资料建议使用 trace、grader、dataset 和 eval run 来检查 Agent 的端到端行为，其中 trace 可以观察模型调用、工具调用、Guardrails 和 handoff 等过程。(OpenAI Developers)

因此本案例至少需要下面四组测试。

二十一、最值得检查的是“决策链”

对于 Agent，不要只保存：

最终答案

最好能够观察：

用户输入 ↓ 模型判断 ↓ 结构化决策 ↓ 工具选择 ↓ 工具参数 ↓ 工具结果 ↓ 下一次判断 ↓ 人工审批 ↓ 最终动作 ↓ 最终输出

例如一次退款任务应该能还原成：

intent = order_delivery_issue order_id = A20260928001 query_order() → order_amount = 199 query_logistics() → logistics_status = exception model decision → refund_required = true human approval → approved = false refund_order() → 未调用 final status → refund_not_executed

这样即使最终用户只看到一句：

“本次暂未执行退款。”

工程团队仍然知道 Agent 为什么这样做。

二十二、一个可复用的业务需求拆解模板

以后拿到任何 Agent 需求，可以直接先填下面这张表。

【业务目标】 Agent 最终要完成什么？ 【用户输入】 用户会提供哪些信息？ 【模型判断】 哪些事情需要理解、分类、推理或选择？ 【可信数据】 哪些信息必须从业务系统获取？ 【工具操作】 Agent 可以调用哪些工具？ 【工具输入】 每个工具需要什么参数？ 【工具输出】 每个工具返回什么字段？ 【自动执行】 哪些动作可以直接执行？ 【人工确认】 哪些动作必须经过人工批准？ 【禁止动作】 哪些事情无论如何都不能执行？ 【停止条件】 什么情况下必须结束？ 【失败处理】 工具失败、数据缺失、权限不足怎么办？ 【验收标准】 如何判断模型判断、工具调用和人工审批都正确？

如果一项业务需求填完以后仍然出现：

“这里让 Agent 自己判断就行。”

通常说明拆解还不够细。

二十三、最终形成一个简单的设计公式

把整篇文章浓缩起来，可以得到：

业务需求 ↓ ┌───────────────┐ │ 哪些事情需要判断？ │ └───────┬───────┘ ↓ 模型判断能力 │ ↓ ┌───────────────┐ │ 哪些事情需要访问系统？ │ └───────┬───────┘ ↓ 工具操作能力 │ ↓ ┌───────────────┐ │ 哪些事情有高风险？ │ └───────┬───────┘ ↓ 人工确认能力 │ ↓ ┌───────────────┐ │ 哪些情况下必须停止？ │ └───────┬───────┘ ↓ 验收体系

因此，一个成熟的 Agent 需求规格，不应该只有：

“让 Agent 自动处理订单问题。”

而应该类似：

目标： 处理订单未收到问题。 模型： - 识别用户意图 - 提取订单号 - 判断下一步 - 判断异常类型 - 判断是否需要退款 工具： - query_order - query_logistics - create_ticket - refund_order 人工： - 退款前确认 - 超出自动化范围时接管 禁止： - 猜测订单 - 编造物流 - 绕过审批 - 修改未授权数据 停止： - 信息不足 - 工具失败 - 权限不足 - 人工拒绝 - 已经得到足够证据 验收： - 检查模型决策 - 检查工具调用 - 检查工具参数 - 检查人工审批 - 检查最终结果

这才是一份可以真正进入研发阶段的 Agent 能力定义。

二十四、结语：不要把所有业务能力都塞给模型

把业务需求拆成智能体能力，本质上不是在设计一份更复杂的 Prompt，而是在进行一次责任分配。

可以用一句话概括：

模型负责判断，工具负责事实和执行，人工负责高风险决策。

再具体一点：

模型： “下一步应该做什么？” 工具： “这个动作真正执行了吗？” 人工： “这个高风险动作是否真的应该执行？” 系统： “这个动作有没有权限执行？” 验收： “整个过程是否符合预期？”

这几个问题不能混在一起。

尤其不要让模型同时承担：

判断 + 权限 + 执行 + 审批

因为一旦模型的“判断”直接变成了系统的“权限”，业务边界就会变得非常模糊。

更稳妥的 Agent 架构应该让模型拥有有限的决策空间，让工具拥有明确的执行边界，让人工介入真正高风险的决策点。

最终，业务需求才能从：

“让 AI 自动处理订单问题。”

变成工程团队真正能够实现、测试和审计的规格：

模型判断什么、工具执行什么、人工确认什么，以及每一步失败后应该去哪里。

验证状态

• 技术资料核验：已完成。核对了 OpenAI 当前 Agent 定义、Guardrails 与 Human Review、Agent Evals、运行机制及安全资料。
• 案例数据：全部为虚构数据。A20260928001、C10001等仅用于本文演练。
• 设计验证：已进行静态一致性检查。order_id、tracking_no、order_amount、ticket_id、refund_id等字段在案例流程中保持一致。
• 模型/API真实运行：未执行。本文没有连接真实订单、物流、支付或工单系统，因此没有声称真实 Agent 调用已经通过。
• 平台配置：未绑定具体平台。示例属于平台无关的能力设计，不宣称可以直接导入 Dify、扣子或其他 Agent 平台。
• 验收覆盖：已包含正常、边界、工具失败、人工拒绝、参数异常和越权访问场景。

参考资料

1. OpenAI，Agent definitions，核验日期：2026-10-02。官方文档
2. OpenAI，Guardrails and human review，核验日期：2026-10-02。官方文档
3. OpenAI，Evaluate agent workflows，核验日期：2026-10-02。官方文档
4. OpenAI，Safety in building agents，核验日期：2026-10-02。官方文档
5. OpenAI，A practical guide to building agents，核验日期：2026-10-02。官方指南