从门店补货到退改签：为什么说“本体设计”是企业级 Agent 的第一道护栏？
返回博客列表
前阵子和同事聊起企业级 AI 落地，他分享了一个关于零售门店自动补货的本体设计案例。这个看似寻常的场景，却解开了我心中关于 Agent 落地架构的很多困惑。
在传统的系统里，门店补货可能就是一个简单的库存警戒线触发公式。但真正的业务远比这复杂：当前货架库存、历史销量预测（需求波动）、供应商配送周期（在途物资）、牛奶等鲜食的保质期（过期损耗风险）、起订量限制（MOQ）、甚至是天气和促销活动。
一个经验丰富的店长在做补货决策时，大脑中其实持有一套完整的“领域本体”（Domain Ontology）——他能清晰地感知实体间的关联，在多重约束下做出合规且最优的行动，并让订单在不同状态间流转。
如果把这个任务直接丢给一个只套了简单 Prompt 的大模型，结局通常是灾难性的：它可能会订购 500 箱后天就过期的酸奶，或者在供应商合同失效时强行下单。因为大模型缺乏对这个业务领域的“确定性语义蓝图”。
这让我意识到，本体（Ontology）在 AI-Native 时代，绝不是学理上的静态数据库 Schema，而是 Agent 真正能与物理世界规则对接的核心语义底底座。
🛠️ 标准化：我们将“本体设计”固化为一个 Skill
在日常的 AI 产品实践中，如果每次都以“脑暴提示词”开始，Agent 的行为就会变得不可预测。因此，我们在团队的 AI 产品经理工具箱中，将本体设计固化为了一个通用的标准能力——agent-ontology-designer（参见 agent-ontology-designer Skill 规范）。这也是我们沉淀在 AI Accelerator - AI 创新加速器 和 AI 2.0 产品实践指南 中的核心工具之一。
我们倡导的本体设计，遵循一套**「三层建模方法论」**：
| 建模层级 | 核心解决问题 | 建模具体内容 |
|---|---|---|
| Layer 1 · 对象关系 | 这是什么？ | 领域内的实体（Entity）、关键属性（Attribute）、实体间的关联与概念边界。 |
| Layer 2 · 行动边界 | 现在能不能做？ | 判定决策的情境（Situation）、所需证据（Evidence）、合法动作、禁止动作以及异常触发条件。 |
| Layer 3 · 状态迁移 | 做完以后去哪里？ | 核心执行流（Workstream）、状态节点（State）、迁移条件、安全护栏以及跨流依赖关系。 |
在实操中，产品经理不需要直接去写复杂的代码，而是通过一份结构化的 YAML 文件定义这三层模型。然后，利用我们提供的编译工具，一键生成一个带有交互的三 Tab 页面（包含对象关系卡片、行动边界四象限和状态迁移内联 SVG 图）。这使得业务团队与技术团队在开发前，就能在“颗粒度”极细的层面上对齐业务逻辑。
🎯 案例剖析：为什么 12306 退改签更需要本体驱动？
理解了门店补货的逻辑，我们再来看一个更硬核、精度要求达到 100% 的财务红线业务——12306 火车票退改签系统。
这个场景的规则错综复杂，几乎是所有智能客服系统的“噩梦”：
- 取整规则的差异性：境内车票退票费是票价乘费率，尾数处理遵循“5角取整”规则（即小于0.25元舍去，0.25至0.75元之间计0.5元，大于等于0.75元进1元）；而广深港跨境车票退票费则是直接向下截断取整到元；中老铁路跨境票则是四舍五入保留到元。
- 状态与次数的强约束：每张车票仅限改签一次。如果一张车票已经改签过，且列车已经发车，那么它将绝对禁止退票。
- 时间的敏感度：普通境内车票变更到站必须在开车前 48 小时以上办理，广深港跨境车票在西九龙站发车前 30 分钟截止办理。
- 特殊免责政策：为了提升体验，购票成功 30 分钟内且距发车 4 小时以上，注册用户可以享受免费的“误购退票”（每日限1次）。
在这个场景下，如果仅仅通过 Prompt 提示词让大模型直接去计算费用或判断能不能退，大模型不仅会出现各种精度计算错误，还容易被用户的越狱词汇绕过费用规则。
它和门店补货非常类似：一个决策的产生，依赖于车票状态、购票时间、乘车区间、支付方式等多维实体的交叉校验。 稍有漂移，就是直接的财务损失。因此，我们必须为 Agent 绘制一张严密的“本体地图”。
📝 实操展示：12306 退改签客服的本体设计
在 TicketAgent 项目中，我们为退改签客服 Agent 梳理并编写了一份详尽的 YAML 本体文件（参见 12306退改签客服Agent-本体设计.yaml）。
我们可以看一下它是如何用三层模型解构 12306 业务的：
Layer 1 · 对象关系（Entities & Relationships）
我们定义了核心实体 ticket，它包含 ticket_type（普通票、积分票、广深港跨境票等）、status（未出行、已改签、已退票等）、price 以及 departure_time。此外，还有 refund_fee_rule（退票费规则）和 passenger（旅客账号类型）。这些实体通过“持有”、“适用”、“约束”等逻辑关系编织在一起。
Layer 2 · 行动边界（Action Boundaries）
针对具体的决策场景定义“四象限约束”。以“误购退票”（ab_mistaken_purchase_refund）为例：
- 所需证据：用户必须是 12306 注册用户；购票距当前时间在 30 分钟内；发车时间在 4 小时以上；当日未用过该额度。
- 合法动作：通过 12306 线上渠道免费办理退票。
- 禁止动作：不允许对改签过的车票办理误购退票；中老铁路跨境票不适用。
- 异常触发：若不满足时间差，主动澄清并切入常规退票计费流程。
Layer 3 · 状态迁移（Workstreams & States）
定义了三条核心执行流：
ws_query_identification（问题识别与意图分类流）ws_refund_calculation（退票计算与渠道引导流）ws_rebooking_guidance（改签引导与费用计算流）
这份 YAML 通过本体设计器的编译，产出了一份直观的交互式 HTML 文档（参见 12306退改签客服Agent-本体设计.html），成为了 PM、架构师和开发团队拉齐认知的“普通话”。
🧪 验证与迭代：用 Ticket-QA-Agent Skill 跑通沙盒测试
在进入真正的应用工程开发之前，如何验证这套本体逻辑是闭环且可行的？
我们的做法是：先搭建一个单纯的政策咨询问答 Skill，并在沙盒环境中进行饱和测试。
我们实现了一个 ticket-qa-agent Skill。它的 System Prompt 很大程度上是本体 YAML 中自动编译生成的 Prompt 片段。它赋予了大模型严厉的角色定位：扮演 12306 客服，严禁在未收集齐参数前盲目计算，严禁对积分票、开车后改签票给出退票指引，并在遇到极端索赔、自然灾害停运等服务边界事件时，强制进行人工分流和安全提示。
为了测试这个 QA Agent 的鲁棒性，我们构建了一套包含 120 多个复杂边界的测试用例集，通过自动化测试运行器（scripts/run_tests.py）进行批量回归测试。
每次修改本体规则后，只需一行命令：
python3 scripts/run_tests.py tests/Agent测试用例集.md tests/reports
测试引擎会比对 Agent 的回答意图、提取的参数和计算结果，生成交互式 HTML 测试报告。这种“数据驱动、本地回归”的开发手感，让我们在写一行交易执行代码之前，就已经确信 Agent 的语义理解和规则边界是 100% 对齐官方政策的。
🏗️ 落地终态：转化为真正的 Agentic AI 交易应用
咨询问答只是第一步。当旅客问完“我这张票退票要收多少手续费”并得到准确回答后，下一步必然是“帮我把这张票退了”。
这就需要我们从一个“只说不练”的问答 Chatbot，演进为一个具备真实交易执行能力的企业级 Agent 软件。
根据 TicketAgent 项目的架构设计（参见 arch.md），我们确立了这套系统的黄金架构原则：
💡 “让大模型做语义理解，让本地代码做确定性裁决，让服务端承担唯一执行边界。”
系统的分层架构设计如下：
+--------------------------------------------------+
| 展示与交互层 (React UI) |
| (ChatPanel / TicketBoard / CalculatorPanel) |
+------------------------+-------------------------+
| (Fetch API)
+------------------------v-------------------------+
| 接口编排层 (Next.js API Routes) |
| (/api/chat / /api/ticket/execute) |
+------------------------+-------------------------+
| (State & Intents)
+------------------------v-------------------------+
| 状态机与流程编排层 (LangGraph 状态节点) |
| (agentGraph.ts) |
+------------------------+-------------------------+
| (Domain Operations)
+------------------------v-------------------------+
| 领域策略与规则层 (ticketPolicyService / rulesEngine) |
| (TypeScript 确定性费用与规则裁决) |
+------------------------+-------------------------+
| (Read/Write)
+------------------------v-------------------------+
| 数据与配置层 (mockDb / Config) |
+--------------------------------------------------+
我们在正文中探讨过，在 落地企业级AI应用，产品经理要会的20件事 中，我们提到过系统规则的刚性边界。在这套混合架构中，大模型不持有任何财务和改签逻辑，它仅仅作为“语义翻译器”。
当用户输入“我要退票”时，调用链路如下：
/api/chat接口调用大模型，大模型理解语义并提取结构化 hints（如：动作是退票，目标车票ID是 1002）。- 参数被注入到状态机
agentGraph.ts。 - 状态机并不自己去判断能不能退，而是将参数原封不动地传给底层的
ticketPolicyService.ts（统一策略服务）。 ticketPolicyService.ts调用纯 TypeScript 编写的rulesEngine.ts（规则引擎），执行 5角取整、跨境票截断、改签次数校验等确定性计算。- 策略服务返回裁决对象（如：
READY，应退金额 54.5元，退票费 5.5元）。 - 大模型拿到这个确定性结果，组合成亲和的自然语言回复用户。
- 当用户在 UI 界面点击“确认退票”按钮时，请求直接发送给
/api/ticket/execute交易执行接口，该接口绕过大模型，直接调用同一套ticketPolicyService进行二次校验，确认无误后直接落库mockDb。
正如我们在 破局单点提效：企业 AI 价值创新的4个举措 和 Agent 时代，企业软件的 9 个变化 中所倡导的，这种设计的精妙之处在于：聊天确认结果与实际点击执行逻辑，共享同一个物理“真理源”（Single Source of Truth）。
这彻底消除了“Agent 聊天时满口答应可以免费退，用户点击执行后却扣了 50% 手续费”的规则漂移。
✍️ 写在最后
从一间零售门店的自动补货决策，到 12306 火车票退改签的财务红线，企业级 Agent 的落地路径正变得越来越清晰。
我们不能寄希望于通过无限叠加 Prompt 来试图堵住大模型的逻辑漏洞，那只是精巧的“沙堆城堡”。真正的解法，是像产品经理做业务建模一样，用本体设计为 Agent 搭建起骨架，再用本地确定的规则引擎守住交易的底线。
大模型赋予了系统温度与理解力，而本体和规则，赋予了系统活下去的确定性。
你在落地企业 Agent时，是否也遭遇过大模型在规则多重叠加时的“逻辑崩溃”？欢迎在评论区或后台留言，聊聊你的实战手感。
#AI产品经理 #本体驱动 #AgenticAI #12306退改签 #架构设计 #Skills实战
