用户问客服 Agent上次那单还没发能不能直接取消优惠券也退回来识别出“取消订单”并不难。模型甚至可以顺手抽出“未发货”“退回优惠券”两个条件给出一段很像样的回复。麻烦从这里才开始。“上次那单”是哪一单系统里的履约状态是否真的还是未发货优惠券是平台券、店铺券还是已经过期的活动券取消后原路退款还是退到余额当前用户有没有权操作这张订单这些问题没有答案Agent 只是听懂了这句话还没有理解这笔业务。碰到这种情况最顺手的改法往往是继续补 Prompt遇到“上次那单”优先查询最近订单用户说“还没发”就走未发货取消流程提到优惠券再补一条退券规则。前几轮可能真有效。问题在于Prompt 能提醒模型怎样分析却不能证明订单此刻处于什么状态也不能替权限系统批准退款。规则越补越长模型知道的似乎越来越多系统对真实业务的把握却未必增加。对会执行动作的 Agent我会把“理解业务”落到一件可以验收的事上它能否在明确边界内把正确的业务对象从当前状态推进到目标状态并留下可核对的依据。这比“意图识别准确率有多高”多走了好几步。查询类任务不一定改变业务对象但也要绑定可信状态和事实来源。本文更关注风险更高的一类Agent 听懂以后还要继续行动。我们在《如何为 Agent 设计产品》里讨论过产品能力要变成 Agent 能理解、调用、约束和审计的动作。这次再往业务内部走一层这些动作依赖的业务含义从哪里来又怎样落到状态、规则和权限里。太长不看• 意图识别回答“用户大概想做什么”它只是业务理解的入口。• 规则、分类器、Embedding、LLM 和 RAG 很少互相取代。生产系统更常见的是逐层分流复杂请求再升级。• 真正的业务理解至少包含六样东西统一术语、业务对象、实时状态、规则版本、权限边界和可执行动作。• RAG 可以找政策和案例不能替订单系统报告实时状态也不能替权限系统批准资金动作。• Prompt 适合告诉模型怎么分析业务规则和高风险边界更适合留在代码、流程或策略系统里。• 评估不能只看意图 Accuracy。还要看状态读取、规则判断、追问质量、误执行、高风险拦截和端到端完成率。Agent 理解业务的完整执行链图 1从自然语言到完成证据每一步都绑定明确的事实来源和责任边界。意图识别只回答了第一问过去十年任务型对话系统在意图分类上已经积累了很完整的技术路线。规则适合处理确定性请求也适合放安全拦截。标签稳定、数据量够时TF-IDF、FastText 配合逻辑回归或 SVM成本低延迟也容易控制。BERT 一类模型能处理更复杂的上下文JointBERT 还会把意图分类与槽位抽取放在一起训练把一句“帮我订周五从杭州到北京的机票”同时整理成目标和参数。新意图多、每类样本又少时可以先用 Embedding 做相似度召回原型网络和对比学习也常用于少样本分类让有限样本先形成可区分的类别表示。LLM 则擅长口语、省略、多轮修正和边界不断变化的长尾请求。这些方法并不是按年代依次淘汰前一种。实际选型通常取决于四件事• 意图有多少是否已经多到一份 Prompt 放不下• 标签是否经常调整新业务多久上线一次• 有没有足够的真实标注数据• 一次判断要回看一句话还是几轮对话和工具结果。生产系统里更常见的是级联。请求先经过规则和安全闸门稳定流量交给轻量分类器意图很多时Embedding 先召回 Top-K 候选仍有歧义的请求再交给 LLM涉及多个动作和依赖关系时才进入规划器或业务流程。请求越简单链路越短。只有复杂度上升时系统才增加推理成本。意图识别的级联架构与四类出口图 2不同技术各守一段边界复杂请求逐层升级最终进入执行、追问、拒识或确认。只是进入 Agent 系统以后输出不再是一张“转给哪个客服组”的标签。模型给出的结构会继续触发查询、退款、改签、发消息等真实动作。同样是 cancel_order至少还缺五个判断1. 操作的是哪个业务对象2. 对象现在处于什么状态3. 当前规则允许走哪条路径4. 这个人有没有操作权限5. 动作执行后怎样确认钱、券和订单都已正确变化。CLINC150 这类经典数据集专门加入了超出支持范围的请求因为分类器不能假设每句话都属于已有标签。到了 Agent 现场这个边界更重要。一个请求不在支持范围内最稳的结果是拒识、追问或转人工。硬选一个“最像的意图”后面可能就是一次错误写入。一次识别最终会进入四类出口之一执行、追问、拒识、确认。到了这一步输出已经从意图标签变成了控制流的下一步。意图识别做得再好也只能证明系统听懂了入口。它还没有证明整件事做得对。业务知识不是一摞可以检索的文档很多团队发现 Prompt 不够用下一步自然会想到 RAG把产品文档、客服手册、制度、历史工单全部放进知识库需要时检索给模型。这会有帮助却也很容易制造一种错觉资料找到了Agent 就懂业务了。文档里通常写着三类东西• 业务术语和政策• 操作流程和例外• 过去发生过的案例。真实业务还多出三类动态事实• 某个对象此刻的状态• 当前用户在当前组织里的权限• 刚才那次动作究竟成功、失败还是只处理了一半。前一组可以从文档检索。后一组必须回到订单、账户、权限、支付和审计系统里读取。Anthropic 在上下文工程文章里强调上下文是有限资源目标是给模型最少但高信号的信息。这解决了一个很现实的问题每一步推理到底该让模型看到什么。上下文工程解决模型此刻看见什么流程工程解决业务接下来允许发生什么。网上讨论里有人把它概括成一句 Context engineering ! process engineering。放到客服场景里这个区别很具体知识库可以把退款政策送到模型眼前订单状态、额度校验和审批结果仍要由业务系统给出。给模型一份退款政策它有机会解释政策。把退款条件、金额上限、审批角色和状态变化写进流程系统才有机会稳定执行政策。业务理解最后落到运行时对着当前对象读取当前状态套用当前规则再以当前身份行动。知识库能补充背景不能替代这条链路。先给业务一套共同语言Agent 业务理解并不是全新的软件工程问题。Eric Evans 在领域驱动设计里把领域模型定义为一组抽象用来描述业务领域中与解决问题有关的部分。他还强调统一语言和限界上下文同一个词只有放在明确边界里含义才稳定。“客户”在销售系统里可能是线索在合同系统里是签约主体在售后系统里又可能是服务权益的持有人。“取消”也不只有一个意思取消预约、撤销订单、终止合同、停止续费背后的状态变化完全不同。如果团队内部还在混用这些词模型很难替我们把它们自动理顺。第一步不必建设一套庞大的企业知识图谱。先把一个小流程里的六样东西写清楚业务要素取消订单场景里要回答什么统一术语“未发货”“已出库”“退款完成”分别指什么业务对象操作哪张订单、哪笔支付、哪张优惠券实时状态订单、履约、支付和优惠券当前是什么状态规则版本当前适用哪版取消和退款政策权限边界谁能查询、谁能取消、谁能批准例外退款可执行动作查询、取消、退款、退券分别调用哪个工具这六项放在一起才接近 Agent 可以使用的业务语义。它不一定要叫“语义层”也不一定要单独做成平台。初期可以只是几份版本化文件、几个清楚的接口和一张状态图。名字不重要关键是业务含义不能继续散在 Prompt、口头经验、数据库字段和客服脑子里。坦率说这六项也不是一套放之四海而皆准的标准模型。制造、金融、医疗、研发会有不同对象和约束。它更像一张排查表用来确认这条业务链路还有哪些地方只存在于人的经验里。同一句人话换个现场就会缺另一组条件订单取消是比较典型的企业流程。把视线放宽一点生活、工作和研发里其实都有同样的问题。一句自然语言Agent 真正动手前还缺什么“把明天下午的安排往后挪”哪个日历事件、挪到几点、参与人是否有空、是否要通知外部来宾“把上周出差的票都报了”哪次行程、哪些发票、费用归属、当前制度版本、审批人和重复报销检查“上周企业客户收入涨了多少”自然周还是最近七天、企业客户口径、收入定义、时区、退款和币种怎样处理“把登录问题修掉没问题就发版”哪个仓库和环境、怎样复现、改动边界、哪些测试算通过、谁有发布权、失败后回滚到哪里这些请求都不难听懂。真正的工作量藏在省略掉的业务条件里。拿“上周企业客户收入涨了多少”来说模型生成一条语法正确的 SQL 并不稀奇。可它如果把“上周”理解成最近七天把“收入”读成账单金额又没有排除内部测试账号最后的图表依然能画得很漂亮。这类错误麻烦在于它往往不会报错。查询能运行数字有小数点解释也顺。等答案进入周报和经营会错误口径已经离开了技术现场。研发任务也一样。“没问题就发版”至少跨过了四种状态问题能够复现代码已经修改本地和流水线检查通过线上版本完成切换。某个测试通过只能证明这一项检查通过不能自动升级成“已经发布”。自然语言更适合做任务入口不能直接拿来执行。Agent 先要补齐对象、状态、规则、权限和完成证据才能从“像是听懂了”走到“可以动手了”。对话状态、业务状态和执行状态别放进一个字段多轮对话里用户常常只说半句话换成明天吧。系统至少要知道当前任务是什么用户是在延续、切换、取消还是修正任务哪些参数已经确认哪些参数还缺以及上一次工具调用返回了什么。这些信息可以整理成一份对话状态例如active_intent intent_transition confirmed_slots missing_slots last_tool_result latest_user_correction对话状态记录的是“目前聊到哪里”不等于业务对象此刻的真实状态。状态回答的问题更可信的来源对话状态用户当前想继续、修改还是取消什么会话记录与结构化槽位业务状态订单、账户、库存现在是什么状态业务 API 和事实数据库执行状态动作是否开始、完成、重试或进入补偿工作流、任务队列和审计日志“用户刚才说订单没发货”只能进入对话状态不能直接写成 fulfillmentnot_shipped。后一个值必须从履约系统重新读取。复合任务还会再多一层。例如查一下本月云账单超过预算就暂停测试环境再通知项目负责人。这句话包含查询、条件判断、环境变更和消息通知。单标签分类只能说它“大概属于成本管理”却会丢掉动作之间的依赖关系。更可用的结果是一张小型执行图读取账单 - 对比预算 ├─ 未超预算 - 返回结果 └─ 超出预算 - 确认环境范围 - 暂停测试环境 - 校验环境状态 - 通知负责人到了这里意图识别已经开始进入语义解析、状态跟踪和任务规划。术语可以很多边界只有一个模型负责整理用户表达真实状态和副作用仍由业务系统负责。把一句话编译成业务决策记录回到开头那句话上次那单还没发能不能直接取消优惠券也退回来模型比较适合做第一段工作把自然语言整理成候选目标、对象线索和待确认项。但它不该凭聊天记录猜订单状态更不该根据“用户说还没发”就直接执行取消。一份更可用的中间结果大致会长成这样{ goal: cancel_order, object: { type: order, id: resolved_by_tool }, observed_state: { payment: paid, fulfillment: not_shipped, coupon: consumed }, policy_refs: [ order_cancel_policy:v7, coupon_restore_policy:v3 ], unresolved: [ refund_destination ], planned_actions: [ cancel_order, refund_payment, restore_coupon ], approval: { required: true, reason: financial_side_effect } }这份记录里的字段不能都交给模型填写• goal 和对象线索可以由模型解析• observed_state 必须由业务系统读取• policy_refs 要绑定明确版本• planned_actions 要经过规则与权限校验• approval 由风险策略决定不能让模型自己给自己放行。从架构上看它更像一个小型编译过程自然语言 - 候选业务目标 - 绑定业务对象 - 读取实时状态 - 应用规则与权限 - 生成动作计划 - 确认后执行 - 校验状态变化LLM 擅长处理前面的模糊表达。确定性系统负责中间的状态、规则和权限。工具执行器产生副作用验证器再检查结果是否符合预期。模型不需要包办每一步。分工越清楚出了问题越容易定位。在《Graph Engineering 详解Loop 之后Agent 工作流开始显式成图》里我们把任务依赖、分支和回流画成了一张图。走到业务现场还要多问一步节点读哪份状态边上传递哪种结果哪个位置会扩大权限。少了这些契约图画得再清楚运行时还是会猜。RAG 适合检索不适合裁决RAG 在这条链路里仍然很有用。它可以根据当前目标找到相关术语、政策、流程说明、正反案例和历史误判。意图很多时也可以先召回三到五个候选让模型在更小范围里判断。但有三类信息不适合让 RAG 当最终裁判。实时状态订单是否出库、付款是否到账、库存是否锁定要从当前业务系统读取。昨天的工单和知识库切片不能替代今天的状态。权限结果“主管通常可以退款”只是说明。当前操作人是否属于这个组织、额度是否超限、凭证是否有效必须由身份与权限系统判断。动作结果模型说“已经取消”没有意义。工具返回成功也还不够。系统还要继续读取订单、支付和优惠券状态确认这次业务事务最终落在预期位置。更稳的做法是把知识按角色拆开信息更合适的真相源术语、政策、SOP、案例版本化文档与检索系统订单、账户、库存、支付状态业务 API 或数据库服务身份、角色、额度、审批权认证与授权系统分支、超时、重试、补偿工作流或状态机调用结果、状态变化、责任人运行记录与审计日志Prompt、RAG、业务系统和工作流的职责对比图 3知识帮助模型理解业务系统和工作流负责让结果可信。Rasa 的 CALM 是一个值得参考的实现方向。它让 LLM 根据对话历史、相关 flow 和当前状态生成结构化命令业务逻辑则放在 flow 里。模型处理语言的灵活性流程保留业务执行的确定性。这比把 if/else 全塞进系统 Prompt 更容易版本化也更容易测试。理解、决策、执行最好分三层为了赶进度很多原型会让同一个 Agent 完成整条链路读用户输入、判断政策、选择工具、执行动作再自己宣布完成。Demo 很顺生产问题却会混在一起。一次退款失败到底是意图识别错了、订单状态读旧了、规则版本不对、权限判断漏了还是支付接口超时如果所有逻辑都藏在一段上下文里排查时只能重放整段对话。放到工程里我更倾向于拆成三层。理解层把人话变成业务候选输出目标、对象线索、参数、置信信息和待确认项。这里允许概率判断也允许拒识和追问。决策层把候选放进业务现场读取实时状态应用规则版本检查权限生成可执行计划。高风险规则尽量使用确定性代码、决策表或状态机。执行层让动作可控地产生副作用工具要有明确输入、输出、前置条件、幂等键和错误类型。涉及资金、删除、外发和不可逆动作时系统能停在“已选择工具尚未调用”的位置等待确认。HumanLayer 的 12-Factor Agents 特别强调控制流要支持暂停和恢复。人工确认不能等到 Agent 执行完以后再看日志系统要能在副作用发生前停住。三层不意味着一定要做三个 Agent。完全可以是一个 Agent 加两层普通代码。架构目标是分清责任不是增加角色。Agent 业务执行的三层架构图 4理解层处理模糊表达决策层绑定业务现场执行层控制副作用并留下证据。一条最小执行链路可以朴素到下面这样candidate understand(user_input) object resolve(candidate.object_ref) state read_source_of_truth(object) policy resolve_policy(candidate.goal, object, state, current_time) decision decide(candidate, state, policy, principal) if decision.requires_confirmation: pause(decision) result execute(decision.command, idempotency_key) evidence verify(object, decision.expected_state) record(decision, result, evidence)这里有两个细节很容易被省掉。principal 指当前以谁的身份行动。Agent 有工具调用能力不等于它继承了管理员权限。verify 也不是复述工具的成功消息而是重新读取业务对象核对预期状态是否真的出现。五份小合同比知识库大全更容易起步如果团队准备让 Agent 接一个真实业务流程我不会先做“企业知识库大全”。更稳的起点是挑一条窄流程做五份小合同。1. 术语合同列出业务对象、关键字段、同义词、容易混淆的词以及它们在哪个边界内成立。例如“退款完成”到底表示支付机构已受理还是资金已经回到用户账户。两种定义会带来完全不同的客服回复。2. 状态合同写清对象有哪些状态允许怎样迁移哪个系统是事实源。paid - cancel_pending - cancelled - refund_pending - refunded如果支付已退但优惠券恢复失败系统要能表达“部分完成”不能只剩一个笼统的 success。3. 规则与权限合同把政策拆成条件、结论、例外、版本和责任人同时写清自动处理额度、审批角色和必须转人工的情况。高频、稳定、高风险的规则优先进入代码或决策表。自然语言文档仍然保留用来解释和检索。到了执行阶段系统需要知道采用的是哪一版规则。4. 工具合同每个工具只做一件清楚的事并写明前置条件、参数、返回值、副作用、幂等方式、可重试错误和终止错误。Anthropic 的工具设计经验里有一句很朴素如果工程师自己都说不清某个场景该用哪个工具就很难期待 Agent 选对。5. 验收合同如果验收里只有“正常取消成功”这类正例很多生产问题不会出现。对象不明确、状态变化、政策冲突、权限不足、重复请求、工具超时、部分成功和用户中途改口都值得单独留样本。每次线上误判也可以回到这五份合同里复盘是术语缺了、状态过期、规则没覆盖、工具设计重叠还是测试集没有收进这个例外。这样业务经验才会逐渐变成系统能力而不是下一轮继续补 Prompt。一张“业务理解卡”够小也够实用五份合同适合沉淀一条稳定流程。刚开始梳理具体任务时可以先用一张更小的卡片。任务 业务对象 当前状态 目标状态 事实来源 适用规则 允许动作 必须确认 完成证据 失败与补偿这张卡不是为了多写一份文档。十行里有三四行填不出来已经足以暴露流程缺口也说明它还不适合直接交给 Agent 自动执行。以研发里常见的“修复登录问题验证后发布”为例可以这样填任务修复登录后的重定向循环 业务对象目标仓库、当前分支、待发布服务 当前状态问题可复现生产版本保持不变 目标状态回归用例通过新版本发布后登录链路正常 事实来源问题记录、代码仓库当前提交、测试结果、运行日志 适用规则不修改认证模型不读取或回显生产凭证 允许动作在隔离分支修改、运行测试、构建候选版本 必须确认正式发布和生产配置变更 完成证据失败用例、代码差异、同一提交上的测试结果、发布版本、线上检查 失败与补偿停止扩大发布范围保留失败证据回滚到上一个已知版本这张卡把一句看似简单的研发指令拆成了几个不能混报的事实代码改了测试通过了候选版本构建出来了生产已经切换线上链路验证正常。它们彼此有关却不是一回事。放到生活场景里也成立。比如调整家庭行程事实来源可能是日历和车票订单必须确认的是通知同行人或支付改签费完成证据则是新的时间、订单状态和通知结果。流程轻很多结构并没有变。四种“看起来懂了”最值得拿来做测试测试集如果只放表达清楚、状态稳定、一步成功的样本很难看出系统是否真的理解业务。下面四种错位更接近生产现场。错位表面现象应有处理目标对了对象错了确实要取消订单却选中了同一用户的另一张订单停止执行补充对象确认规则对了状态旧了按“未发货可取消”处理但仓库刚刚完成出库执行前重新读取状态发现变化后重新决策动作合法身份不对退款动作存在但当前客服额度不足或跨组织操作由权限系统拒绝转审批或人工工具成功业务只完成一半订单取消成功退款成功优惠券恢复失败标记部分完成进入补偿或人工队列这四类失败分别对应对象绑定、状态新鲜度、权限边界和事务完整性。它们比“模型回答是否流畅”更能暴露系统的真实水平。上线初期让 Agent 少做一点Microsoft 在核心业务流程 Agent 模式里强调决策权和自治边界要在上线前写清业务结果仍由业务方负责。OpenAI 的 Agent 实践指南也把取消订单、大额退款、支付等动作列为需要人工监督的高风险操作。落到实施上我会分四步推进。先做历史回放找一批已经处理完的真实案例遮掉敏感信息让 Agent 只生成业务决策记录不调用写工具。人工对照原处理结果重点看对象、状态、规则、追问和拒绝是否正确。再跑只读影子模式让 Agent 跟着真实流量读取数据、给出计划但不产生副作用。这里能发现文档规则和线上状态不一致、接口字段含义混乱、权限信息拿不到等问题。只放开低风险路径查询、信息补齐、草稿生成可以先自动完成。退款、删除、外发、生产发布等动作仍停在确认点。每次确认都要展示对象、影响范围、采用的规则和预期结果。根据失败证据扩大边界稳定运行后再按具体流程、金额或对象范围增加自治权。误执行、人工接管、补偿和业务结果数据应该成为扩大边界的依据不能只凭团队感觉模型“已经挺聪明”。这套节奏看起来慢一点实际上省掉了不少上线后的返工。早期的自动化比例说明不了太多。一批经过核对的失败案例以及逐渐清楚的状态、规则和权限边界往往更有价值。指标也要跟着换意图系统常看 Accuracy、Macro-F1、混淆矩阵和 RecallK。这些指标仍然有价值可以定位理解层的问题。Agent 进入业务流程后还要再看几组指标层次更值得观察的指标理解层拒识率、追问率、对象绑定准确率、字段级 F1决策层规则命中准确率、状态读取新鲜度、权限拦截率、例外路由准确率执行层工具成功率、重复执行率、补偿成功率、高风险误执行率业务结果端到端完成率、人工接管率、处理周期、客诉与资金差错级联系统尤其需要分层看指标。目标意图没有进入 Top-K先查向量索引、样本覆盖和召回策略目标已经召回LLM 仍然选错再查意图定义、混淆反例和判断上下文计划正确但动作失败问题已经离开意图层应去看权限、工具和流程状态。如果只留一个整体 Accuracy这三类故障会被揉成同一个数字团队很难知道该改数据、改 Prompt还是改业务流程。Microsoft 最近发布的核心业务流程 Agent 模式也强调业务结果责任仍然在业务方评估应回到处理周期、吞吐、准确率、例外率和既有业务指标而不是只看模型回答得像不像。一个 Agent 可以把取消政策解释得很漂亮却把不该退的券退了。语言表现不错业务结果仍然是错的。业务理解要看状态有没有正确改变Prompt、意图分类、Embedding、RAG、LLM 都有自己的位置。它们帮系统从一句不完整的人话里找到方向。企业难复制的部分往往藏在方向之后团队怎样定义对象怎样判断状态哪些例外由谁批准失败后怎么补偿做到哪里才算完成。通用模型越来越强这部分工作也不会自然消失。模型可以帮助整理规则、生成流程、发现缺口企业仍要把自己完成工作的方式变成可执行、可验证、可维护的系统。回到开头那张订单我会看三个结果• 它有没有找到正确的业务对象和当前状态• 它有没有在规则与权限范围内选择动作• 动作结束后系统能不能证明业务对象已经到达目标状态。钱退到了哪里券有没有恢复订单最后停在哪个状态这些都能查清楚Agent 才算从“听懂一句话”走进了真实业务。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。
一文讲清 Agent 如何理解业务：把对象、状态和权限接进执行流程
发布时间：2026/7/30 3:15:45
用户问客服 Agent上次那单还没发能不能直接取消优惠券也退回来识别出“取消订单”并不难。模型甚至可以顺手抽出“未发货”“退回优惠券”两个条件给出一段很像样的回复。麻烦从这里才开始。“上次那单”是哪一单系统里的履约状态是否真的还是未发货优惠券是平台券、店铺券还是已经过期的活动券取消后原路退款还是退到余额当前用户有没有权操作这张订单这些问题没有答案Agent 只是听懂了这句话还没有理解这笔业务。碰到这种情况最顺手的改法往往是继续补 Prompt遇到“上次那单”优先查询最近订单用户说“还没发”就走未发货取消流程提到优惠券再补一条退券规则。前几轮可能真有效。问题在于Prompt 能提醒模型怎样分析却不能证明订单此刻处于什么状态也不能替权限系统批准退款。规则越补越长模型知道的似乎越来越多系统对真实业务的把握却未必增加。对会执行动作的 Agent我会把“理解业务”落到一件可以验收的事上它能否在明确边界内把正确的业务对象从当前状态推进到目标状态并留下可核对的依据。这比“意图识别准确率有多高”多走了好几步。查询类任务不一定改变业务对象但也要绑定可信状态和事实来源。本文更关注风险更高的一类Agent 听懂以后还要继续行动。我们在《如何为 Agent 设计产品》里讨论过产品能力要变成 Agent 能理解、调用、约束和审计的动作。这次再往业务内部走一层这些动作依赖的业务含义从哪里来又怎样落到状态、规则和权限里。太长不看• 意图识别回答“用户大概想做什么”它只是业务理解的入口。• 规则、分类器、Embedding、LLM 和 RAG 很少互相取代。生产系统更常见的是逐层分流复杂请求再升级。• 真正的业务理解至少包含六样东西统一术语、业务对象、实时状态、规则版本、权限边界和可执行动作。• RAG 可以找政策和案例不能替订单系统报告实时状态也不能替权限系统批准资金动作。• Prompt 适合告诉模型怎么分析业务规则和高风险边界更适合留在代码、流程或策略系统里。• 评估不能只看意图 Accuracy。还要看状态读取、规则判断、追问质量、误执行、高风险拦截和端到端完成率。Agent 理解业务的完整执行链图 1从自然语言到完成证据每一步都绑定明确的事实来源和责任边界。意图识别只回答了第一问过去十年任务型对话系统在意图分类上已经积累了很完整的技术路线。规则适合处理确定性请求也适合放安全拦截。标签稳定、数据量够时TF-IDF、FastText 配合逻辑回归或 SVM成本低延迟也容易控制。BERT 一类模型能处理更复杂的上下文JointBERT 还会把意图分类与槽位抽取放在一起训练把一句“帮我订周五从杭州到北京的机票”同时整理成目标和参数。新意图多、每类样本又少时可以先用 Embedding 做相似度召回原型网络和对比学习也常用于少样本分类让有限样本先形成可区分的类别表示。LLM 则擅长口语、省略、多轮修正和边界不断变化的长尾请求。这些方法并不是按年代依次淘汰前一种。实际选型通常取决于四件事• 意图有多少是否已经多到一份 Prompt 放不下• 标签是否经常调整新业务多久上线一次• 有没有足够的真实标注数据• 一次判断要回看一句话还是几轮对话和工具结果。生产系统里更常见的是级联。请求先经过规则和安全闸门稳定流量交给轻量分类器意图很多时Embedding 先召回 Top-K 候选仍有歧义的请求再交给 LLM涉及多个动作和依赖关系时才进入规划器或业务流程。请求越简单链路越短。只有复杂度上升时系统才增加推理成本。意图识别的级联架构与四类出口图 2不同技术各守一段边界复杂请求逐层升级最终进入执行、追问、拒识或确认。只是进入 Agent 系统以后输出不再是一张“转给哪个客服组”的标签。模型给出的结构会继续触发查询、退款、改签、发消息等真实动作。同样是 cancel_order至少还缺五个判断1. 操作的是哪个业务对象2. 对象现在处于什么状态3. 当前规则允许走哪条路径4. 这个人有没有操作权限5. 动作执行后怎样确认钱、券和订单都已正确变化。CLINC150 这类经典数据集专门加入了超出支持范围的请求因为分类器不能假设每句话都属于已有标签。到了 Agent 现场这个边界更重要。一个请求不在支持范围内最稳的结果是拒识、追问或转人工。硬选一个“最像的意图”后面可能就是一次错误写入。一次识别最终会进入四类出口之一执行、追问、拒识、确认。到了这一步输出已经从意图标签变成了控制流的下一步。意图识别做得再好也只能证明系统听懂了入口。它还没有证明整件事做得对。业务知识不是一摞可以检索的文档很多团队发现 Prompt 不够用下一步自然会想到 RAG把产品文档、客服手册、制度、历史工单全部放进知识库需要时检索给模型。这会有帮助却也很容易制造一种错觉资料找到了Agent 就懂业务了。文档里通常写着三类东西• 业务术语和政策• 操作流程和例外• 过去发生过的案例。真实业务还多出三类动态事实• 某个对象此刻的状态• 当前用户在当前组织里的权限• 刚才那次动作究竟成功、失败还是只处理了一半。前一组可以从文档检索。后一组必须回到订单、账户、权限、支付和审计系统里读取。Anthropic 在上下文工程文章里强调上下文是有限资源目标是给模型最少但高信号的信息。这解决了一个很现实的问题每一步推理到底该让模型看到什么。上下文工程解决模型此刻看见什么流程工程解决业务接下来允许发生什么。网上讨论里有人把它概括成一句 Context engineering ! process engineering。放到客服场景里这个区别很具体知识库可以把退款政策送到模型眼前订单状态、额度校验和审批结果仍要由业务系统给出。给模型一份退款政策它有机会解释政策。把退款条件、金额上限、审批角色和状态变化写进流程系统才有机会稳定执行政策。业务理解最后落到运行时对着当前对象读取当前状态套用当前规则再以当前身份行动。知识库能补充背景不能替代这条链路。先给业务一套共同语言Agent 业务理解并不是全新的软件工程问题。Eric Evans 在领域驱动设计里把领域模型定义为一组抽象用来描述业务领域中与解决问题有关的部分。他还强调统一语言和限界上下文同一个词只有放在明确边界里含义才稳定。“客户”在销售系统里可能是线索在合同系统里是签约主体在售后系统里又可能是服务权益的持有人。“取消”也不只有一个意思取消预约、撤销订单、终止合同、停止续费背后的状态变化完全不同。如果团队内部还在混用这些词模型很难替我们把它们自动理顺。第一步不必建设一套庞大的企业知识图谱。先把一个小流程里的六样东西写清楚业务要素取消订单场景里要回答什么统一术语“未发货”“已出库”“退款完成”分别指什么业务对象操作哪张订单、哪笔支付、哪张优惠券实时状态订单、履约、支付和优惠券当前是什么状态规则版本当前适用哪版取消和退款政策权限边界谁能查询、谁能取消、谁能批准例外退款可执行动作查询、取消、退款、退券分别调用哪个工具这六项放在一起才接近 Agent 可以使用的业务语义。它不一定要叫“语义层”也不一定要单独做成平台。初期可以只是几份版本化文件、几个清楚的接口和一张状态图。名字不重要关键是业务含义不能继续散在 Prompt、口头经验、数据库字段和客服脑子里。坦率说这六项也不是一套放之四海而皆准的标准模型。制造、金融、医疗、研发会有不同对象和约束。它更像一张排查表用来确认这条业务链路还有哪些地方只存在于人的经验里。同一句人话换个现场就会缺另一组条件订单取消是比较典型的企业流程。把视线放宽一点生活、工作和研发里其实都有同样的问题。一句自然语言Agent 真正动手前还缺什么“把明天下午的安排往后挪”哪个日历事件、挪到几点、参与人是否有空、是否要通知外部来宾“把上周出差的票都报了”哪次行程、哪些发票、费用归属、当前制度版本、审批人和重复报销检查“上周企业客户收入涨了多少”自然周还是最近七天、企业客户口径、收入定义、时区、退款和币种怎样处理“把登录问题修掉没问题就发版”哪个仓库和环境、怎样复现、改动边界、哪些测试算通过、谁有发布权、失败后回滚到哪里这些请求都不难听懂。真正的工作量藏在省略掉的业务条件里。拿“上周企业客户收入涨了多少”来说模型生成一条语法正确的 SQL 并不稀奇。可它如果把“上周”理解成最近七天把“收入”读成账单金额又没有排除内部测试账号最后的图表依然能画得很漂亮。这类错误麻烦在于它往往不会报错。查询能运行数字有小数点解释也顺。等答案进入周报和经营会错误口径已经离开了技术现场。研发任务也一样。“没问题就发版”至少跨过了四种状态问题能够复现代码已经修改本地和流水线检查通过线上版本完成切换。某个测试通过只能证明这一项检查通过不能自动升级成“已经发布”。自然语言更适合做任务入口不能直接拿来执行。Agent 先要补齐对象、状态、规则、权限和完成证据才能从“像是听懂了”走到“可以动手了”。对话状态、业务状态和执行状态别放进一个字段多轮对话里用户常常只说半句话换成明天吧。系统至少要知道当前任务是什么用户是在延续、切换、取消还是修正任务哪些参数已经确认哪些参数还缺以及上一次工具调用返回了什么。这些信息可以整理成一份对话状态例如active_intent intent_transition confirmed_slots missing_slots last_tool_result latest_user_correction对话状态记录的是“目前聊到哪里”不等于业务对象此刻的真实状态。状态回答的问题更可信的来源对话状态用户当前想继续、修改还是取消什么会话记录与结构化槽位业务状态订单、账户、库存现在是什么状态业务 API 和事实数据库执行状态动作是否开始、完成、重试或进入补偿工作流、任务队列和审计日志“用户刚才说订单没发货”只能进入对话状态不能直接写成 fulfillmentnot_shipped。后一个值必须从履约系统重新读取。复合任务还会再多一层。例如查一下本月云账单超过预算就暂停测试环境再通知项目负责人。这句话包含查询、条件判断、环境变更和消息通知。单标签分类只能说它“大概属于成本管理”却会丢掉动作之间的依赖关系。更可用的结果是一张小型执行图读取账单 - 对比预算 ├─ 未超预算 - 返回结果 └─ 超出预算 - 确认环境范围 - 暂停测试环境 - 校验环境状态 - 通知负责人到了这里意图识别已经开始进入语义解析、状态跟踪和任务规划。术语可以很多边界只有一个模型负责整理用户表达真实状态和副作用仍由业务系统负责。把一句话编译成业务决策记录回到开头那句话上次那单还没发能不能直接取消优惠券也退回来模型比较适合做第一段工作把自然语言整理成候选目标、对象线索和待确认项。但它不该凭聊天记录猜订单状态更不该根据“用户说还没发”就直接执行取消。一份更可用的中间结果大致会长成这样{ goal: cancel_order, object: { type: order, id: resolved_by_tool }, observed_state: { payment: paid, fulfillment: not_shipped, coupon: consumed }, policy_refs: [ order_cancel_policy:v7, coupon_restore_policy:v3 ], unresolved: [ refund_destination ], planned_actions: [ cancel_order, refund_payment, restore_coupon ], approval: { required: true, reason: financial_side_effect } }这份记录里的字段不能都交给模型填写• goal 和对象线索可以由模型解析• observed_state 必须由业务系统读取• policy_refs 要绑定明确版本• planned_actions 要经过规则与权限校验• approval 由风险策略决定不能让模型自己给自己放行。从架构上看它更像一个小型编译过程自然语言 - 候选业务目标 - 绑定业务对象 - 读取实时状态 - 应用规则与权限 - 生成动作计划 - 确认后执行 - 校验状态变化LLM 擅长处理前面的模糊表达。确定性系统负责中间的状态、规则和权限。工具执行器产生副作用验证器再检查结果是否符合预期。模型不需要包办每一步。分工越清楚出了问题越容易定位。在《Graph Engineering 详解Loop 之后Agent 工作流开始显式成图》里我们把任务依赖、分支和回流画成了一张图。走到业务现场还要多问一步节点读哪份状态边上传递哪种结果哪个位置会扩大权限。少了这些契约图画得再清楚运行时还是会猜。RAG 适合检索不适合裁决RAG 在这条链路里仍然很有用。它可以根据当前目标找到相关术语、政策、流程说明、正反案例和历史误判。意图很多时也可以先召回三到五个候选让模型在更小范围里判断。但有三类信息不适合让 RAG 当最终裁判。实时状态订单是否出库、付款是否到账、库存是否锁定要从当前业务系统读取。昨天的工单和知识库切片不能替代今天的状态。权限结果“主管通常可以退款”只是说明。当前操作人是否属于这个组织、额度是否超限、凭证是否有效必须由身份与权限系统判断。动作结果模型说“已经取消”没有意义。工具返回成功也还不够。系统还要继续读取订单、支付和优惠券状态确认这次业务事务最终落在预期位置。更稳的做法是把知识按角色拆开信息更合适的真相源术语、政策、SOP、案例版本化文档与检索系统订单、账户、库存、支付状态业务 API 或数据库服务身份、角色、额度、审批权认证与授权系统分支、超时、重试、补偿工作流或状态机调用结果、状态变化、责任人运行记录与审计日志Prompt、RAG、业务系统和工作流的职责对比图 3知识帮助模型理解业务系统和工作流负责让结果可信。Rasa 的 CALM 是一个值得参考的实现方向。它让 LLM 根据对话历史、相关 flow 和当前状态生成结构化命令业务逻辑则放在 flow 里。模型处理语言的灵活性流程保留业务执行的确定性。这比把 if/else 全塞进系统 Prompt 更容易版本化也更容易测试。理解、决策、执行最好分三层为了赶进度很多原型会让同一个 Agent 完成整条链路读用户输入、判断政策、选择工具、执行动作再自己宣布完成。Demo 很顺生产问题却会混在一起。一次退款失败到底是意图识别错了、订单状态读旧了、规则版本不对、权限判断漏了还是支付接口超时如果所有逻辑都藏在一段上下文里排查时只能重放整段对话。放到工程里我更倾向于拆成三层。理解层把人话变成业务候选输出目标、对象线索、参数、置信信息和待确认项。这里允许概率判断也允许拒识和追问。决策层把候选放进业务现场读取实时状态应用规则版本检查权限生成可执行计划。高风险规则尽量使用确定性代码、决策表或状态机。执行层让动作可控地产生副作用工具要有明确输入、输出、前置条件、幂等键和错误类型。涉及资金、删除、外发和不可逆动作时系统能停在“已选择工具尚未调用”的位置等待确认。HumanLayer 的 12-Factor Agents 特别强调控制流要支持暂停和恢复。人工确认不能等到 Agent 执行完以后再看日志系统要能在副作用发生前停住。三层不意味着一定要做三个 Agent。完全可以是一个 Agent 加两层普通代码。架构目标是分清责任不是增加角色。Agent 业务执行的三层架构图 4理解层处理模糊表达决策层绑定业务现场执行层控制副作用并留下证据。一条最小执行链路可以朴素到下面这样candidate understand(user_input) object resolve(candidate.object_ref) state read_source_of_truth(object) policy resolve_policy(candidate.goal, object, state, current_time) decision decide(candidate, state, policy, principal) if decision.requires_confirmation: pause(decision) result execute(decision.command, idempotency_key) evidence verify(object, decision.expected_state) record(decision, result, evidence)这里有两个细节很容易被省掉。principal 指当前以谁的身份行动。Agent 有工具调用能力不等于它继承了管理员权限。verify 也不是复述工具的成功消息而是重新读取业务对象核对预期状态是否真的出现。五份小合同比知识库大全更容易起步如果团队准备让 Agent 接一个真实业务流程我不会先做“企业知识库大全”。更稳的起点是挑一条窄流程做五份小合同。1. 术语合同列出业务对象、关键字段、同义词、容易混淆的词以及它们在哪个边界内成立。例如“退款完成”到底表示支付机构已受理还是资金已经回到用户账户。两种定义会带来完全不同的客服回复。2. 状态合同写清对象有哪些状态允许怎样迁移哪个系统是事实源。paid - cancel_pending - cancelled - refund_pending - refunded如果支付已退但优惠券恢复失败系统要能表达“部分完成”不能只剩一个笼统的 success。3. 规则与权限合同把政策拆成条件、结论、例外、版本和责任人同时写清自动处理额度、审批角色和必须转人工的情况。高频、稳定、高风险的规则优先进入代码或决策表。自然语言文档仍然保留用来解释和检索。到了执行阶段系统需要知道采用的是哪一版规则。4. 工具合同每个工具只做一件清楚的事并写明前置条件、参数、返回值、副作用、幂等方式、可重试错误和终止错误。Anthropic 的工具设计经验里有一句很朴素如果工程师自己都说不清某个场景该用哪个工具就很难期待 Agent 选对。5. 验收合同如果验收里只有“正常取消成功”这类正例很多生产问题不会出现。对象不明确、状态变化、政策冲突、权限不足、重复请求、工具超时、部分成功和用户中途改口都值得单独留样本。每次线上误判也可以回到这五份合同里复盘是术语缺了、状态过期、规则没覆盖、工具设计重叠还是测试集没有收进这个例外。这样业务经验才会逐渐变成系统能力而不是下一轮继续补 Prompt。一张“业务理解卡”够小也够实用五份合同适合沉淀一条稳定流程。刚开始梳理具体任务时可以先用一张更小的卡片。任务 业务对象 当前状态 目标状态 事实来源 适用规则 允许动作 必须确认 完成证据 失败与补偿这张卡不是为了多写一份文档。十行里有三四行填不出来已经足以暴露流程缺口也说明它还不适合直接交给 Agent 自动执行。以研发里常见的“修复登录问题验证后发布”为例可以这样填任务修复登录后的重定向循环 业务对象目标仓库、当前分支、待发布服务 当前状态问题可复现生产版本保持不变 目标状态回归用例通过新版本发布后登录链路正常 事实来源问题记录、代码仓库当前提交、测试结果、运行日志 适用规则不修改认证模型不读取或回显生产凭证 允许动作在隔离分支修改、运行测试、构建候选版本 必须确认正式发布和生产配置变更 完成证据失败用例、代码差异、同一提交上的测试结果、发布版本、线上检查 失败与补偿停止扩大发布范围保留失败证据回滚到上一个已知版本这张卡把一句看似简单的研发指令拆成了几个不能混报的事实代码改了测试通过了候选版本构建出来了生产已经切换线上链路验证正常。它们彼此有关却不是一回事。放到生活场景里也成立。比如调整家庭行程事实来源可能是日历和车票订单必须确认的是通知同行人或支付改签费完成证据则是新的时间、订单状态和通知结果。流程轻很多结构并没有变。四种“看起来懂了”最值得拿来做测试测试集如果只放表达清楚、状态稳定、一步成功的样本很难看出系统是否真的理解业务。下面四种错位更接近生产现场。错位表面现象应有处理目标对了对象错了确实要取消订单却选中了同一用户的另一张订单停止执行补充对象确认规则对了状态旧了按“未发货可取消”处理但仓库刚刚完成出库执行前重新读取状态发现变化后重新决策动作合法身份不对退款动作存在但当前客服额度不足或跨组织操作由权限系统拒绝转审批或人工工具成功业务只完成一半订单取消成功退款成功优惠券恢复失败标记部分完成进入补偿或人工队列这四类失败分别对应对象绑定、状态新鲜度、权限边界和事务完整性。它们比“模型回答是否流畅”更能暴露系统的真实水平。上线初期让 Agent 少做一点Microsoft 在核心业务流程 Agent 模式里强调决策权和自治边界要在上线前写清业务结果仍由业务方负责。OpenAI 的 Agent 实践指南也把取消订单、大额退款、支付等动作列为需要人工监督的高风险操作。落到实施上我会分四步推进。先做历史回放找一批已经处理完的真实案例遮掉敏感信息让 Agent 只生成业务决策记录不调用写工具。人工对照原处理结果重点看对象、状态、规则、追问和拒绝是否正确。再跑只读影子模式让 Agent 跟着真实流量读取数据、给出计划但不产生副作用。这里能发现文档规则和线上状态不一致、接口字段含义混乱、权限信息拿不到等问题。只放开低风险路径查询、信息补齐、草稿生成可以先自动完成。退款、删除、外发、生产发布等动作仍停在确认点。每次确认都要展示对象、影响范围、采用的规则和预期结果。根据失败证据扩大边界稳定运行后再按具体流程、金额或对象范围增加自治权。误执行、人工接管、补偿和业务结果数据应该成为扩大边界的依据不能只凭团队感觉模型“已经挺聪明”。这套节奏看起来慢一点实际上省掉了不少上线后的返工。早期的自动化比例说明不了太多。一批经过核对的失败案例以及逐渐清楚的状态、规则和权限边界往往更有价值。指标也要跟着换意图系统常看 Accuracy、Macro-F1、混淆矩阵和 RecallK。这些指标仍然有价值可以定位理解层的问题。Agent 进入业务流程后还要再看几组指标层次更值得观察的指标理解层拒识率、追问率、对象绑定准确率、字段级 F1决策层规则命中准确率、状态读取新鲜度、权限拦截率、例外路由准确率执行层工具成功率、重复执行率、补偿成功率、高风险误执行率业务结果端到端完成率、人工接管率、处理周期、客诉与资金差错级联系统尤其需要分层看指标。目标意图没有进入 Top-K先查向量索引、样本覆盖和召回策略目标已经召回LLM 仍然选错再查意图定义、混淆反例和判断上下文计划正确但动作失败问题已经离开意图层应去看权限、工具和流程状态。如果只留一个整体 Accuracy这三类故障会被揉成同一个数字团队很难知道该改数据、改 Prompt还是改业务流程。Microsoft 最近发布的核心业务流程 Agent 模式也强调业务结果责任仍然在业务方评估应回到处理周期、吞吐、准确率、例外率和既有业务指标而不是只看模型回答得像不像。一个 Agent 可以把取消政策解释得很漂亮却把不该退的券退了。语言表现不错业务结果仍然是错的。业务理解要看状态有没有正确改变Prompt、意图分类、Embedding、RAG、LLM 都有自己的位置。它们帮系统从一句不完整的人话里找到方向。企业难复制的部分往往藏在方向之后团队怎样定义对象怎样判断状态哪些例外由谁批准失败后怎么补偿做到哪里才算完成。通用模型越来越强这部分工作也不会自然消失。模型可以帮助整理规则、生成流程、发现缺口企业仍要把自己完成工作的方式变成可执行、可验证、可维护的系统。回到开头那张订单我会看三个结果• 它有没有找到正确的业务对象和当前状态• 它有没有在规则与权限范围内选择动作• 动作结束后系统能不能证明业务对象已经到达目标状态。钱退到了哪里券有没有恢复订单最后停在哪个状态这些都能查清楚Agent 才算从“听懂一句话”走进了真实业务。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。
