ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

AI Agent生产环境踩坑实录:Harness如何让大模型不再“发疯”

AI Agent生产环境踩坑实录:Harness如何让大模型不再“发疯” 文章目录1. 先搞清楚Harness 是个啥1.1 什么时候根本不用上1.2 那 Harness 到底管啥2. 我们为啥需要这东西2.1 数 T 的日志不能全喂给模型2.2 模型没有眼睛MCP 就是它的眼镜2.3 团队的记忆不能靠脑补3. 具体怎么干3.1 外部工具skill 和 MCP3.2 管理上下文3.2.1 数据预计算3.2.2 成本控制3.3 规划与决策3.3.1 指令系统3.3.2 任务调度3.4 知识管理3.4.1 记忆管理3.4.2 版本控制3.5 前后指标对比眼见为实4. 还没解决的老大难5. 下一步想干嘛P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看 传送门https://blog.csdn.net/qq_34419312先声明一下这篇不是教科书是我被大模型折腾了三个月之后的血泪汇报。全程大白话能听懂模型会一本正经地胡说八道这句话的人都能看下去。1. 先搞清楚Harness 是个啥OpenAI 今年 2 月把Harness 工程这个词炒火了。Harness 直译过来是马具——缰绳、马鞍、护具全算。马具是干嘛的你见过不戴笼头的马吗它想往哪跑往哪跑最后跑进玉米地你还得扛着胡萝卜去追。大模型同理。你说你要聪明它能聪明地把同一个需求理解出十八个版本你说你自由发挥它能在你的生产库里自由发挥出事故。套上马具它才知道今天该往哪跑、跑到什么程度算完。但先说句公道话不是所有场景都配得上 Harness这玩意儿也有试用门槛。1.1 什么时候根本不用上**第一种你就临时问几个问题、检索点资料、单轮对话用完就走。**普通模型加 System Prompt 加 RAG 完全够用这时候选个聪明的模型比啥都强。非要上 Harness属于下楼倒垃圾还要开个作战会议。**第二种预算充足闭眼上最贵最强的模型。**那 Harness 可能反而拖后腿——这就好比给博尔特套一身铅块人家本来能跑你非让人家先适应装备。**第三种公司从架构上就是 AI 原生的核心价值全建立在模型的推理和决策上。**那你们已经是骑在马背上的骑手了还研究什么马具研究方向应该是怎么让马长翅膀。1.2 那 Harness 到底管啥一句话总结Agent 模型 Harness模型负责聪明Harness 负责稳。就像创业公司的黄金搭档一个负责天马行空画饼一个负责按住他别把公司作没了。模型就是那个画饼的Harness 就是那个按人的。顺便说个真实感受跑一个 Demo 太容易了难的是让模型连续三周稳定输出。我们前段时间参加公司内部的 Agent 大赛将近三个星期前三天就把 Demo 跑起来了剩下的时间全在收拾模型的各种幺蛾子——输出跑偏、任务超时、幻觉上头、权限乱飞。跑 Demo 是开屏孔雀生产环境是拉磨的驴而我们的日常是既当饲养员又当兽医。2. 我们为啥需要这东西起因很简单我们希望大模型帮安全团队干三件脏活累活结果每件都踩坑。2.1 数 T 的日志不能全喂给模型第一件事是检测恶意攻击。网关日志光一天就是好几个 T洗完数据也还有接近 T 级。把这玩意儿直接扔给大模型那不叫分析那叫给模型做压力测试顺便测试财务部的忍耐底线——钱和时间先不说上下文直接原地爆炸。2.2 模型没有眼睛MCP 就是它的眼镜第二件事是评估风险请求。没有 MCP 工具的时候大模型就是个睁眼瞎你说啥它都好的呢我理解您的意思好不容易给它配了工具它又开始有小脾气这个接口我没用过那个工具我不太熟下一步该干嘛你还得逐句哄着来。2.3 团队的记忆不能靠脑补第三件事是管理团队记忆。哪些信息值得写进长期记忆Agent 平台要扩展记忆怎么迁移这些问题不解决模型每次都是闪婚式合作今天教会它这类请求必须人工复核明天它就忘了比金鱼还金鱼——金鱼好歹有七秒它是按轮次清零的。3. 具体怎么干踩完坑方法论就出来了。总的原则是四件事约束动作空间、管好上下文、把调度交给确定性系统、把状态和记忆存下来。下面按我们踩坑的顺序展开。3.1 外部工具skill 和 MCP出于数据安全考虑Agent 一般蹲在沙箱里想让它分析真实数据第一步是让它看得见、够得着。数据量小的时候你可以手动复制粘贴、传附件粗糙但能用但这是重复性任务必须沉淀成稳定可靠的 skill 和 MCP 工具。工具固化下来还有个隐藏福利能提升大模型的缓存命中率也就是省钱。这年头能让财务少皱一次眉就是技术人的最高勋章。但注意技能不是越多越好。社区有开发者反馈给 Agent 装了上万个 skill效果反而变得很差。你想想给一个人发一万把工具他忙活一天大概率只用其中一把来开瓶盖。我们自己的做法是以解决问题为导向idp-mcp 查 Hive 数据、ES 查询技能分析实时流量、威胁情报技能查 IP把能力做成原子化的模块随取随用还能直接复制到别的 Agent 里。3.2 管理上下文前面说了把 T 级数据直接怼给模型任务要么跑不起来要么跑起来比蜗牛还慢。而且长期看平台限制执行时间和思考轮次是必然的——上下文管理不是可选项是保命项。3.2.1 数据预计算核心思路一句话低信息密度的数据别直接给模型让它干高价值的推理和归因。我们的数仓分三层ods 是原始日志T 级dwd 做清洗和特征提取还是 T 级dws 是统计加工好的维度指标和事实指标百 M 级。前两层必须在 Agent 之外先做清洗降维别拿去烦模型。到了 dws 层再按小时分区规模就小到模型可以愉快玩耍了。至于 dwd 的明细数据也不是没用——dws 粒度不够细的时候还得回去结合 dwd 查。简而言之把白菜洗好切好端上桌别让大厨自己去地里刨。3.2.2 成本控制有了工具、数据也降维了你当然希望模型干得越多越好、干得越久越好。但现实是token 不是无限的模型的注意力也是稀缺品——比我的发际线还珍贵得省着用。我们的做法分两类**被动限制外部兜底**工具层面限制 MCP 返回的行数和会话时长模型层面限制思考轮次和思考时长成本层面搞 token plan。**主动介入内部取舍**在技能文档和提示词里规定时间范围、查询范围、查询深度分析任务按优先级分层高优先级全量分析中优先级只看 TopN低优先级抽样检查。举个例子我们的分析任务覆盖 1k API我总不能指望模型把所有接口流量都过一遍。所以先用廉价资源把 dwd 层的流量预算出风险等级高风险用 ES 全量查中低风险做分层抽样。让模型有指向性地干活别像个刚拿到超市购物车的孩子看见什么都想往里装。3.3 规划与决策3.3.1 指令系统最简单的做法就是在系统层面把规矩写清楚比如CLAUDE.md和./prompts。这类提示词一次定义好就别天天改你天天调它反而输出不稳定——好比领导天天改 KPI员工只会越来越迷茫。duties.md管该干嘛duties.md - 工作模式接收问题后先思考是否需要调用工具 → 制定分析计划 → 执行工具调用 → 基于结果给出结构化回答 - 内容呈现要求结构化的、约定好的格式 - 工作原则使用什么工具、方案对比、信息来源 - 其他禁止事项rules.md管不该干嘛## 运行时产物隔离 12. 中间文件、下载产物、截图、图片、SQL、Excel、临时报表、JSON 卡片、HTML 原型和调试日志 必须默认写入 /tmp/runtime/不得写到 Git 工作区根目录 13. 只有明确需要版本化的团队知识才写入 team-knowledge/ 14. 不自作聪明在没有被 的情况下保持沉默尤其最后这条没被 就闭嘴强烈建议所有群聊的人类成员也抄一份。模型不写这条能把工作目录整成灾难现场截图、SQL、临时报表满地开花比大学男生宿舍查寝前的桌面还壮观。它还会在你开会的时候突然好心地冒出来发表意见——你不拦着它能帮你把会开了。3.3.2 任务调度重要原则**Agent 不负责判断什么时候该干活这个交给外部确定性系统。**分析、推理、归因给模型但何时开工得有人拍板。常规做法是 cron 定时任务到点触发。但实际跑起来你会发现上游任务的完成时间根本不确定定时触发经常造成重复执行、漏执行、超时成功率低得感人。而且你让模型自己决定什么时候干活它可能凌晨三点突然兴奋“我觉得现在适合跑一次全量分析”——比我家猫半夜跑酷还准点。我们后来改成了事件触发上游任务完成通过事件消息把模型叫起来干活。模型不用再猜上游什么时候就绪也不用自己管理调度状态省了一大堆工具调用。效果后面有数据先卖个关子。3.4 知识管理重建一个 Agent 很容易难的是让模型的行为保持一致。光复制模型、工具、提示词、知识库是不够的——就像你换了个新同事简历一模一样干起活来完全是两个人。3.4.1 记忆管理跟大模型打交道多了你会发现人更多是在当 reviewer这个请求要人工复核、那个规则要写进长期记忆、这类信息下次优先展示。这些带着个人色彩的业务判断和处理偏好全是私域信息。不沉淀下来人和模型的磨合期会无限拉长——每次合作都像第一次相亲自我介绍重来一遍还未必有下文。所以建议从第一天就重视记忆管理把它当长期资产来存。我们现在的做法是团队里明确写入长期记忆这个动作让模型把经验沉淀下来防止复发。3.4.2 版本控制用 git 管 Agent 的基础文件系统提示词、记忆文件、启动脚本全管起来。好处是迭代可回溯、团队可共享、沙箱重建不丢。以后模型出了幺蛾子还能git log看看是哪次提交把它带沟里的——比看监控回放找责任人有仪式感多了。3.5 前后指标对比眼见为实口说无凭贴一组我们同模型、同时段任务的前后对比。模型是 qwen3.7-plus主要调整了调度方式、加了重试熔断、改了查询方式、把重复逻辑固化成脚本指标调整前调整后变化Agent Loop 轮数52 轮21 轮↓ 59.6%执行耗时2630.5s约 43.8 分钟479.4s约 8 分钟↓ 81.8%基础输入 Token22321278↓ 42.7%生成输出 Token2424615421↓ 36.4%Token 总消耗2,920,4044,176,966↑ 43%增量主要是缓存工具调用次数也大幅缩水Bash 从 25 次降到 11 次Hive SQL 从 13 次降到 2 次Read 从 8 次直接清零。之前 Hive SQL 一次 2~14 分钟13 次独立查询扫表占了总时长的七成以上——现在改成一次导出数据快照后续全部本地聚合重复的 Hive 读写和错误重试全没了。说到重试必须单独表扬一下熔断规则每个操作最多重试 2 次不要反复尝试不同参数格式。之前模型失败了自己重试失败了再重试比客服电话转接还执着你挂都挂不掉Token 就这么被它烧光了。现在规则写死效果立竿见影。可能有同学要问Token 总量不是涨了吗别急增量几乎全来自缓存读取和缓存创建而缓存命中的价格只有普通输入的十分之一。用少量成本换执行效率翻倍这笔账怎么算都划算——就像你多花了五块钱升级加速包但省下了一下午的等待时间。4. 还没解决的老大难坦白讲Harness 不是万能药我们还有几道题没解完**幻觉这东西压不灭。**系统提示词、记忆层面都做了强化幻觉还是偶发。而且不同模型对指令的遵循程度不一样一旦切换模型输出就可能不一致——换模型跟换对象似的前任养成的习惯现任全不认。**任务要稳定跑完还得继续较劲。**Agent SDK 底座一直在迭代模型能力参差不齐上下文长度、提示词长度都不一样。保证持续输出的稳定性和行为一致性是场持久战。**团队 Agent 还是个人数字分身**我们倾向团队优先成员随时能用、能共同管理经验复用、口径统一、共享记忆飞书生态还方便接入。个人分身当然也有价值但一个人养一个 AI 管家和一群人养一个 AI 同事投入产出比完全不是一回事。**一定需要 SOTA 模型吗**真不一定。不是所有任务都需要最前沿的模型我们这套框架用的就是国产大模型工程上优化好之后实际用下来完全能满足需求。SOTA 是锦上添花Harness 才是雪中送炭。5. 下一步想干嘛现在模型是能稳定跑了但新的问题冒出来了Agent 如果只顾埋头输出、收不到人类的反馈它会不断自我强化最后钻进死胡同出不来——像极了把导航开到断头路还坚信前方可达的司机。所以下一步的聚焦点是怎么高效收集人类真实的反馈和纠正让 Agent 自己总结经验、避免再次踩坑。说白了就是给它装一个人类吐槽接收器把我们的嫌弃变成它的成长。最后说句掏心窝子的模型是马Harness 是马具但马具不会自己调整松紧这件事终归得人来干。所以各位别担心被取代——你还能当个马倌而且是个越来越省心的马倌。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/qq_34419312
返回列表