一个助手能写出语气得体的邮件,不代表它能接管“处理退款”这条工作流。退款需要识别订单、核对政策、判断例外、写入系统、通知客户,还要在金额异常时停下来。只要其中一步使用了过期规则、越过授权或重复执行,流畅的回答就会变成真实损失。
因此,工作流准入不应从“模型回答得像不像人”开始,而应从三个更硬的条件开始:上下文是否可维护,动作是否受权限约束,过程是否可追溯并可恢复。这三道门槛共同决定助手是在提供建议,还是已经成为生产系统的一部分。
先分清助手、工作流和代理
OpenAI 的代理构建指南把代理描述为能够代表用户独立完成任务、选择工具并管理工作流执行的系统;Anthropic 的工程总结则区分了由代码预先编排的工作流与由模型动态决定步骤的代理。这个区别很实用:如果流程稳定、规则清晰,确定性代码通常更便宜、更容易测试;只有存在大量非结构化信息、例外和上下文判断时,才值得让模型参与路由。
把普通聊天框接上几个 API,并不会自动得到可交付的代理。系统至少还需要任务状态、身份传递、输入输出校验、重试与人工接管。模型负责处理模糊性,确定性组件负责守住不能含糊的边界。
第一道门槛:上下文必须有来源和保鲜期
企业上下文不是把几十份文档塞进长提示词。它至少包括业务对象、当前状态、适用规则、用户权限和本次任务目标。订单状态来自交易系统,退款规则来自受控知识库,客户身份来自会话凭据;这些信息的负责人、更新时间和适用范围都不同。
可维护的做法是把上下文拆成可验证字段,并记录来源和时间。例如,助手引用“30 天内可退款”时,应能关联到具体政策版本,而不是依赖模型记忆。规则冲突或数据缺失时,正确行为是请求补充或转人工,而不是补出一个听起来合理的答案。
上下文还需要失效机制。政策更新后,旧索引、缓存和正在执行的长任务如何处理,应有明确规则;否则系统可能一边展示新制度,一边继续按旧版本执行。对关键规则,可以在调用时校验版本或生效日期,而不是只依赖定期重建知识库。
判断标准:如果团队无法回答“这条信息来自哪里、何时更新、谁有权修改”,它就不应成为自动执行的依据。
第二道门槛:授权必须细到具体动作
登录只证明调用者是谁,不证明任何动作都被允许。读取订单、生成退款草稿、提交退款和批准大额退款应当是四种不同能力。凭据应短期、最小权限并绑定任务目的;高风险动作还需要金额、对象范围和有效期限制。
| 动作层级 | 典型能力 | 最低控制 | 失败后的处理 |
|---|---|---|---|
| 读取 | 查询订单、检索政策 | 主体身份、字段级权限、访问日志 | 拒绝访问并记录缺失权限 |
| 草拟 | 生成回复或退款建议 | 来源引用、结构校验、禁止自动发送 | 保留草稿并交给人员确认 |
| 提交 | 创建工单、发送消息 | 明确确认、幂等键、范围上限 | 停止重试,展示已完成步骤 |
| 批准 | 付款、删除、改变权益 | 独立审批、强身份验证、不可抵赖日志 | 进入人工处置与补偿流程 |
矩阵的重点不是多设弹窗,而是让风险越高的动作拥有越明确的授权和恢复路径。
自然语言里的“帮我处理一下”不应被当作无限授权。系统需要把用户意图转换为待审批的结构化动作:对象是谁、将修改什么、影响范围多大、能否撤销。确认界面应展示这些差异,而不是只问一句“是否继续”。
第三道门槛:失败必须可见、可停、可恢复
真实系统会超时、返回重复结果,也会在任务执行一半时等待外部审批。代理如果没有持久化任务 ID 和步骤状态,就无法区分“上一请求失败”与“上一请求成功但响应丢失”,重试可能造成重复下单或重复发信。
有副作用的工具应优先支持幂等键;工作流应记录已完成步骤、待处理步骤、外部产物和补偿动作。超过重试次数、遇到权限冲突或证据不足时,系统要能停止并把上下文交给人,而不是让模型继续猜。人工接管不是失败标志,而是系统边界的一部分。
审计不是保存一段聊天记录
聊天记录只能说明用户和助手说了什么,不能证明系统做了什么。生产日志还应关联代理版本、模型版本、检索来源、工具调用、授权决策、参数摘要、状态变化和最终产物。敏感数据可以脱敏,但决策链不能丢失。
NIST AI RMF用 Govern、Map、Measure、Manage 四类功能组织风险管理,并强调治理贯穿整个生命周期。对应到助手上线,团队至少要有任务级成功率、未经授权调用率、人工接管率、重复执行率和单位成功成本,而不是只统计对话量或用户点赞。
用一条低风险流程做准入测试
适合的第一条流程应高频、边界清晰、结果容易复核,例如整理内部知识库的待更新条目,而不是直接批准付款。先采集人工流程的时间、错误和例外基线,再让助手只读取和草拟;稳定后逐步开放提交动作,并保留相同评测集回归。
上线门槛可以写成六个可回答的问题:输入是否有可信来源;缺失信息时是否会停;每个工具是否有最小权限;写操作是否幂等;人员能否看到并纠正关键判断;一次失败能否从确定状态恢复。任何一项只能靠“模型应该会注意”来保证,都说明系统还停留在演示阶段。
并非每个流程都需要代理
固定字段转换、确定性审批规则和高吞吐批处理,常常更适合传统软件。代理的价值是处理规则难以穷举、材料非结构化且需要多步判断的部分,而不是替代所有代码。最稳妥的架构通常是让模型提出下一步,让权限、状态机和验证器决定这一步能否发生。
当上下文可以追根溯源、授权可以细到动作、失败可以安全退出,AI 助手才真正跨过了工作流门槛。此前的重点是“能不能做”;此后的重点应变成“在什么条件下允许做,以及如何证明它做对了”。
参考资料
更新记录
首次发布,暂无后续更新。
DISCUSSION
评论 0
理性讨论,尊重不同观点。
登录后参与讨论。
登录注册账号还没有评论,欢迎留下第一个观点。