一文讲清 Agent 如何理解业务：把对象、状态和权限接进执行流程

核心结论（一句话）

Agent 真正理解业务，不是能把一句人话分到正确意图上，而是能在明确边界内，把正确业务对象从当前状态推进到目标状态，并且全过程绑定真实状态、规则版本、权限边界与可核对证据。

分类提炼

知识节点（9 个独立概念）

关联图谱

上游（基于 / 来自）

下游（应用于 / 验证于）

同级（横向 / 并列）

正文要点（6 条）

  1. 意图识别最多只能证明系统听懂了入口，不能证明整件事做得对。
    一个请求最终至少要落到四类出口之一：执行、追问、拒识、确认。真正有风险的不是意图分错，而是意图分对以后，系统仍然不知道对象是谁、状态如何、权限是否成立。

  2. 业务知识不是一摞可检索文档，而是一条运行时真相链。
    文档和 RAG 适合提供术语、政策、案例和 SOP；订单是否未发货、当前客服额度是否足够、退款到底有没有成功，这些都必须回到事实系统里读取。知识帮助理解，业务系统和工作流负责让结果可信。

  3. 把业务理解最小化成六项语义，比上来就做“大语义层平台”更稳。
    统一术语、业务对象、实时状态、规则版本、权限边界、可执行动作，是把业务含义从 Prompt、口头经验、数据库字段和人工脑内迁回系统的最小起点。

  4. 自然语言最好先编译成业务决策记录，而不是直接驱动副作用。
    goal、对象线索和待确认项可以由模型整理；真实状态、规则版本、审批要求和动作计划要由业务系统和策略系统补全。这让“听懂一句话”先变成一份可审计、可暂停、可验证的中间产物。

  5. 动作型 Agent 的可靠架构，更适合理解层 / 决策层 / 执行层三层拆开。
    理解层允许概率判断、拒识和追问；决策层读实时状态、算规则、查权限；执行层持有幂等键、暂停点和事后验证。这样出错时才能定位是理解错、规则错、权限错，还是执行没完成。

  6. 真正能把业务理解落地的，不是更长 Prompt，而是小合同、测试样本、分阶段放权和新指标。
    五份小合同和一张业务理解卡，能快速暴露流程缺口；四类“伪懂”测试能逼出对象/状态/权限/事务完整性问题；上线则更适合历史回放 -> 只读影子 -> 低风险开放 -> 依据失败证据扩边，而不是一开始就追求全自动。

对 Seetong / APP AI 开发流程可借鉴动作（6 条）

  1. 每条可执行业务流都先补一张对象-状态-权限卡：任务、对象、当前状态、目标状态、事实来源、适用规则、允许动作、必须确认、完成证据、失败补偿，不清楚就先别自动化。
  2. RAG 只给解释层，不给裁决权：产品规则、FAQ、案例可走检索；设备状态、订单状态、用户权限、告警完成证据必须从实时系统与授权系统读取。
  3. 把高风险规则从 Prompt 挪到代码、决策表或状态机：退款、删除、发版、外发消息这类路径，别让模型靠“理解力”决定边界。
  4. 所有副作用前都保留暂停点，副作用后都做状态复核：不能只看工具返回 success，要重新读对象状态，核对是否真的到达目标状态。
  5. 测试集优先收“四类伪懂”反例：对象选错、状态读旧、身份不对、业务只完成一半，比标准正例更能暴露系统真实水平。
  6. 放权按证据升级，而不是按感觉升级：先历史回放，再影子读取，再只开低风险路径，最后依据误执行率、人工接管率、补偿成功率和端到端完成率逐步扩边。

备注与限制

相关链接