006 从问答到执行：AI Agent 的现场交付方法

从问答到执行AI Agent 的现场交付方法#AI FDE #AI Agent #工具调用 #工作流 #人工审批一、问题产生背景知识库问答解决的是“给出信息”但很多企业场景需要“完成动作”创建工单、生成 CRM 更新草稿、查询订单状态、安排会议、发送通知或触发审批。一旦 AI 开始执行动作交付风险就从“回答是否准确”扩大到“动作是否被授权、参数是否正确、失败是否可恢复、重复执行是否会造成损失”。因此Agent 不能只被设计成一个会调用工具的聊天机器人。二、Agent 的最小交付模型一个可交付的 Agent 至少包含Planner理解任务并决定步骤Tool执行明确、有限的业务动作Permission判断用户是否有权调用工具和访问参数Approval高风险动作需要人工确认Idempotency重复请求不会造成重复业务动作Retry区分可重试错误和不可重试错误Audit记录谁在什么时间以什么参数执行了什么动作Handoff无法完成时交给人工处理。三、以销售助手为例销售助手可以读取客户跟进记录生成“待更新 CRM”的草稿但首期不直接修改 CRM 主数据。销售确认草稿后系统才可以进入写入流程涉及客户状态变更、批量修改或跨团队操作时需要更高等级审批。这个边界看似降低了自动化程度实际上提高了可控性。AI FDE 应优先交付用户愿意接受且出错后容易补救的动作。四、工具设计原则1. 工具职责单一不要提供一个名为update_everything的大工具。更好的做法是拆成get_customer_followupscreate_crm_draftsubmit_crm_changerequest_manager_approval工具越具体权限判断、参数校验、审计和测试越容易。2. 参数必须结构化工具输入应使用明确字段而不是一段自然语言。例如更新草稿需要customer_id、summary、next_action和source_ids并在服务端再次校验这些字段。3. 关键动作必须幂等客户端重试、网络超时和模型重复调用都可能造成重复写入。每一次业务动作应携带idempotency_key服务端使用它判断请求是否已经处理。五、Agent 状态机RECEIVED - PLANNED - WAITING_PERMISSION - WAITING_APPROVAL - EXECUTING - SUCCEEDED 任意阶段都可能进入 FAILED_RETRYABLE - RETRYING FAILED_FINAL - HANDOFF CANCELLED - END把状态显式化前端就可以向用户展示“正在等待审批”“工具调用失败”“已转人工”而不是一直显示一个无法解释的加载动画。六、失败处理可重试错误网络超时、服务暂时不可用、限流和短暂连接失败通常可以重试但要设置最大次数、退避策略和幂等键。不可重试错误参数格式错误、权限不足、客户不存在和业务规则冲突不应无休止重试。系统应该解释问题并要求用户补充信息或转人工。人工接管人工接管不是 Agent 失败后的临时补丁而是高风险流程的一部分。交接时应保留用户问题、已执行步骤、工具返回、失败原因和待人工确认内容。七、审批设计审批不应只做一个“确认”按钮。审批页面至少要显示将要执行的动作影响的业务对象变更前后内容数据来源和引用风险等级发起人和执行人取消或回滚方式。如果用户无法看懂即将发生什么就不应该让他承担审批责任。八、关键知识点总结Agent 交付的基本原则是让模型负责理解和规划让工具负责有限执行让服务端负责授权和校验让人负责高风险决策。AI FDE 应先选择低风险、高频、可验证的动作做试点再逐步扩大自动化范围。不要因为模型能够调用工具就默认它应该拥有完整业务系统权限。九、关键知识点总结Agent 不等于会调工具的聊天机器人规划、工具、权限、审批、幂等、重试、审计、人工接管都要设计。模型负责理解与规划工具负责有限执行服务端负责授权与校验人负责高风险决策。高风险动作发邮件、改主数据、付款、删除必须先生成命令摘要再走人工确认。幂等键 重试分级 失败回收 审计日志才能让 Agent 在真实业务里稳定上线。十、可复用的“黄金总结公式”Agent 交付 规划 × 工具 × 审批 × 幂等 × 审计 × 接管