从规则引擎到AI Native：得物小摊的可控智能体交付实践

在接触“得物小摊”这个业务之前，我对 AI Native 的理解停留在“找个大模型接上，能聊就行”。真正把摊主的自动招呼、估价答疑、砍价引导这些能力叠加上去之后，我才意识到问题不在模型笨不笨，而在于我们从未给模型配上一套可以驾驭它的“马具”。

这套马具，就是 Harness。它不是某个具体软件，而是一整套围绕模型构建的工程化运行环境，涵盖输入改写、工具权限、上下文管理、安全护栏、全链路观测和灰度回滚。这篇文章把我们团队在“得物小摊”从规则系统演进到 AI Native 交付的完整过程写下来，包括为什么非改不可、Harness 到底管住了哪些事、四步演进路线怎么走，以及线上踩过的那些坑。如果你也在做业务 AI 化改造，或者正被 Agent 的不可控搞得焦头烂额，这篇应该能给你一些可以直接抄走的思路。

1. 小摊业务的“智能化焦虑”：从规则模板到 AI Native 的起点

1.1 一个看似简单的互动场景，为什么让运营痛不欲生

先交代一下“得物小摊”是什么。它是我们平台里的一个轻量化互动场景：用户可以在虚拟摊位上浏览潮流单品、向摊主提问、发出求购意向，甚至模拟砍价。看起来只是一个带点游戏味的电商前端，但它背后的对话和推荐逻辑非常重。

早期版本完全依赖规则引擎。运营同学手工配置了三百多条关键词模板和意图槽位，覆盖“这个多少钱”“有没有码数大一点的”“能不能便宜点”“适合送人吗”这些高频问题。一开始还能撑住，但随着商品池扩大、用户表达越来越口语化，规则系统开始露出疲态。比如“这鞋垫是不是有点薄啊，跑步会不会废脚”这种句子，没有一个正则能接住；“我预算八百，你帮我看看摊上有没有能打的”更是让意图识别直接崩掉。

最开始我们选择继续堆规则，结果发现运营团队每周要新增几十条模板，误匹配率反而越来越高。用户那边给出的反馈非常直接：摊主像个复读机，答非所问。我们统计过，规则引擎的冷启动匹配率在长尾问题里不到四成，大量对话被兜底话术吞掉，用户停留时长一个月内掉了十几个百分点。这已经不是体验问题，而是业务增长的天花板。

1.2 被逼到墙角的我们，决定换一种思路

正是在这个背景下，我们开始认真讨论 AI Native 这件事。所谓 AI Native，不是简单地在原有系统上挂一个聊天机器人，而是把“语言理解、语义推理、动态决策”作为业务主链路的默认能力，让规则退居二线，只做控制和兜底。

但对一个电商业务来说，完全放开让模型自由发挥是绝对不可能的。它可能说错价格、可能承诺不存在的优惠、可能在用户投诉时火上浇油。所以我们的 AI Native 演进从一开始就带着一个明确约束：不是追求模型有多聪明，而是追求在业务边界内可控地变聪明。这也是“可控 AI 交付”这个命题的由来。

现在回头看，这个起点非常关键。如果当时我们只是因为“大模型火”就盲目接入，后续一定会被各种线上事故击穿。正是因为先想清楚了可控性，后续引入 Harness 才不是多余动作，而是水到渠成的一件事。

2. Harness 工程化思路：为什么可控性才是 AI 交付的第一道门槛

2.1 模型是发动机，Harness 是整辆车的底盘

很多团队在接入大模型时有一个惯性动作：把 API 一封装，写两个 prompt 就开始内测。结果模型回答风格飘忽不定，偶尔还会胡编乱造。问题不出在模型，而出在缺少一个“让模型在既定轨道上运行”的工程环境。

Harness 这个词，直译是“马具”，用在 AI 工程里非常贴切。马跑得多快是马的能力，但往哪个方向跑、什么时候停、背上驮多少货物不翻车，是马具决定的。放到我们的场景里，模型是发动机，Harness 就是整车底盘——它负责把模型的能力传导到业务场景里，同时把风险隔离在驾驶舱之外。

网上很多教程会把 Harness 当成一个需要折腾插件的“外挂工具”，一会儿研究桌面端，一会儿研究插件市场，热度高但落地价值模糊。我们团队反其道而行之，没有去折腾那些花哨的功能，而是把 Harness 抽象成了我们自己的 AI 交付底座。具体来说，它管理六件事：

• 模型路由与供应商隔离：不同难度的问题走不同规格的模型，密钥和配额由内部网关统一管理；
• 上下文组装与压缩：把商品信息、用户画像、历史对话组织成干净的 prompt，超长时自动摘要；
• 工具注册与权限：模型能调用哪些函数、访问哪些数据，全部白名单控制；
• 记忆与状态管理：多轮对话中哪些信息要持久化，哪些信息用完即焚；
• 安全护栏：输入审计、输出合规检查、涉政涉暴过滤，全部在独立进程完成；
• 审计与观测：每一次模型调用、每一轮工具执行都有 trace，事后可回放。

2.2 Agent 和 Harness 的区别，到底在哪里

被问得最多的一个问题是：Harness 和 Agent 有什么区别？我的理解是，Agent 是“能自主决策的程序”，它代表一种行为模式；Harness 是“让 Agent 被掌控的运行环境”，它代表一种工程约束。

你可以把 Agent 想象成一个很有主见的实习生，能力强但容易自由发挥；Harness 则是实习生的工位——桌面只有工作需要的资料，右手边是审批流程，左手边是操作规范，一举一动都被记录。没有 Harness 的 Agent 不是不能用，而是你永远无法提前预判它会干什么；有了 Harness，Agent 的能力才是可预期、可度量、可干预的。

在“得物小摊”里，这个对比尤其明显。我们早期放了一个裸奔的 Agent 出去做估价对话，它表现得很“聪明”，会主动说“这款联名鞋最近行情不错，预估原价六折左右可以拿下”。但运营同学很快发现，它会在没有查询实时交易数据的情况下，给出一本正经的错误估价。这种错误比规则引擎答不上来更危险，因为用户会当真。Harness 上线后，我们把“估价”从模型的自由发挥变成了一个强制工具调用：模型只能基于查询结果生成回复，不能自己编数字。这就是可控交付的第一课。

3. 演进路线拆解：分四步把“摊主智能体”落到线上

3.1 阶段一：先用检索增强解决“答非所问”

我们的第一步不是直接上 Agent，而是老老实实做检索增强问答。这个阶段的目标只有一个：把“答非所问”的比例降下来。

具体做法是：先把商品库、尺码指南、售后政策、平台交易规则全部清洗成结构化的知识切片，写入向量库；用户提问后，先做意图识别和 query 改写，再检索相关片段，让模型基于检索结果生成回答。每个回答后面必须带上引用来源，用户点开能看到“参考商品详情页”或“参考售后政策第几条”。

这一步的效果立竿见影：长尾问题的有效回答率从四成出头提升到接近九成。更重要的是，因为所有回答都有引用，运营同学终于可以从“猜模型为什么这么回答”里解放出来，直接看引用是否正确。这也是我们后来评测体系里“事实一致性”指标的雏形。

3.2 阶段二：让智能体真正具备行动能力

能回答之后，下一步是能办事。这个阶段的标志性事件，是给“摊主智能体”接上了第一批工具：查库存、查价格、查询用户优惠券、创建求购意向单。

技术上就是 function calling，prompt 里声明工具的 JSON Schema，模型在对话中决定是否调用这批函数。但工程上的复杂度远高于表面：工具调用结果要拼回上下文、失败要能重试、调用过程要可计费和审计。我们在工具网关层做了一个中间件，所有由模型触发的调用都必须签名、限额、走统一日志，并且对敏感操作（比如提交订单、修改价格）做了强制二次确认。

这一步完成之后，“摊主智能体”才有点像回事：用户问“这个鞋有 42 码吗”，它会先查库存再回答；用户说“帮我留到晚上八点”，它会创建求购意向单并提醒绑定手机号。整个链路从“问答”延伸到了“行动”。

3.3 阶段三：从单一智能体到多角色协同

单一智能体能解决大部分点状问题，但解决不了需要多角色配合的场景。比如一个用户先问商品信息，再投诉物流，然后又想砍价——如果让同一个智能体处理所有事，它的角色会很拧巴，一会儿热情导购，一会儿客服赔礼，一会儿又要坚持底价。

所以我们把业务拆成了三个角色：摊主（负责商品介绍、估价、穿搭推荐），小二（负责售后、物流、投诉处理），买手（负责砍价、求购、出价建议）。每个角色对应一个独立的智能体配置，共享底层知识库和工具层，但拥有各自独立的 prompt 策略和边界约束。

多角色协同需要解决一个前置问题：路由。用户进来之后，先由一个轻量级意图识别器判断当前该由哪个角色接管，同时允许用户在对话中随时切换。我们做了一个事件总线，角色之间的状态通过结构化事件传递，而不是让模型从一个角色“扮演”成另一个角色。这种设计的稳定性比“一个大 prompt 塞三个角色”高很多，后续维护也轻松。

3.4 阶段四：把 AI 能力当成正式版本一起交付

走到这一步，AI 已经不是业务上的“彩蛋”，而是用户每天都会遇到的主干链路。正因如此，我们才把第四阶段的重心放在了交付体系上。这套体系包含三个层面：

• 配置版本化：每个智能体的 prompt、工具列表、模型参数全部进 Git，一次改动对应一个 MR，必须有评审记录和变更说明；
• 灰度发布：先切 5% 流量，观察自动回复率、用户投诉率、平均单轮对话成本，确认无异常后再逐步放量；
• 即时回滚：一旦线上指标触发阈值，运维平台自动把模型和 prompt 一起回退到上一个稳定版本，整个过程不需要开发介入。

这个阶段做完，AI 就真正变成了一条“正规军”。产品、运营、算法、平台研发之间的协作方式彻底变了：每次调整 prompt 都像发一次版，有人在看成本曲线，有人在看满意度指标，有人在看安全告警。

4. 可控交付的关键能力：评测、观测、护栏与回滚，一个都不能少

4.1 评测：不是几十条手工用例，而是一套分层体系

很多团队做 AI 评测，就是准备几十条 golden question，跑一遍看答案像不像。这种评测最大的问题在于滞后和主观：答案“看起来对”和“业务上可用”是两回事。我们搭建的是一套分层评测金字塔。

第一层是事实正确性。每条测试问题都预置了必须出现在回答里的“事实锚点”，比如商品名、价格区间、库存状态。模型回答里缺失或篡改锚点，就算失败。第二层是合规与语气。回答不能出现绝对化承诺、不能主动透露平台内部规则、不能在用户表达负面情绪时使用机械式话术。第三层是工具行为。模型在什么情况下应该调价、应该查库存、应该拒绝回答，都有标准行为模板对比。第四层是端到端任务成功率。模拟完整对话流程，看用户能否从提问走到成功留资或下单。

这套评测跑在每次变更之前的 CI 管道里，大概需要三到五分钟。发布 prompt 之前必须全绿，否则代码门禁直接拦截。有了它，我们不再靠“感觉这个回答变好了”来发版，而是有一个可量化的准绳。

4.2 观测：用 trace 把每一句话变成可回放的录像

大模型应用的可观测性，比普通后端服务难得多。普通接口请求是确定性的，同一个输入基本对应同一个输出；大模型应用的输出是概率性的，同一个 prompt 可能产生完全不同的回答，所以必须记录全链路的上下文特征，我称之为“回放式观测”。

我们为每个用户会话建立了一个贯穿全链路的 trace，包含以下关键节点：

{ "session_id": "stalker_20250101_00123", "trace_id": "tr_9f3e2a1b", "nodes": [ {"type": "intent", "result": "price_query", "latency_ms": 120}, {"type": "retrieval", "top_k": 5, "scores": [0.92, 0.88, 0.81, 0.75, 0.62]}, {"type": "tool_call", "name": "query_current_price", "args": {"sku": "SNK-88231"}, "status": "success"}, {"type": "llm_generation", "model": "pro-v3", "prompt_tokens": 1480, "completion_tokens": 230, "latency_ms": 1800}, {"type": "guardrail", "action": "pass"} ] }

有了这套 trace，我们排查线上问题时几乎不用靠猜。用户说“摊主乱报价”，只要拉出会话 trace，就能看到模型是否真的调用了价格查询工具、查询结果是什么、生成阶段是否有上下文遗漏。这种能力在规则引擎时代是没有的，也是我们迁移到 AI Native 之后才真正建立起来的安全感。

4.3 护栏：能力边界必须写在代码里，而不是写在 prompt 里

关于安全护栏，我有一条很深的体会：凡是只靠口语约束就能绕过的规则，都等于没有规则。很多团队在 prompt 里写“你不能编造价格”“你不能承诺包邮”，但大模型对这类指令的遵循程度极不稳定，尤其是面对用户长句诱导时。

我们的护栏最终全部下沉到了代码层：

• 输入侧：对用户文本做敏感词过滤和注入检测，遇到问题自动转移人工客服；
• 输出侧：对外发内容做二次合规检查，命中风险词直接拦截替换；
• 工具侧：所有的读操作和写操作严格分离，写操作必须走二次确认；
• 业务侧：价格、库存等数值类内容只信任工具返回结果，模型生成的数值一律丢弃。

这套护栏体系是独立于模型推理链路的一个旁路进程，意味着即使模型突然“发疯”，护栏也能在外层把危险内容扣下来。上线之后，“摊主智能体”的安全事故率降到了两位数的数量级，这是 Harness 给我们带来的第二重安全感。

4.4 回滚：把模型和 prompt 当作业务配置来管理

最后是可回滚能力。我们的回滚粒度不是整个服务，而是“模型版本 + prompt 版本 + 工具链版本”组成的一个部署单元。每次变更都生成一个版本号，灰度发布时带上这个版本号，线上流量可以在平台界面一键切回旧版本。

这里有一个小细节容易被忽略：回滚不只是切换版本号，还要考虑会话连续性的影响。假如用户在一个已经由新版本回答到一半的会话里，突然被切回旧版本，上下文可能对不上。我们的处理方案是：回滚后对进行中的会话强制开启新会话，并给用户一个友好的提示文案，而不是让新老版本在同一会话里“打架”。这个细节在压测中帮我们避免了好几类隐性故障。

5. 线上踩坑实录：幻觉、工具失败与上下文爆炸的应对细节

5.1 幻觉问题：模型一本正经报错价的根治方法

讲完体系，再聊几个让我们印象深刻的线上坑。

第一个坑就是幻觉。早期版本没有强制工具调用时，出现过一次很严重的事故：有用户问一款限量球鞋的二级市场价，模型凭空给出了一个“预估三千二”，实际平台近期成交均价是两千五。用户付款后发现价格不对，直接投诉到消费者热线。我们的处理方案前面提到过，把“数值类信息”从生成任务改成查询任务——凡是价格、库存这类硬数据，prompt 中明确告诉模型“你不知道，你只能查，查不到就说不知道”。这个约束写进 Harness 的工具策略层之后，同类问题再没有出现过。

不过这并不代表幻觉彻底消失了，更隐蔽的幻觉出现在“规则解释”里。比如模型会回答“平台支持七天无理由退换”，但具体到某些类目是有例外的。后来我们又叠加了一层“知识切片强制检索”，要求所有涉及售后政策的回答必须带出知识库切片 ID，没有切片佐证的内容直接拦截。这一步把解释类幻觉也压到了极低水平。

5.2 工具失败：AI 已读不回，用户心态瞬间爆炸

第二个坑是工具调用失败时，模型的应对特别蠢。有一次我们更新了库存接口，导致某类商品查询超时，模型的表现是长时间不回复，用户那边看起来就是“摊主已读不回”。有些用户连发三条消息，场面对话体验非常糟糕。

复盘之后，我们给工具调用加了三重保护。第一重是“调用前置反馈”：模型一旦决定调用工具，系统立刻先给用户返回“我正在查一下库存，稍等几秒”；第二重是超时重试和降级：第一次超时自动重试一次，仍然失败就降级到普通搜索，并把降级原因写进 trace；第三重是兜底话术：如果所有招数都失败，模型必须回复“我这边暂时看不到实时库存，你可以先加购物车，我会帮你留意”，不允许沉默。这套机制现在看起来简单，但当时是实打实地救回了那个晚上的大量会话。

5.3 上下文爆炸：延迟和费用一起失控

第三个坑是上下文爆炸。多轮对话场景下，如果把所有历史对话都塞进 prompt，请求体积会越来越大。上线初期我们没有做压缩，结果线上出现了一个怪现象：用户聊到二十轮之后，首字响应延迟翻了两倍不止，单轮费用更是涨了接近三倍。

解决办法是建立上下文分层管理机制。第一层是“会话即时上下文”，只保留最近五轮完整对话；第二层是“结构化记忆”，把用户表示过的关键信息（预算、尺码、意向商品、收货城市）抽取成结构化字段持久化；第三层是“摘要记忆”，每一轮结束后由小模型生成一句话摘要，取代过期的历史细节。模型最终看到的 prompt 是“五轮对话 + 结构化记忆 + 摘要 + 当前检索结果”的组合，既有足够的信息支撑，又不会无限膨胀。

这套机制上线后，长会话的平均 token 数回落了约 40%，同时因为信息密度更高，回答的准确率反而有小幅提升。这也印证了一个观点：大模型不是上下文越长越聪明，给它干净、相关、结构化的信息，效果远比硬塞全部历史要好。

5.4 预算失控：模型路由是省钱的最后一道防线

最后说一个所有 AI 业务都会遇到的问题：成本。我们一开始所有对话都用最强大的模型，账单出来的时候，整个团队都沉默了。后来引入了模型路由策略：用一个小模型做意图识别和意图改写，用中等模型处理大部分日常问答，只有复杂的多步推理和砍价谈判场景才升级到大模型。同时设置单用户单日预算上限，超限后自动降级到精简单回复。

模型路由本质上也是一种能力上的“可控”：在大模型能力过剩的场景里，用小模型省成本；在小模型能力不足的场景里，用大模型保体验。这个动态切分的逻辑由 Harness 统一管控，业务团队完全不用感知内部路由变化。

6. 组织流程联动：AI Native 之后，需求、验收和运营方式的改变

6.1 产品经理从“写逻辑”变成“写例子”

AI Native 演进到后期，我们发现在组织流程上最大的阻力不在研发，而在需求侧。传统 PRD 写得再详细，也只适合规则系统；到了模型这里，逻辑描述往往不如一条示例来得清楚。

我们现在要求产品经理在提出一个新能力时，必须同时提供一组“行为示例”：十个正向示例、五个负向示例、三个边界模糊示例。这些示例会直接进入评测集，成为模型行为验收的一部分。这看起来是把工作量转嫁给了产品，但实际上是在帮产品建立更清晰的行为预期。产品经理也开始习惯用“模型会不会在这个场景失控”来审视需求，这个变化我觉得是 AI Native 带给我们组织最大的收获。

6.2 验收标准变成“护栏内稳定表现”

过去验收一个功能，标准是“按 PRD 执行，无 bug”。现在验收一个 AI 能力，标准变成了“在评测集上全绿、在护栏范围内稳定、在核心场景上优于旧方案”。这里的关键是把“优于旧方案”定义成可量化的指标，而不是主观感受。

我们业务侧锁定的三个北极星指标是：有效应答率（用户没有重复提问就结束会话的比例）、任务完成率（走到留资或下单的会话占比）、安全拦截率（风险内容被成功拦截而不是外溢的比例）。所有模型或 prompt 变更，必须在离线评测和灰度数据上都优于这三个指标的基线值，才能全量上线。这套验收机制执行了三个月后，团队里很少有人再提“我觉得模型变聪明了”这种模糊的评价，大家讨论的都是数字。

6.3 运营同学的新角色：语料运营与 badcase 回流

传统运营在 AI Native 项目里很容易边缘化，但实际情况恰恰相反。我们需要有人每天蹲在线交易流水和 trace 回放里，把模型表现不好的对话打标签、提取特征、补充进评测集。这个角色我们内部叫“语料运营”：既要懂业务，又要能看懂 trace，还要能把问题定义成模型能听懂的评测用例。

最开始这个岗位被当成客服岗的附属，后来独立成型之后，直接成了模型迭代速度的重要影响因素。有一个很直观的数字：语料运营上岗之前，我们每周只能更新一次评测集；上岗之后，评测集几乎可以做到每日增量，模型的坏案例也在持续收敛。这让我深刻意识到，AI Native 的落地不能只靠算法工程师，它需要一整套新的岗位分工来支撑。

7. 从得物小摊看 AI Native 的下一站：Agentic 体验与生态

7.1 下一步：把 Harness 能力开放给更多业务方

“得物小摊”的 AI Native 演进走到现在，已经孵化出一套相对通用的 Harness 平台能力。我们的下一步，是把这套能力开放给平台内更多业务方，让其他想要做智能化改造的团队不用从零开始踩坑。模型路由、工具网关、评测管道、观测 trace、护栏策略，这些都是可以复用的公共能力。

不过开放不等于把配置面板丢给业务方随便填。我们在做的是把 Harness 进一步模板化：一个业务如果需要接入 AI，只需要定义自己的知识库类型、工具列表、护栏策略和评测集，剩下的运行环境全部由平台兜底。这样既保证了每个业务的独立性，也让平台层面的安全策略可以统一管理。

7.2 对 Agentic 体验的判断：从对话到自主行动

长期来看，我认为 AI Native 的下一个阶段是真正的 Agentic 体验。当前“得物小摊”的智能体本质上还是“对话增强”，用户在多大程度上能接受智能体主动代表自己执行任务，还是一个未知数。比如智能体在用户授权后主动比价、主动蹲守补货、主动处理售后进程，这些都会大幅改变用户的交互习惯。

我们已经在规划这一类能力，但每一步都走得很小心。核心原则就一条：可以自主，但必须可控。Agent 越主动，Harness 需要提供的约束层级就越高，一旦某个环节失控，用户损失的可能是真金白银。我倾向于把 Agentic 体验理解成一个权限边界逐渐扩大的过程：先从一个动作的自动化开始，发展到多步任务的编排，最后才谈得上全流程代理。每一层权限的放开，都需要配套的观测、护栏和回滚机制同步就位，这样 AI Native 才不会是沙滩上的城堡。

最后说一点个人体会。做“得物小摊”这一路，我最大的收获不是跑通了多少轮对话、降了多少成本，而是明白了“AI 可控交付”真正的含义：模型的能力边界是模糊的，但业务的边界必须清晰。Harness 就是用来把“模型的模糊能力”约束在“业务的清晰边界”之内的一整套工程手段。这套手段不值得吹嘘，但确实每一层都缺不得。如果你所在的团队也正在经历从“接个大模型试试”到“认真做 AI 交付”的过程，我的建议是：别急着追模型更新，先把 Harness 这层地基夯实，后面的大模型能力越强，你的地基越稳，收益才会越大。