TECHNICAL DESIGN · 2026-09-03

食堂智能客服 Agent
处理流程与项目集成设计

解释用户问题如何经过大模型语义理解、项目能力路由、权限校验和真实数据查询，最终形成可核验的订单与退款答复。

store develop_ai_agent_0903 订单咨询现金退款退款订单只读 Agent

01｜核心结论

大模型负责理解，项目工具负责查证，权限系统负责边界，校验器负责防幻觉，人工负责敏感操作。

大模型不能直接连数据库，也不能靠记住项目代码回答实时订单和退款问题。它先把自然语言转换为结构化任务，后端再使用当前账号权限调用现有业务逻辑，结果通过校验后才能向用户陈述。

02｜总体处理链路

STEP 1用户输入问题、当前页面、最近对话

STEP 2模型理解意图、人物、退款类型、时间

STEP 3项目路由选择订单或两个退款域

STEP 4查询与校验权限内读真实数据并核验

STEP 5回答与入口事实答复、同范围页面动作

职责不能混用

层级	负责	不负责
大模型	自然语言理解、结构化任务、结果解释	数据库查询、权限判断、退款执行
业务路由	确定能力与查询域	生成未经验证的业务结论
项目工具	复用现有 Logic / Service / Model	绕过商户、门店和数据权限
校验器	判断真实、唯一、完整、可展示	把失败解释成没有记录
人工人员	退款、调账、补单等敏感操作	把审批权交给模型

03｜大模型如何结合项目

请求上下文

当前登录人、角色、商户、门店、页面和最近对话。权限范围由后端判断，不交给模型决定。

业务知识

业务词典、页面路径、状态解释和人工边界。适合放进系统提示词或RAG，不用于回答实时金额。

能力目录

告诉模型可用的订单、现金退款、退款订单查询能力以及参数Schema，不开放任意接口。

项目工具

后端工具复用现有业务逻辑，带着当前账号的部门、人员和餐厅权限查询真实数据。

关键边界：稳定知识通过提示词或知识库提供；订单数量、退款金额和审核状态必须通过项目工具实时查询。

04｜结构化任务协议

第一阶段模型只返回受约束 JSON，不直接生成最终业务答案。

{
  "intent": "refund_status_query",
  "entities": {
    "person_name": "赵宇彤",
    "refund_type": null
  },
  "time_range": { "preset": "last_1_month" },
  "need_live_data": true,
  "confidence": 0.96
}

后端校验字段、枚举和人员实体后，才生成能力执行计划。模型输出不能直接变成 SQL 或数据库条件。

05｜退款问题完整示例

用户：赵宇彤的退款进度怎么样？

模型识别为退款状态查询，人物为赵宇彤，退款类型未明确。
确定性业务规则发现“具名人员 + 类型缺失”，生成双域查询计划。
现金退款按部门权限查询；退款订单按订单人员和餐厅权限查询。
校验姓名完全匹配、同名情况、查询状态和结果完整性。
回答层把两类结果分开说明，并生成两个同范围页面入口。

是否具名	退款类型	系统行为
否	未明确	要求选择现金退款或退款订单，不查人员数据。
否	已明确	返回对应业务说明和入口。
是	未明确	同时查询两种退款，并分别回复。
是	现金退款	只查询现金退款。
是	退款订单	只查询退款订单。

查询到赵宇彤近一个月的两类退款记录：
现金退款1笔，申请金额20元，当前状态为待审核。
退款订单1笔，退款金额12.5元，当前状态为已同意。
你可以分别进入“现金退款”和“退款订单”页面核对详细记录。

06｜校验与失败处理

结果状态	含义	答复要求
verified	查询与校验通过	可以陈述笔数、金额和状态。
zero_result	查询成功但没有记录	明确说未查到记录。
ambiguous_person	人员同名或不唯一	要求补充部门或餐厅。
permission_denied	当前账号无权限	不泄露记录是否存在。
query_failed	查询执行失败	说明暂时无法核实，不得说没有记录。
result_truncated	结果超过读取上限	提示结果不完整，引导页面核对。

07｜权限与人工边界

Agent可以做

查询订单与退款状态
解释页面和处理流程
生成带筛选条件的入口
收集人工处理信息

Agent不可以做

新增、同意、驳回退款
修改金额、余额或流水
自动补单、冲正
绕过菜单与数据权限

手机号、证件信息、UUID、卡号和支付凭据不得进入大模型上下文。退款、调账、补单等写操作必须进入现有业务页面由人工复核。

08｜当前项目代码映射

代码位置	当前职责	架构位置
`application/p/controller/Agent.php`	请求接入、工具和权限注入	接入层、上下文层
`application/p/logic/AgentAssistant.php`	助手编排、能力匹配、降级回答	编排层、回答层
`CanteenCustomerServiceAgent.php`	订单/退款路由、统一只读策略、资金写请求前置拦截	业务路由、安全边界
`ConsumeOrderReadTool.php`	查询最近订单状态并校验姓名、状态证据、截断和筛选一致性	订单只读工具、结果校验
`RefundSupportReadTool.php`	现金退款与退款订单双域读取	工具层、校验层
`CashRefund.php` / `MealOrder.php`	现有业务查询逻辑	业务数据层

目标方案不重写原有退款逻辑，新增部分集中在结构化语义协议、能力目录、工具契约和结果校验。

09｜实施路径

先稳定只读能力：已完成订单、现金退款和退款订单工具契约、资金写请求拦截及具名双域查询；154个相关测试、935个断言通过。
再引入模型语义规划：模型输出固定JSON，增加同义表达、权限失败和模型不可用回归。
最后接知识库与运营指标：接入操作手册和制度，观察澄清率、工具失败率与人工转交率。

验收底线：答案与页面入口必须来自同一人员、时间、退款类型和权限范围；任何一步未验证，都不能生成确定性业务结论。