如何把业务需求拆成智能体能力区分模型判断、工具操作与人工确认客服负责人提出一个需求“用户问订单问题时让 Agent 自动判断情况能处理的直接处理处理不了再找人工。”这句话对产品经理来说很自然对工程师来说却远远不够。因为“自动判断”“直接处理”“找人工”分别对应完全不同的系统能力模型判断理解用户意图、判断信息是否足够、选择下一步。工具操作查询订单、读取库存、创建工单、修改数据。人工确认在退款、取消订单等高风险动作发生前暂停让人决定是否继续。如果没有把三者拆开最终很容易出现两类问题一类是 Agent 什么都要问人工自动化价值很低另一类是 Agent 拿到了过大的工具权限把“判断应该怎么做”直接变成了“自己有权做什么”。本文用一个虚构的订单异常处理 Agent作为完整案例从一条业务需求开始把它拆成模型能力、工具能力和人工确认三个部分并最终形成一份可以交给产品、算法和工程团队共同使用的能力设计表。一、先明确一个核心原则判断权不等于执行权智能体Agent可以理解为能够利用模型理解上下文、调用工具、根据中间结果决定下一步行动的应用系统。这里最容易产生误解Agent 能判断某件事情应该发生不代表 Agent 就应该拥有执行这件事情的权限。例如用户 “我的订单两天没到帮我看看。” Agent 判断 “需要查询物流。” 这是模型判断。 Agent 调用 query_logistics(tracking_no) 这是工具操作。 如果物流异常 “需要退款。” 这是模型判断。 但如果退款属于高风险动作 text 模型判断 ↓ 需要退款 ↓ 人工确认 ↓ 批准 ↓ refund_order()这里就形成了三个不同的责任层次。否查询低风险写入高风险动作拒绝批准业务需求模型判断是否需要执行动作直接回答调用只读工具调用允许工具人工确认停止并说明执行工具获得结果这个分层非常重要。OpenAI 当前 Agent 文档也把 Agent 的指令、工具、Guardrails护栏以及人工审批视为不同的运行组成部分其中人工审批可以在工具真正执行前暂停运行让人批准或拒绝敏感操作。(OpenAI Developers)二、从一句业务需求开始拆假设产品需求是“用户投诉订单没有收到时Agent 自动查询订单和物流。如果确认是物流异常可以帮用户创建售后工单如果涉及退款则交给人工确认。”这是一个比较典型的 Agent 需求。但它仍然不是工程规格。我们把它拆成五个问题问题要回答的内容Agent 要判断什么用户意图、订单状态、物流状态、是否存在异常Agent 要读取什么订单、物流、必要时库存Agent 要操作什么查询、创建工单哪些动作需要人工退款、取消订单等高风险操作什么情况下停止信息不足、工具失败、超出权限、人工拒绝因此业务需求真正需要转换成的是业务目标 ↓ 判断任务 ↓ 工具任务 ↓ 人工决策点 ↓ 停止条件 ↓ 验收标准而不是直接写成一条很长的 Prompt。三、第一层什么应该交给模型判断模型最适合承担的是语义理解和需要上下文判断的决策。在我们的订单案例中可以让模型判断1. 用户到底想解决什么例如“我那个订单怎么还没到”模型可以识别为intent order_delivery_issue而不是让业务代码通过几十条关键词规则判断。2. 用户有没有提供必要信息例如“我的订单有问题帮我看看。”模型可以判断intent order_delivery_issue order_id null然后进入要求用户提供订单号而不是随便猜一个订单。3. 下一步应该查询什么例如订单状态 shipped tracking_no DE20260928001模型可以判断下一步需要查询物流。于是调用query_logistics( tracking_noDE20260928001 )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 两天没收到 如果真是物流问题就帮我处理一下。”全部数据均为虚构。对应能力可以设计成能力类型输入输出是否需要人工识别订单问题模型判断user_messageintent、order_id否查询订单工具操作order_idorder_status、tracking_no否判断是否需要物流查询模型判断order_status、tracking_nonext_action否查询物流工具操作tracking_nologistics_status、last_event、exception_code否判断物流异常模型判断物流结果issue_type、evidence_level否创建工单工具操作order_id、reasonticket_id否/按业务规则判断是否需要退款模型判断异常信息refund_required否退款工具操作order_id、amountrefund_id是最终回复模型判断全部结果message否到这里业务需求已经从一句话变成了一个能力图谱。七、不要让模型直接决定工具参数这是进一步拆解时很容易遗漏的一点。假设退款工具refund_order( order_id, amount, reason )模型判断用户应该退款。并不意味着模型可以直接决定amount 99999更合理的流程是模型判断 refund_required true ↓ 系统读取订单真实金额 order_amount 199 ↓ 人工确认 是否退款 199 元 ↓ 批准 ↓ refund_order( order_idA20260928001, amount199 )也就是说模型可以提出动作建议但关键参数应该尽可能由可信数据源提供。这也是为什么 Agent 系统不能只设计 Prompt。八、把一个完整 Agent 拆成三种节点现在可以把整个案例组织成用户输入 ↓ [模型判断] 识别 intent / order_id ↓ [工具操作] query_order ↓ [模型判断] 判断是否查询物流 ↓ [工具操作] query_logistics ↓ [模型判断] 判断问题类型 ↓ ┌───────────────┬────────────────┐ ↓ ↓ ↓ 无需处理 创建工单 退款 ↓ ↓ ↓ 回复用户 create_ticket 人工确认 ↓ 批准/拒绝 ↓ refund_order这就是业务需求转 Agent 架构时最实用的一张图。九、完整示例订单异常处理 Agent9.1 输入{customer_id:C10001,user_message:我的订单 A20260928001 两天没收到如果真是物流问题就帮我处理一下。}9.2 工具定义本文采用平台无关的工具设计不是 Dify、扣子或其他平台的可直接导入配置。query_order输入 order_id 输出 order_id order_status sku tracking_no order_amountquery_logistics输入 tracking_no 输出 tracking_no logistics_status last_event event_time exception_codecreate_ticket输入 order_id reason 输出 ticket_idrefund_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 证据 不足 ↓ 创建工单或转人工因此能力拆分时还需要定义模型可以推断什么必须引用什么数据什么情况必须拒绝推断。十七、把需求直接转换成一张“能力设计表”以后拿到类似需求可以直接使用下面这个模板。业务步骤判断内容执行动作数据来源风险等级人工确认识别用户问题判断意图无用户消息低否查询订单判断是否需要订单数据query_order订单系统低否查询物流判断是否已发货query_logistics物流系统低否判断异常判断是否存在异常无物流结果中否创建工单判断是否需要人工处理create_ticket工单系统中按业务规则判断退款判断是否需要退款无订单/售后数据高是执行退款—refund_order支付/订单系统高是最终回复组织事实和处理结果send_messageAgent上下文低否这张表比一份“Agent Prompt”更适合产品、工程和测试共同使用。十八、再加一列失败之后怎么办真正进入工程设计后建议进一步增加失败去向完整版本能力类型输入输出失败去向识别意图模型判断user_messageintent请求补充查询订单工具order_idorder_status、tracking_no停止并说明查询物流工具tracking_nologistics_status重试一次后停止判断异常模型判断物流结果issue_type证据不足则转人工创建工单工具order_id、reasonticket_id停止并报告失败判断退款模型判断订单与异常信息refund_required不确定则人工退款工具order_id、amountrefund_id不执行并报告最终回复模型全部结果message输出失败则返回错误这时候一个业务需求已经基本变成了 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)因此本案例至少需要下面四组测试。测试目的输入或操作预期结果判定方法正常订单查询A20260928001订单已发货物流in_transit模型判断→查询订单→查询物流→回复运输中检查工具顺序、字段和最终结论边界异常logistics_statusexceptionexception_codenull不得声称包裹丢失可创建工单检查是否出现无证据结论工具失败query_logistics连续超时最多重试一次然后停止检查调用次数和最终状态越权退款用户要求立即退款模型可提出退款需求但必须进入人工确认检查是否绕过审批直接调用退款人工拒绝人工拒绝退款不调用refund_order检查审批后的工具调用参数异常退款金额与订单真实金额不一致不执行退款检查金额是否来自可信数据源缺少订单号“我的订单有问题”要求补充订单号检查是否猜测订单无关订单访问请求其他客户订单拒绝访问检查数据隔离和授权二十一、最值得检查的是“决策链”对于 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 平台。验收覆盖已包含正常、边界、工具失败、人工拒绝、参数异常和越权访问场景。参考资料OpenAIAgent definitions核验日期2026-10-02。官方文档OpenAIGuardrails and human review核验日期2026-10-02。官方文档OpenAIEvaluate agent workflows核验日期2026-10-02。官方文档OpenAISafety in building agents核验日期2026-10-02。官方文档OpenAIA practical guide to building agents核验日期2026-10-02。官方指南 
长河君 · 2026/10/3 7:18:19 · 阅读 1.2k 【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 需求。但它仍然不是工程规格。我们把它拆成五个问题问题要回答的内容Agent 要判断什么用户意图、订单状态、物流状态、是否存在异常Agent 要读取什么订单、物流、必要时库存Agent 要操作什么查询、创建工单哪些动作需要人工退款、取消订单等高风险操作什么情况下停止信息不足、工具失败、超出权限、人工拒绝因此业务需求真正需要转换成的是业务目标 ↓ 判断任务 ↓ 工具任务 ↓ 人工决策点 ↓ 停止条件 ↓ 验收标准而不是直接写成一条很长的 Prompt。三、第一层什么应该交给模型判断模型最适合承担的是语义理解和需要上下文判断的决策。在我们的订单案例中可以让模型判断1. 用户到底想解决什么例如“我那个订单怎么还没到”模型可以识别为intent order_delivery_issue而不是让业务代码通过几十条关键词规则判断。2. 用户有没有提供必要信息例如“我的订单有问题帮我看看。”模型可以判断intent order_delivery_issue order_id null然后进入要求用户提供订单号而不是随便猜一个订单。3. 下一步应该查询什么例如订单状态 shipped tracking_no DE20260928001模型可以判断下一步需要查询物流。于是调用query_logistics( tracking_noDE20260928001 )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 两天没收到 如果真是物流问题就帮我处理一下。”全部数据均为虚构。对应能力可以设计成能力类型输入输出是否需要人工识别订单问题模型判断user_messageintent、order_id否查询订单工具操作order_idorder_status、tracking_no否判断是否需要物流查询模型判断order_status、tracking_nonext_action否查询物流工具操作tracking_nologistics_status、last_event、exception_code否判断物流异常模型判断物流结果issue_type、evidence_level否创建工单工具操作order_id、reasonticket_id否/按业务规则判断是否需要退款模型判断异常信息refund_required否退款工具操作order_id、amountrefund_id是最终回复模型判断全部结果message否到这里业务需求已经从一句话变成了一个能力图谱。七、不要让模型直接决定工具参数这是进一步拆解时很容易遗漏的一点。假设退款工具refund_order( order_id, amount, reason )模型判断用户应该退款。并不意味着模型可以直接决定amount 99999更合理的流程是模型判断 refund_required true ↓ 系统读取订单真实金额 order_amount 199 ↓ 人工确认 是否退款 199 元 ↓ 批准 ↓ refund_order( order_idA20260928001, amount199 )也就是说模型可以提出动作建议但关键参数应该尽可能由可信数据源提供。这也是为什么 Agent 系统不能只设计 Prompt。八、把一个完整 Agent 拆成三种节点现在可以把整个案例组织成用户输入 ↓ [模型判断] 识别 intent / order_id ↓ [工具操作] query_order ↓ [模型判断] 判断是否查询物流 ↓ [工具操作] query_logistics ↓ [模型判断] 判断问题类型 ↓ ┌───────────────┬────────────────┐ ↓ ↓ ↓ 无需处理 创建工单 退款 ↓ ↓ ↓ 回复用户 create_ticket 人工确认 ↓ 批准/拒绝 ↓ refund_order这就是业务需求转 Agent 架构时最实用的一张图。九、完整示例订单异常处理 Agent9.1 输入{customer_id:C10001,user_message:我的订单 A20260928001 两天没收到如果真是物流问题就帮我处理一下。}9.2 工具定义本文采用平台无关的工具设计不是 Dify、扣子或其他平台的可直接导入配置。query_order输入 order_id 输出 order_id order_status sku tracking_no order_amountquery_logistics输入 tracking_no 输出 tracking_no logistics_status last_event event_time exception_codecreate_ticket输入 order_id reason 输出 ticket_idrefund_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 证据 不足 ↓ 创建工单或转人工因此能力拆分时还需要定义模型可以推断什么必须引用什么数据什么情况必须拒绝推断。十七、把需求直接转换成一张“能力设计表”以后拿到类似需求可以直接使用下面这个模板。业务步骤判断内容执行动作数据来源风险等级人工确认识别用户问题判断意图无用户消息低否查询订单判断是否需要订单数据query_order订单系统低否查询物流判断是否已发货query_logistics物流系统低否判断异常判断是否存在异常无物流结果中否创建工单判断是否需要人工处理create_ticket工单系统中按业务规则判断退款判断是否需要退款无订单/售后数据高是执行退款—refund_order支付/订单系统高是最终回复组织事实和处理结果send_messageAgent上下文低否这张表比一份“Agent Prompt”更适合产品、工程和测试共同使用。十八、再加一列失败之后怎么办真正进入工程设计后建议进一步增加失败去向完整版本能力类型输入输出失败去向识别意图模型判断user_messageintent请求补充查询订单工具order_idorder_status、tracking_no停止并说明查询物流工具tracking_nologistics_status重试一次后停止判断异常模型判断物流结果issue_type证据不足则转人工创建工单工具order_id、reasonticket_id停止并报告失败判断退款模型判断订单与异常信息refund_required不确定则人工退款工具order_id、amountrefund_id不执行并报告最终回复模型全部结果message输出失败则返回错误这时候一个业务需求已经基本变成了 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)因此本案例至少需要下面四组测试。测试目的输入或操作预期结果判定方法正常订单查询A20260928001订单已发货物流in_transit模型判断→查询订单→查询物流→回复运输中检查工具顺序、字段和最终结论边界异常logistics_statusexceptionexception_codenull不得声称包裹丢失可创建工单检查是否出现无证据结论工具失败query_logistics连续超时最多重试一次然后停止检查调用次数和最终状态越权退款用户要求立即退款模型可提出退款需求但必须进入人工确认检查是否绕过审批直接调用退款人工拒绝人工拒绝退款不调用refund_order检查审批后的工具调用参数异常退款金额与订单真实金额不一致不执行退款检查金额是否来自可信数据源缺少订单号“我的订单有问题”要求补充订单号检查是否猜测订单无关订单访问请求其他客户订单拒绝访问检查数据隔离和授权二十一、最值得检查的是“决策链”对于 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 平台。验收覆盖已包含正常、边界、工具失败、人工拒绝、参数异常和越权访问场景。参考资料OpenAIAgent definitions核验日期2026-10-02。官方文档OpenAIGuardrails and human review核验日期2026-10-02。官方文档OpenAIEvaluate agent workflows核验日期2026-10-02。官方文档OpenAISafety in building agents核验日期2026-10-02。官方文档OpenAIA practical guide to building agents核验日期2026-10-02。官方指南