← 返回洞察
2026 年 9 月 · 8 分钟阅读
Agent 失败不在模型里，在 harness 里：monday.com 的生产护栏
关键定义
Harness（护栏层） 围绕 agent 的工程边界：控制喂给模型的输入、限定运行的边界、验证输出、闭环反馈。monday.com 的比喻是保龄球护栏——LLM 是球道，harness 是护栏；他们复盘 feedAgent 后得出结论：失败模式几乎不出在模型里，而出在围绕模型的假设里。
Schema 校验输出（Schema-validated output） 强制模型通过带 schema 校验的工具调用来输出，而不是信任它自己生成 JSON——monday.com 称之为『契约与希望的差别』。schema 失败时把校验错误作为上下文喂回去重试。
幻觉过滤（Hallucination filtering） 输出中任何解析不到真实数据 ID 的引用一律丢弃并记录。monday.com 用别名系统把原始 ID 换成短别名并建立检测面，模型编造而非真实检索的引用会被抓到。
把 agent 想象成保龄球：LLM 是球道，harness 是球道两侧的护栏。没有护栏，一个坏球就滚进沟里——幻觉引用、畸形输出、烧预算的死循环。monday.com 上周公开了 feedAgent——一个为每个工作区成员生成个性化动态的深度 agent——的完整生产案例，结论直接：他们遇到的所有失败模式，几乎没有一个是出在模型里，而是出在围绕模型的假设里：喂进去什么、边界在哪、输出怎么验证、下次怎么记得。护栏决定生产可用性，不是模型排行榜。
三处会坏的地方：输入、流程边界、反馈回路
monday.com 的工程团队把 agent 生产的失败面归纳为三类（来源：monday.com engineering blog — https://engineering.monday.com/building-a-robust-harness-for-agent-in-production-feed-agent-case-study/ ）：① 数据与上下文——模型拿到什么输入、对它工作的世界知道多少；② agent 流程——流程本身与其边界；③ 反馈回路——它如何改进。他们用「walk the flow」方法建设 harness：走过 agent 执行的每一阶段，在每个转弯处问「这里会出什么问题，harness 对这个问题做什么」。
这个方法的出发点很朴素：agent 不是管道，是复杂循环，每个 feed 都不一样。把「哪里会坏」当成设计问题，而不是把「模型够不够强」当成赌注——这是整篇案例的方法论核心。
输入侧护栏：模型永远看不到原始洪流
feedAgent 的输入是巨大的跨资产数据：用户活动、agent 活动、已有 feed 项。模型只会拿到 harness 选择暴露的部分。三个关键设计：第一，activity preprocessor 确定性地折叠事件、保留重要聚合变化、丢弃噪音——同时在这一步移除所有 PII，模型在见到任何数据前，敏感信息已经被剥掉。第二，alias 系统把原始 ID 换成短别名，创造了幻觉检测面：模型在输出里编造的引用会被抓到并丢弃。第三，prompt caching——静态系统提示词在网关层缓存，后续调用只付零头，否则每次运行都为同一段静态文本付全价输入 token。
运行边界：schema 是契约，上限是保险
agent 启动时，harness 定义的不仅是能力，还有约束。最容易被低估的是输出 schema：没有 schema，模型返回自由文本；下游代码要消费输出，就必须强制模型通过 schema 校验的工具调用输出——这是「契约与希望的差别」。schema 失败怎么办？把校验错误作为上下文喂回去重试，模型就有能力修正自己。
边界上还有两组独立上限：model call limit 封顶模型被调用的次数，recursion limit 封顶循环迭代的次数——两个独立的顶盖，任何一个达到都安全停止，而不是未处理崩溃。工具侧同样有模式：必要工具不交给 agent 选择而是拆到流程后段保证执行；工具错误信息要写成可行动指令——只回一个「failed」是信号，让模型猜；回「当前数据不可用，请用已有数据继续」是指令，模型知道下一步做什么；持有连接的工具必须有确定的关闭路径。
输出验证与反馈闭环：幻觉过滤、去重、记忆
输出侧，任何解析不到真实活动 ID 的引用全部丢弃并记录——模型可能引用了从未出现在原数据里的别名，那些都是幻觉；同一活动不能出现在两条 feed 项，用全输出 pass 的 ID 集合强制去重。反馈侧，每次 run 都会触发 summary event：时长、活动数、feed 项数、模型名、工具调用轨迹、prompt 长度分解；LangSmith tracing 记录每一步中间过程。feed memory 把行为信号写回下一轮输入：用户显式规则是高优先级，推断观察（dismiss、CTA 点击、停留时长聚合出的模式）是低优先级软上下文，永不覆盖显式规则。
eval 是闭环的保险丝：离线 eval 用持续扩充的数据集 + LLM-as-judge 在 CI 上跑，防止回归上线；在线 eval 在实时生产数据上跑，发现潜在问题并建议修复。agent 不确定，所以只测确定性部分不够——这正是双层 eval 存在的原因。
我们的判断
第一，「失败不在模型里」是反直觉但正确的工程结论：生产 agent 的质量上限由 harness 的设计决定，不是模型卡。这解释了为什么同一模型在不同公司表现天差地别——差的是围绕模型的假设。第二，护栏是分层设计的：输入侧（大小与 PII）、运行侧（schema、双上限、工具）、输出侧（幻觉过滤、去重）、记忆侧（反馈闭环）——少一层，生产可用性就少一档，且缺失的层会在最不该出错的时刻暴露。第三，评估 agent 平台时别只问模型多强，要问它管住了哪几层护栏。这与 OOMeta 自己的生产实践一致：我们的技能系统、评估门禁、任务总线就是「把失败挡在护栏内」的设计——模型只是被路由的那颗球。第四，对买方的直接含义：把「harness 成熟度」加进 agent 平台评估清单，与模型能力并列，甚至前置。
买家行动清单
第一，为每个生产 agent 画一张「护栏清单」：输入/PII、schema 与上限、输出验证、反馈记忆、eval——缺项就是已知风险，写进上线评审。第二，输出必须走 schema 校验的工具调用，禁止模型自由生成 JSON。第三，双上限独立封顶：模型调用次数 + 循环迭代次数。第四，幻觉过滤不是可选项：引用/ID 必须能解析回真实数据，解析不了就丢弃并记录。第五，eval 双层：CI 离线 + 生产在线，每次失败都回灌数据集——护栏不是静态配置，是持续工程。
留给你的决策问题：你的 agent 项目里，护栏管住了几层？如果今天一次坏球进场，谁会第一个发现？
OOMeta AI
OOMeta 在生产中把「harness 成熟度」当作 agent 系统的第一质量维度：技能边界、评估门禁、任务总线、失败回灌，先于模型选型落地。我们帮企业把 agent 从「能跑」升级为「有护栏地跑」：护栏清单审计、schema 与上限设计、双层 eval 的完整工程。
预约诊断会参考来源：①monday.com engineering blog（09-09）：Building a Robust Harness for Agent in Production — feedAgent case study — https://engineering.monday.com/building-a-robust-harness-for-agent-in-production-feed-agent-case-study/
常见问题
什么是 agent harness？+
围绕 agent 的工程边界层：控制输入、限定运行边界、验证输出、闭环反馈。monday.com 的比喻是保龄球护栏——LLM 是球道，harness 是护栏，保证球不滚进沟里。它决定生产可用性，不是模型排行榜。
为什么说失败不在模型里？+
monday.com 复盘 feedAgent 生产案例：反复出现的失败模式是围绕模型的假设——喂进去什么、边界在哪、输出怎么验证、下次怎么记住——都不是模型的工作。结论是生产质量由 harness 决定。
生产 agent 的输出为什么必须走 schema？+
让模型自由生成 JSON 等于靠运气。monday.com 用输出 schema 强制模型通过 schema 校验的工具调用输出，失败就带上校验错误重试——这是『契约与希望的差别』。
怎么防止 agent 无限循环烧钱？+
双上限：模型调用次数上限（model call limit）与循环迭代上限（recursion limit）独立封顶，任何一个达到都安全停止。工具错误信息也要写成可行动指令，而不是裸错误让模型猜。
幻觉过滤怎么做？+
输出中解析不到真实数据 ID 的引用全部丢弃并记录。monday.com 用别名系统：原始 ID 换成短别名，模型编造而非真实检索的引用会被检测面抓到，输出侧再过滤一遍。
eval 应该怎么分层？+
双层：离线 eval 在 CI 上跑（LLM-as-judge + 不断用生产用例扩充的数据集），防止回归上线；在线 eval 在实时生产数据上跑，发现问题并建议修复。每次失败都回灌数据集。
相关文章
评估优先不是质量洁癖：Zepto 把 eval 做成了成本杠杆
Zepto 客服每天跑超 10 万张工单，AI 处理 80%+ 工单、成本降 65%、回本不到 1 个月（Databricks 案例口径）。我们的判断：eval 不是上线前检查，是成本与质量基础设施——双循环+质量门禁+金标数据集，dev-prod 精度差本身就是数据集质量信号。
Docusign 把合同层开放给所有 Agent：9 月 30 日起 MCP 客户端可直接调用
9月4日 Docusign 宣布其 MCP Server 将于 9 月 30 日向所有 AI Agent 开放：Claude、ChatGPT、Gemini、Copilot、Slack 等任何 MCP 客户端都能原生调用合同分析、发送与签署，由 AI 引擎 Iris 注入历史谈判与政策上下文。签署动作需要企业级治理。
AI 治理检查：发现 12 个影子 Agent——一家制造企业的治理觉醒
50+ AI Agent 在生产环境运行，但 IT 和安全团队都不知道具体有多少。OOMeta 的 Agent 发现扫描找到了 12 个未经授权的影子 Agent。
跨境合规文档审查：从 3 周缩短到 3 天——Agent 原生工作流实战
200+ 份供应商合同的 EU AI Act 合规审查，传统方式 3 周，Agent 原生工作流 3 天完成、准确率 94%。本文拆解三个维度的工作量爆炸与 Sprint 方案，解释为什么 Agent 原生工作流快 7 倍。