在接触“得物小摊”这个业务之前我对 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 不是不能用而是你永远无法提前预判它会干什么有了 HarnessAgent 的能力才是可预期、可度量、可干预的。在“得物小摊”里这个对比尤其明显。我们早期放了一个裸奔的 Agent 出去做估价对话它表现得很“聪明”会主动说“这款联名鞋最近行情不错预估原价六折左右可以拿下”。但运营同学很快发现它会在没有查询实时交易数据的情况下给出一本正经的错误估价。这种错误比规则引擎答不上来更危险因为用户会当真。Harness 上线后我们把“估价”从模型的自由发挥变成了一个强制工具调用模型只能基于查询结果生成回复不能自己编数字。这就是可控交付的第一课。3. 演进路线拆解分四步把“摊主智能体”落到线上3.1 阶段一先用检索增强解决“答非所问”我们的第一步不是直接上 Agent而是老老实实做检索增强问答。这个阶段的目标只有一个把“答非所问”的比例降下来。具体做法是先把商品库、尺码指南、售后政策、平台交易规则全部清洗成结构化的知识切片写入向量库用户提问后先做意图识别和 query 改写再检索相关片段让模型基于检索结果生成回答。每个回答后面必须带上引用来源用户点开能看到“参考商品详情页”或“参考售后政策第几条”。这一步的效果立竿见影长尾问题的有效回答率从四成出头提升到接近九成。更重要的是因为所有回答都有引用运营同学终于可以从“猜模型为什么这么回答”里解放出来直接看引用是否正确。这也是我们后来评测体系里“事实一致性”指标的雏形。3.2 阶段二让智能体真正具备行动能力能回答之后下一步是能办事。这个阶段的标志性事件是给“摊主智能体”接上了第一批工具查库存、查价格、查询用户优惠券、创建求购意向单。技术上就是 function callingprompt 里声明工具的 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 统一管控业务团队完全不用感知内部路由变化。场景初始模型路由后模型成本变化意图识别/query改写大模型小模型降低超80%日常商品问答大模型中模型降低约55%多轮砍价谈判大模型大模型不变长会话摘要压缩大模型小模型降低近90%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 这层地基夯实后面的大模型能力越强你的地基越稳收益才会越大。
从规则引擎到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 不是不能用而是你永远无法提前预判它会干什么有了 HarnessAgent 的能力才是可预期、可度量、可干预的。在“得物小摊”里这个对比尤其明显。我们早期放了一个裸奔的 Agent 出去做估价对话它表现得很“聪明”会主动说“这款联名鞋最近行情不错预估原价六折左右可以拿下”。但运营同学很快发现它会在没有查询实时交易数据的情况下给出一本正经的错误估价。这种错误比规则引擎答不上来更危险因为用户会当真。Harness 上线后我们把“估价”从模型的自由发挥变成了一个强制工具调用模型只能基于查询结果生成回复不能自己编数字。这就是可控交付的第一课。3. 演进路线拆解分四步把“摊主智能体”落到线上3.1 阶段一先用检索增强解决“答非所问”我们的第一步不是直接上 Agent而是老老实实做检索增强问答。这个阶段的目标只有一个把“答非所问”的比例降下来。具体做法是先把商品库、尺码指南、售后政策、平台交易规则全部清洗成结构化的知识切片写入向量库用户提问后先做意图识别和 query 改写再检索相关片段让模型基于检索结果生成回答。每个回答后面必须带上引用来源用户点开能看到“参考商品详情页”或“参考售后政策第几条”。这一步的效果立竿见影长尾问题的有效回答率从四成出头提升到接近九成。更重要的是因为所有回答都有引用运营同学终于可以从“猜模型为什么这么回答”里解放出来直接看引用是否正确。这也是我们后来评测体系里“事实一致性”指标的雏形。3.2 阶段二让智能体真正具备行动能力能回答之后下一步是能办事。这个阶段的标志性事件是给“摊主智能体”接上了第一批工具查库存、查价格、查询用户优惠券、创建求购意向单。技术上就是 function callingprompt 里声明工具的 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 统一管控业务团队完全不用感知内部路由变化。场景初始模型路由后模型成本变化意图识别/query改写大模型小模型降低超80%日常商品问答大模型中模型降低约55%多轮砍价谈判大模型大模型不变长会话摘要压缩大模型小模型降低近90%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 这层地基夯实后面的大模型能力越强你的地基越稳收益才会越大。
