跳转到内容

企业落地 AI,例如 Agent、Skill 等智能体相关能力时,首先需要把具体业务场景梳理清楚。

具体需要梳理哪些内容呢?这篇文章就来聊一聊。

很多客户在描述需求时,会说“数据很多”“情况复杂”“就是看到的这样”。这些描述本身有价值,但不能直接用于智能体配置或开发,对智能体来说,这些信息是模糊的。智能体需要的是更明确的信息:

具体看哪些数据?
按照什么顺序处理?
依据什么规则判断?
什么情况必须转人工?
输出给谁?
输出成什么格式?
哪些事情不能自动处理?
怎样算做对?
哪些错误绝对不能出现?

整体调研流程

第 1 步:确定一个具体任务

落地智能体,应“大处着眼,小处着手”,先找具体场景落地。

不建议一开始就说:

做一个销售智能体
做一个财务智能体
做一个客服智能体
替代某个部门工作

更好的方式是从具体任务开始:

销售线索初步整理
客户邮件分类与回复草稿生成
合同条款初步审查
员工报销材料完整性检查
采购申请材料初审

适合优先落地的任务通常具备以下特点:

高频重复
有明确业务价值
规则相对稳定
有明确输入输出
有历史案例可以参考
出错风险可控
可以先由人工确认后使用
所需数据可以获得或导出
输出结果可以验证

选择任务时,可以从以下维度评估:

评估维度
需要判断的问题
业务价值
是否高频、耗时、影响收入、体验或风险控制
流程稳定性
人工处理步骤是否相对固定
数据可得性
所需文件、表格、系统数据是否能稳定获得
规则显性度
判断依据是否能够说清楚、写出来、验证
风险可控性
出错后影响是否可控,是否能人工兜底
系统复杂度
是否需要读取多个系统、写入核心系统或跨部门协作
验收可测性
是否能用历史案例判断智能体做得好不好

如果某个任务价值很高但风险也很高,不应直接追求自动化,可以先从“辅助分析、生成草稿、风险提示、人工确认”开始。

第 2 步:提供 3-5 个真实案例

业务人员口头描述的流程,往往是理想流程;真实案例暴露的,才是实际流程。

应优先提供最近已经完成的 3-5 个真实案例,同时每个案例建议包含:

材料
说明
原始输入
邮件、文件、截图、表单、聊天记录等
处理过程
人工参考了什么、做了哪些判断
最终结果
回复、报告、表格、工单、审批意见等
特殊情况
信息缺失、投诉、金额较大、规则不确定等
人工修改记录
如有草稿或中间版本,请说明最后修改了什么

案例最好覆盖:

正常案例
常见案例
异常案例
高风险案例
边界案例
处理不理想的案例

前期 3-5 个案例主要用于理解场景。如果进入原型验证或上线前,还需要补充更多案例,用于测试和验收。

如果涉及敏感信息,可以脱敏,但应保留字段结构和内容类型。

第 3 步:说明当前处理步骤

按照真实工作顺序,说明人工现在如何完成这个任务。

需要按步骤说明:

顺序
谁处理
看什么信息
做什么动作
判断依据
产出什么
1





2





3





填写时不要只写“审核”“判断”“处理”,而要尽量写具体:

审核什么?
判断什么?
依据什么判断?
判断后进入哪个分支?
最终产生什么结果?

例如,“根据截图判断”是不够的,需要进一步说明:

看哪张截图?
截图中哪些字段有用?
字段是否需要校验?
截图和系统数据冲突时以哪个为准?
截图不清楚时怎么处理?

第 4 步:说清楚判断逻辑

如果任务中有需要判断的地方,请说清楚判断逻辑。

类似下面表格:

判断事项
需要查看的信息
判断规则
处理结果
不确定时如何处理
是否需要转人工




是否属于高风险




是否可以生成回复草稿




是否可以继续处理




很多业务规则并不一定写在制度里,而是存在于经验中。调研的重点,不只是收集已有规则文件,还要通过真实案例反推隐性规则。

尤其要明确“不确定时怎么处理”。智能体不应该在信息不足时猜测结果,常见处理方式包括:

提示信息不足
要求补充材料
标记为不确定
转人工确认
只生成草稿不执行
拒绝执行高风险动作

第 5 步:说明异常情况和兜底方式

列出实际工作中常见的异常情况,以及现在如何处理。

异常情况
当前处理方式
希望智能体处理方式
是否必须人工确认
信息不完整


是/否
系统查不到数据


是/否
客户表达不清楚


是/否
系统数据冲突


是/否
涉及投诉


是/否
涉及金额或赔偿


是/否
规则不明确


是/否

异常情况不是边角问题,而是判断智能体能不能上线的重要依据。很多智能体在演示时表现不错,但上线后失败,往往是因为异常情况处理不好。

第 6 步:系统、数据来源和边界

如果任务处理过程中需要查看系统、表格、数据库或内部资料,请说明这些信息从哪里来、如何使用。

项目
内容
需要查看哪些系统或资料

需要哪些数据字段

哪些数据是必须的

哪些数据经常缺失

哪个系统或文件是准确信息来源

多个系统数据冲突时以哪个为准

是否有系统接口或导出方式
有/无/不确定
是否允许智能体读取系统数据
是/否/需确认
是否允许智能体写入系统
是/否/需确认
是否涉及敏感数据
是/否
是否需要脱敏
是/否
是否允许使用外部模型处理
是/否/需确认
是否需要操作日志或审批记录
是/否/需确认

智能体能不能落地,很多时候不只取决于模型能力,还取决于数据是否能拿到、权限是否允许、系统是否能接入、错误是否能追踪。

第 7 步:输出要求

输出要求不要只写“准确”“专业”“自然”,而应尽量具体。例如:

回复控制在 150 字以内。
语气正式、克制。
不得承诺退款或赔偿。
无法确认的信息不得编造。
如涉及投诉或法律问题,必须转人工。

第 8 步:确认智能体不能做什么

需要明确哪些事情不能由智能体自动完成。

禁止事项
是否适用
说明
不能自动审批
是/否

不能自动付款
是/否

不能自动对外发送正式回复
是/否

不能修改正式合同原文
是/否

不能承诺赔偿
是/否

不能给出法律、财务、人事最终结论
是/否

不能访问某些系统或数据
是/否

不能写入核心系统
是/否

不能替代最终人工判断
是/否

不能在信息不足时自行猜测
是/否

建议进一步进行风险分级:

风险等级
说明
智能体处理方式
低风险
出错影响小,可人工快速修正
可生成结果,人工抽检
中风险
影响客户体验或业务处理
生成草稿或建议,人工确认
高风险
涉及金额、合同、投诉、审批
标记风险并转人工
不可自动化风险
涉及付款、最终审批、法律结论、敏感决策
禁止自动执行,只能提供参考

第 9 步:明确验收标准

在进入配置或开发前,需要说明期望达到怎样的目标。目标难度,直接决定智能体的实现难度和成本。

指标
说明
处理速度
期望节省多少时间
输出质量
是否符合模板、语气和业务要求
分类准确性
分类、标签、优先级判断是否准确
人工修改量
人工需要修改多少才可使用
风险识别能力
高风险、异常、禁止事项是否能识别
事实准确性
是否正确引用客户信息、订单信息、制度条款
转人工准确性
该转人工的情况是否都转人工
错误底线
哪些错误绝对不能出现
验证案例数量
上线前需要通过多少个测试案例

对于高风险任务,应优先保证风险识别和人工确认机制,而不是只追求自动化比例。

可以尽量量化,例如:

常见问题分类准确率达到 90% 以上。
高风险事项必须被识别并转人工确认。
上线前至少通过 30 个历史案例验证。
不得自动承诺赔偿、退款、审批通过或法律结论。
涉及客户信息、订单状态、金额等内容不得引用错误。

后续推进方式

资料提交后,项目团队根据上面整理的详细信息,整理一版《智能体工作说明》。

这份说明用于使用智能体“可以理解”的方式客观描述场景工作流程:

检查场景资料是否完整
检查任务是否足够具体
检查处理步骤和判断规则是否合理
明确智能体可以做什么、不能做什么
明确哪些环节必须人工确认
明确系统、数据、权限和合规要求
设计智能体工作流程
制作原型
建立测试案例集
明确验收标准和上线前验证方式

客户确认后,进行原型设计,以及接下来的具体实现。

总结

企业智能体落地前的调研,要完成的是一次“业务转译”:

把真实案例转译成测试样本
把人工流程转译成智能体工作流
把经验判断转译成规则和边界
把异常处理转译成兜底机制
把输出样例转译成模板和质量标准
把禁止事项转译成权限和风控策略
把业务目标转译成验收指标

一个好的智能体项目,首先需要清晰梳理业务现场,这也是企业智能体真正能够落地的前提。

返回专题 · 企业 Agent 下一篇:欢迎加入企业智能体讨论群

持续沉淀企业 AI 技术内容。