别把 Agent 做成聊天窗口：一次智能排产业务的 Harness 实践
我最近做了一个小型实验。
原始项目不展开，数据也不讲。为了方便对外表达，我把它换成一个相近场景：一家精密备件工厂，要根据需求、库存和产能，自动生成本周排产计划。
这类场景很典型。业务不复杂，但很容易把 AI 做虚。
一开始，很多人会把它做成一个聊天框。用户问一句“帮我排产”，模型回一段建议。看起来像 Agent，其实只是会说话。
真正难的地方不是让模型说出“建议补货”。真正难的是： 它能不能读取正确数据，走固定工具链，生成结构化表格，通过业务校验，失败时还能交付可用结果。
一、最容易做错的，是把 Agent 做成聊天窗口
很多企业做 AI 应用，第一反应是加一个侧边栏。
左边是原系统，右边是 AI。用户输入问题，AI 输出一段分析。
这一步不能说没用，但它离真正的业务 Agent 还很远。
在排产业务里，计划员真正要的不是一段话，而是一张可执行的排产表。它要有日期、产线、产品、数量、班次、原因和校验结果。它还要能导出，能复核，能追溯。
所以我给这个项目定了一个判断标准： 右侧可以展示智能体过程，但最终结果必须回到业务工作区。
AI 不能只在旁边“解释”。它要把结果写回系统里的工作对象。
二、数据表不是界面，是智能体的工具
这个项目里有三类核心输入：需求、库存、产能。
这些表很重要，但它们不应该全部暴露给普通使用者。使用者不需要看一堆底层表再自己判断。底层表应该变成智能体的工具。
这一步很关键。
如果你把表格直接摊在中间，AI 就变成了页面旁边的说明员。如果你把表格变成工具，AI 才开始承担执行角色。
我的做法是：前台只保留业务入口，底层数据保留为工具源。智能体运行时，先读取数据快照，再调用计算工具，再调用生成工具，最后调用校验工具。
用户看到的是“它正在读什么、算什么、校验什么”。而不是看到一堆原始表，再听 AI 说一堆正确废话。
三、真正的 Harness，是给模型装四层边界
我现在越来越觉得，企业 Agent 的核心不是 prompt，而是 harness。
你可以把它理解为一整套缰绳工程。它不是为了限制 AI，而是为了让 AI 能稳定进入业务现场。
这次实践里，我把 harness 分成四层。
第一层是输入边界。 脏数据、空字段、异常峰值不能直接进入模型。进入前先校验，不合格就阻断。
第二层是过程边界。 模型不能自己决定要不要读表、要不要算缺口、要不要校验。工具链必须固定，关键工具必须调用。
第三层是输出边界。 结果不能是一段散文。它必须是结构化对象，并且字段、取值、数量、日期和业务规则都能被系统校验。
第四层是运行边界。 接口失败、模型不返回、输出不合格，都不能让业务停在错误页。系统要能重试、降级、兜底和记录。
这四层加起来，才是一个企业 Agent 真正能跑起来的基础。
四、过程一定要被看见，否则用户不会相信它在工作
这个项目里有一个很小但很重要的判断：右侧面板不是“建议操作区”，而是“执行过程区”。
如果右侧只是三个按钮：重新生成、触发检测、通知主管，那它看起来还是传统后台。
真正要让别人感知 Agent 在工作，就要把过程展开。
它正在读取哪张表，调用哪个工具，返回多少行数据，经过哪一步校验，是否命中 harness 闸门，什么时候开始，什么时候结束。这些都要可见。
我最后要求所有调用和日志都带时间戳。不是为了好看，而是为了让这个系统可以被复盘。
企业里，可信任不只来自结果。可信任还来自过程。
五、结果必须回到业务工作区
做这类项目时，有一个细节很容易被忽略：结果什么时候渲染？
如果工具刚跑完，模型还没最终返回，你就把表格渲染出来，用户会觉得你在造假。
如果模型最终返回了，你还停留在 loading，用户会觉得你没做完。
所以我把状态机重新梳理了一遍。
进入排产页，先清空旧结果，显示加载状态。离开页面，中止当前运行，丢弃后续返回。只有模型最终输出通过结构化校验后，才把排产计划渲染到中间工作区。
这不是前端小问题。它反映的是一个产品判断： AI 的结果必须和业务页面生命周期一致。
最后，排产结果不是一段话，而是一张表。它支持导出，支持检查，支持给后续系统继续消费。
六、失败路径不能只会报错
我对这个项目最后一次改造，重点不是让模型更聪明，而是让失败路径更像生产系统。
没有配置模型密钥时，系统不能装作一切正常。它要明确提醒用户配置，并给出入口。
模型接口异常时，也不能只给用户一个红色错误。因为计划员今天还是要排产。
所以我让系统先走固定工具链。模型成功，就由模型基于工具结果生成最终结构化输出。模型失败，就用规则引擎基于同一批工具结果生成可用排产计划，同时在日志里标清楚兜底原因。
这不是退而求其次。企业系统里， 可用性本身就是智能的一部分。
七、这件事真正沉淀的，不是一个库存 Demo
这个项目表面上是在做安全库存和智能排产。
但我真正想验证的是另一件事：业务专家怎么把自己的判断路径变成可运行的工程。
过去，专家经验常常停留在会议、PPT、Excel 和口头规则里。AI 进来以后，很多人以为只要把这些经验写进提示词就够了。
不够。
提示词只能表达意图，harness 才能承载执行。
一个可迁移的方法大概是这样：
先选一个闭环业务，不要从泛问答开始。
把专家判断拆成输入、工具、规则、输出和复核。
把底层数据做成工具，不要全部变成前台页面。
把执行过程做成可见日志，让用户知道 AI 在干什么。
把最终结果写回业务工作区，而不是停在聊天框。
把失败路径当成正式流程设计，而不是异常提示。
你会发现，这套方法不只适用于排产。
合同评审、采购比价、项目周报、流程诊断、质量异常分析，都可以照这个思路迁移。
区别只在于工具和规则不同。底层逻辑是一致的：不要让 AI 在空气里发挥，要让它在流程里工作。
未来企业真正需要的，不是更多会聊天的机器人，而是一批被业务 harness 管住、能完成闭环任务的流程智能体。
这也是我这次实践最大的收获。