在干线物流AI系统的开发中，从多Agent协作的混乱到敏感数据泄露的危机，再到Token成本失控的挑战，项目团队踩过的每一个坑都揭示了AI产品落地的真实困境。本文通过六个实战案例，拆解如何用工程化思维驾驭AI能力——从上下文管理到执行边界设定，从成本分层优化到评测体系构建，这些被OpenAI称为Harness Engineering的方法论，其实早已渗透在解决实际问题的过程中。

做路况分析系统那会儿，我根本不知道 Harness Engineering 这个词。

去年十月我接手了一个干线物流的AI项目——日均2000多台车在途，路况异常每天能触发200多起，暴雨、事故、管制什么都有。传统模式就是调度员盯屏幕加打电话，一次异常从发现到决定改不改线，平均要45分钟。公司希望搞一套AI系统，把异常响应从人盯人变成AI驱动+人工兜底。

从方案设计干到PoC验证。最后做了一个六个Agent协作的多智能体系统，效果还不错——改线方案采纳率72%，异常响应时间从45分钟压到8分钟，ETA偏差率从15%降到6%。

今年二月，OpenAI发了那篇关于Harness Engineering的文章，朋友圈刷了一波。我点开看完，第一反应不是好厉害，而是——这不就是我过去几个月一直在做的事吗？

上下文怎么管、任务怎么编排、边界怎么卡、效果怎么测，这些东西我全都做过，只是当时没有这个名字。所以这篇文章不打算再讲一遍HE是什么，市面上这类科普已经够多了。我想从自己做项目的经历出发，聊聊实际遇到了什么问题、怎么解决的，以及作为一个PM我现在怎么看这件事。

先说一句话背景

Agent = 大模型 + Harness Engineering。

模型之外的一切——上下文怎么管、任务怎么编排、边界怎么卡、效果怎么测——都属于Harness Engineering的范畴。如果你之前做过提示词优化、做过上下文管理、搭过评测体系，你其实已经在做HE了，只是当时没有人给它起名字。

项目背景：我接手了一个什么样的场景

干线物流，听起来很传统，但问题很真实：

• 日均2000+台车在途
• 路况异常（暴雨、事故、管制等）日均触发200+起
• 传统模式：调度员人工监控+打电话
• 一次异常从发现到改线决策，平均耗时45分钟
• ETA预测偏差率超15%，客户投诉率居高不下

业务需求很明确：搞一套AI系统，让异常响应从”人盯人”变成”AI驱动+人工兜底”。我带着5人团队（算法+后端+前端+业务+设计），从方案设计干到PoC验证。

问题一：六个Agent一起跑，谁先谁后全乱了

项目初期，我们的系统需要六个Agent协作：有负责路况感知的，有负责异常归因的，有负责改线决策的，还有负责调度通知的。

最开始我想的比较简单，让每个Agent自己判断接下来该干什么——看到用户请求就自己决定调什么工具、走什么流程。类似于你去一个陌生城市旅游不做攻略，走到哪算哪。

结果很快就乱了。路况感知Agent还没出结论，改线决策Agent已经开始生成方案了，拿的是上一轮的旧数据。有时候两个Agent同时调用同一个接口，返回结果互相覆盖。更离谱的是偶尔会出现循环调用——A调B，B又调A，Token哗哗地烧。

后来我们改了架构，用了Plan-and-Execute模式：设一个主Agent作为Planner，它只负责理解需求和拆解任务，生成一个执行计划；六个子Agent作为Executor，按照计划一步步执行，每一步执行完把结果回传；主Agent根据执行偏差决定要不要调整计划。

改完之后稳定性提升很明显。物流这种场景有一个特点——流程是相对确定的。路况异常进来，一定是先感知、再归因、再决策、再通知，这个顺序不会变。不适合让Agent自由发挥，必须先规划再执行。

后来我看到HE的资料里把这叫Agent Loop就是你怎么设计Agent执行任务的循环方式。有ReAct和Plan两种主要模式。我们的场景天然适合Plan模式，但这个判断是踩了坑之后才做出来的。

踩坑教训：不是所有场景都适合让Agent自由发挥。流程越确定的业务，越应该用Plan模式把执行路径锁死。

问题二：Agent差点把不该给用户看的数据吐出去了

有一次内部测试，我发现异常归因Agent在回复里把一个客户的合同金额拼进去了。虽然只是测试环境，但把我吓出一身冷汗。

复盘了一下原因：我们在系统提示词里写了不要泄露客户敏感信息，但大模型对敏感信息的理解跟我们的理解不一样。合同金额在模型看来可能只是一个数字，它不理解这东西不能出现在面向调度员的回复里。

这件事教会我一个道理——涉及安全和权限的事，不能只靠提示词。提示词是软规则，大模型不一定每次都遵守。必须在代码层面加硬规则做兜底。

后来我们做了几件事：

第一，给每个Agent定义了明确的能力边界。每个Agent只能调用它被授权的工具，只能访问它被允许的数据范围。路况感知Agent只能读路况数据，看不到客户合同信息；改线决策Agent能看到SLA约束，但看不到合同金额。

第二，在Agent输出之前加了一层过滤。代码层面检查回复里有没有出现预定义的敏感字段——合同金额、客户联系方式、内部系统ID这些，一旦命中就拦截重新生成。

第三，关键操作加审批。比如涉及到跨区域调度或者大额赔付建议的决策，Agent不能直接输出，必须标记为待人工确认。

这些后来在HE的框架里被归纳为执行边界——软规则定方向，硬规则守底线，权限约束控范围。听起来很学术，但在项目里就是因为差点出事故才逼出来的。

踩坑教训：涉及安全的事，永远不要只靠提示词。提示词管80%，剩下20%必须靠代码拦截。

问题三：Token成本扛不住，老板问我为什么一天烧这么多钱

项目刚上线测试的第一周，我算了一下Token成本，吓了一跳。六个Agent都用的同一个强模型，每次端到端决策的Token消耗非常高。按当时的调用频次推算，一个月光模型调用费就是一笔不小的数。

老板不懂什么Token不Token的，他只关心一件事这个：系统一天花多少钱、值不值。

我回去仔细分析了一下每个Agent的任务特点，发现不是所有环节都需要用强模型。比如路况感知Agent做的事相对简单——解析结构化的路况数据、提取关键信息，这种事小模型完全能干。但改线决策Agent要综合考虑路况、车辆状态、客户SLA、历史案例，这确实需要推理能力强的大模型。

于是我们做了分层配置：关键决策环节用强模型保质量，执行环节用轻量模型控成本。具体怎么选，我建了一个评估框架，从任务复杂度、模型能力、调用稳定性、Token成本四个维度去打分，每个环节单独评估。

最终效果是单次端到端决策的Token成本控制在五毛以内。老板听了觉得可以接受。

后来看资料才知道这叫多模型路由，是HE里上下文管理和成本治理的一部分。但做的时候真没想过什么路由不路由，就是被成本逼的。

踩坑教训：不是所有环节都需要最聪明的模型。按任务复杂度做分层，是控制成本最直接的办法。

问题四：Agent拍脑袋出方案，调度员说这方案拍脑袋想的吧

系统最早输出的改线方案纯靠模型自己推理。一条路封了，它就根据地图数据算一条新路线出来。从技术角度看方案是合理的，但调度员看了直摇头——这条路我们以前走过，晚高峰堵死了、这个方案绕太远了，上次类似情况我们走的是另一条。

问题出在模型没有历史经验。它只有当前的信息，不知道过去类似的情况是怎么处理的。

后来我们做了一个向量知识库，把历史改线案例、路段通行规则、客户SLA协议这些数据统一清洗、切片、向量化入库。设计了一个基于路段+异常类型+时段的多维检索策略——改线决策Agent在生成方案之前，先去检索历史上类似场景下的成功案例，拿过来做参考。

效果很直接：命中历史最优解的比例达到了68%。调度员看到方案里附带着历史参考案例和引用来源，信任度一下子就上来了。

这里还有一个小细节。我加了一条产品规则：Agent输出的每一个决策建议，必须携带引用来源。如果检索不到相关案例，就明确标注”无历史参考，建议人工复核”。模型有时候会编造一个看起来很合理的引用，所以我们又在后面加了一层校验——引用的案例必须真实存在于知识库中，否则强制重新生成。

用工程手段约束模型的幻觉，比在提示词里写请不要编造信息管用太多了。

踩坑教训：模型没有经验，你得给它经验库。决策必须带引用，引用必须可校验——用工程约束治理幻觉。

问题五：上线前觉得没问题，上线后一堆BadCase

这个坑应该很多做Agent产品的PM都踩过。

我们在上线前做了模型层面的测试，意图识别准确率、幻觉率、工具调用成功率，数据都还不错。上线后第一周就收到了大量反馈——”方案不可用响应太慢给了一个上周的旧数据”。

复盘之后发现，模型层面的测试只能说明这个模型基础能力没问题，但不能说明这个系统作为一个整体能不能用。问题出在Agent之间的协作链路上——数据传递有延迟、上下文丢失、某个Agent超时导致整个链路卡住。

这件事促使我重新设计了评测体系，分成三层：

• L1 模型层：测基础能力。意图识别准确率、幻觉率、工具调用成功率。这一层过了只能说明模型本身没大问题。
• L2 Agent层：测多Agent协作。端到端能不能跑通、延迟多长、有没有数据丢失、异常情况下能不能正确兜底。这一层才是系统真正的质量线。
• L3 业务层：测业务价值。改线方案调度员采不采纳、ETA预测偏差率多少、客户投诉有没有减少。这一层决定了系统到底值不值得用。

我们建了一个300多条的测试集，覆盖8类高频异常场景。每次改了Prompt或者调整了检索策略，都要跑一遍回归测试，确保改了A不会把B搞坏。

踩坑教训：模型好≠产品好。评测必须分层，从模型、Agent协作、业务价值逐层验证。

问题六：同一类Bug反复出现，修了又冒

上线之后最头疼的不是出Bug，而是同一类Bug反复出现。修了一个路况信息解析错误的case，过两天类似的又冒出来，只是换了一个路段。

原因是我们的BadCase管理太粗放了。出了问题就修，修完就过，没有做系统化的分类和归因。

后来我建了一个BadCase三级分类机制：

1. 感知层失误：原始数据就有问题，或者数据解析出错
2. 推理层偏差：数据没问题，但模型的分析判断出了偏差
3. 执行层故障：分析也对，但工具调用失败、超时、返回异常

每周自动抽取失败案例，分类归因之后输出周报。推理层的问题走Prompt调优，感知层的问题走数据接入修复，执行层的问题走工具稳定性优化。不同层的问题对应不同的解决路径，不再一锅乱炖。

这套机制跑起来之后，同类问题重复出现的概率明显下降了。评测不再是上线前做一次就结束的事情，而是一个持续运转的闭环。

踩坑教训：BadCase不分类就永远在救火。分清楚是感知的问题、推理的问题还是执行的问题，才能对症下药。

回过头来看

做完这个项目回头看，我做的事情拆开来其实就是在给Agent搭一个工作环境：

• 上下文管理——告诉它该看什么信息，不该看的屏蔽掉
• Agent Loop——告诉它该按什么步骤干活，先规划再执行
• 执行边界——告诉它什么不能碰，软规则定方向硬规则守底线
• 记忆系统——给它可以查的历史经验库，别每次都从零开始
• 评测体系——检查它干得好不好，不好就分类归因持续优化

这跟管理一个新员工入职其实是一回事。你给TA做入职培训，给TA工作SOP，告诉TA什么事不能做，给TA查资料的知识库，然后定期做绩效考核。

只是现在管理的对象从人变成了AI。

OpenAI用了一个挺精准的词——Harness，马具、缰绳。不是限制马的自由，而是让它在正确的方向上跑得更快。

给同行PM的几点建议

第一，别等概念出来了才开始做。如果你现在在做Agent产品，遇到的那些模型不听话成本太高输出不稳定”的问题，你去解决它们的过程就是在做Harness Engineering。不需要等有人给它起了名字你才觉得这事值得做。

第二，从评测开始建。很多PM觉得评测是最后做的事，产品上线前跑一下就行了。我的经验恰好相反：评测体系建得越早，后面的迭代越快。你连好坏都判断不了，怎么知道往哪个方向优化？

第三，提示词管80%，剩下的20%靠代码兜底。特别是涉及到敏感数据和权限的场景，不要指望大模型每次都能自觉遵守你在提示词里写的规则。该写硬规则就写硬规则，该拦截就拦截。

第四，先单Agent跑通，不够了再上多Agent。不要一上来就设计六个Agent的复杂系统。我们项目最早也是从单Agent开始做PoC的，验证核心链路跑得通之后，发现单Agent扛不住才逐步拆分。多Agent带来的协作成本和信息损耗是实实在在的，不到万不得已别上。

最后说点个人看法

做了这个项目之后，加上这段时间密集地看各种关于HE的文章和讨论，我越来越觉得一件事——

AI这个行业，新词永远不缺。从Prompt Engineering到Context Engineering到Harness Engineering，半年一个新概念。很多人的焦虑来自于觉得自己永远在追，追完这个词下一个又来了。

但我现在觉得，学AI不是学新词，是学怎么对新词做完整的解码。

什么叫解码？我自己的方法是分层。

第一层，分概念层和实现层。一个新词出来，先搞清楚它在概念上到底在说什么问题、解决什么痛点，这是概念层。然后再看它在实现上到底对应哪些具体的工程动作、产品设计、技术方案，这是实现层。很多新词在概念层听起来很唬人，拆到实现层你会发现其实你之前就在做了，只是没有这个包装。Harness Engineering就是一个典型概念层是驾驭工程，实现层就是上下文管理、任务编排、边界约束、评测闭环这些你可能早就在做的事。

第二层，分清楚哪些是人的事，哪些是AI的事。一个Agent系统里，哪些决策必须人来做。比如业务规则的制定、边界的划定、评测标准的定义。哪些执行可以交给AI：比如数据检索、方案生成、日志分析。这个边界搞清楚了，你才知道作为PM你的价值在哪。不是去写更好的Prompt，而是去设计更好的规则和环境。

会解码的人，每出一个新词就多一份认知资产。你拿到一个新概念，三十分钟就能把它拆到你已有的知识框架里，知道它跟你做过的事有什么关系、能给你的产品带来什么增量。

不会解码的人，每出一个新词就多一份焦虑。因为你不知道它在说什么，也不知道跟自己有什么关系，只能等别人出教程、等别人做总结，永远慢一步。

Harness Engineering这个词本身可能过一阵子就不那么热了，但解码的能力是通用的。下一个新词出来的时候，你依然用得上。