Agent 会干活以后，谁来管它停下？ 模型能调用工具只是开头。企业要让 Agent 进入真实流程，需要用 Harness 管边界、Loop 管过程、Eval 管判断、LLMOps 管改进。 #AI #AI Agent #企业AI #大模型 #智能体

一个Agent查完客户投诉，发现八个客户还没赔，他下一步问你：“要不要我现在自动退款？”这个问题一出来，Demo就不只是Demo了，因为他已经碰到真实业务系统，他不只是回答你，他可能要改记录，建任务，甚至执行确认。所以企业做Agent最关键的问题，不是模型够不够聪明，而是他什么时候该查资料，什么时候该动手，什么时候必须停下来等人确认。这期我们不背概念，就沿着这个八个未赔付客户的例子，把Agent Harness、Loop、LLM Ops和Eval串起来。你会发现这几个词其实都在管同一件事：让大模型从聊天脑子变成工作系统里可控、可复盘、可修改的一个部件。Anthropic和OpenAI的资料里，也都是把Agent放在工具、反馈、指令、护栏、交接这些部件里讲，换到企业场景，它就不是一个会聊天的模型，而是一套会碰系统的工作流程。 先看Agent和普通聊天机器人差在哪儿。普通聊天机器人通常就是把当前问题、对话历史、系统提示词塞给模型，模型给你一句回答，问完就结束。企业里的Agent不一样，他要知道我是谁，公司过去发生过什么，这件事有什么规则，现在任务做到哪一步了，他还要知道哪些系统能查，哪些系统能写，哪些动作需要权限，这些东西不可能全塞进一句提示词里。上下文窗口再大，也不是垃圾桶，你不能每次都把客户、历史、知识库、工单、政策、口径、权限、规则一股脑扔进去，这就是Harness要解决的问题。 Agent Harness可以理解成一个工作台，他把模型、记忆、工具、权限和规则放到一起，让模型沿着边界干活。这里要注意，Harness不是套一个框架就完事儿，框架只是工程起点，真正要涉及的是控制关系：谁能进上下文，谁能被调用，谁有权限改业务系统，谁负责记录结果。各类里最容易被低估的是记忆，企业Agent至少会碰到四类记忆：工作记忆是这次任务正在发生什么，程序记忆是规则、技能、流程和决策要求，语义记忆是客户资料、产品知识、政策口径，情景记忆是过去真实发生过的会话、投诉、退款和工单流转。四类记忆的取法也不一样：产品政策这种文本适合用RAG从文档里找相关片段，但你问“这个客户最近十次投诉是什么？”更像查数据库，如果你问“过去二十次质量投诉里，哪些是Agent没处理好的？”可能就要结构化查询和语义检索一起用。所以，Harness的核心动作不是把资料越塞越多，而是判断这次任务到底需要哪几块资料，哪些可以不取，哪些要先汇总成事实，哪些必须保留原始记录。 那么到这里，Agent终于有了工作台，但他没有开始连续干活儿，接下来就是Loop。Loop的意思很简单，Agent不一定一次回答完，他可以看一步，做一步，再判断下一步。回到投诉处理的场景：他先查CRM，发现三十起投诉，再查赔付记录，发现十二起已经赔了，八起还没处理。然后他可能打开日历，准备安排销售跟进，再连接支付系统，准备发起退款，这就是Loop的价值。他让Agent能在工具之间来回跑，直到任务达到某个结束条件。但麻烦也在这里，如果Loop没设计好，Agent会做两种蠢事：一种是太早停，他查到名单就说已找到相关客户，但业务要的是后续处理方案；另外一种是停不下来，他一路查，一路改，一路调用工具，最后把本来该人工确认的退款也执行了。所以Loop工程不是让模型自由发挥，他要写清楚每一轮怎么判断下一步调哪个工具，调用前要不要看权限，结果够不够支持下一步，什么时候要问人，最多跑几轮，什么叫任务完成。他在企业里的停止条件，经常比开始条件难：开始很容易，用户说“帮我处理这些客户投诉”，Agent就启动了，那停在哪里？预列出八个未赔付客户是一个终点，自动创建跟进任务是另一个终点，直接退款又是完全不同的终点。这三个终点对业务影响不一样，靠谱的Agent要把他们分开，到了退款这种动作，他应该停下来问：“我可以继续生成跟进任务，是否需要我执行退款？退款需要你确认。”这不是把Agent调笨，他更像一个靠谱同事，能往前推进，也知道哪些动作不能擅自做。 但就算有了Harness和Loop，事情还没完。Agent对接业务系统以后，靠“我试了一下，感觉还行”会很危险，因为一次运行里会发生一串小动作：用户问了什么，模型读了哪些记忆，检索命中了哪些文档，调用了几次工具，每个工具耗时多久，哪一步失败了，用了多少Token，最后有没有完成任务。这些东西合起来就是Trace运行记录，LangSmith这类Trace工具看的也是这个，把一次LLM应用运行拆成可观察的步骤，你能看到延迟、错误、调用链、输入和输出。我更愿意把Trace看成工作录像：没有录像的时候，团队只能说这个Agent有时候不太稳定，有了录像，你才能把不稳定拆开：模型能回答，但检索拿错了文档；工具能调用，但参数格式传错了；循环条件没写清楚，所以任务提前结束；上下文塞太多，所以每次响应都被拖慢。这就是LLM Ops该干的活儿，他听起来像运维，做起来更像产品复盘：记录运行，评估结果，定位问题，再调整提示词、模型、工具、参数、检索策略或权限规则。更关键的是，调整完不能拍脑袋上线，要把原来的失败任务重新跑一遍，看同一个问题有没有真的被修好。很多Agent的项目后期卡住，不是因为模型不够强，而是没有这套固定动作：失败样本收不回来，配置改了没复跑，下次还是踩同一个坑。 但是再往下就是Eval，很多人听到Eval会以为是给模型做考试，但在Agent系统里，这个理解太窄了。你要检查一次真实交付：客户投诉有没有找全，退款状态有没有判断对，会议有没有真的创建，需要人工确认的动作有没有停住，回答里有没有把已执行和建议执行混在一起，成本和延迟还能不能接受。OpenAI的Evals小模型，输出质量数据集评分器和迭代改进放到Agent里，评估对象要往前推一步，不只是看一句回答写的好不好，而是看整条任务链有没有可靠完成。一个客服Agent的Eval可以拆成几类：结果指标，投诉有没有识别出来，分类准不准，退款状态有没有查对；过程指标，该调用CRM时有没有调用，该停下确认时有没有停下；体验指标，响应多久，问了几次澄清，用户有没有被迫重复信息；成本指标，每次任务消耗多少Token，调用多少外部接口。可能评分方式也不止一种：有些可以写成确定性规则，比如退款动作必须有用户确认记录；有些需要人工审核，比如这次回复有没有误导客户；有些可以用LLM Judge先做初筛，比如判断回答有没有覆盖投诉原因、处理进度和下一步建议。但评分不是终点，更有用的是他能告诉团队下一轮该改哪里：是