AI Agent可控性关键：Harness Engineering与SDD如何协同落地-北京尧图网络

搞AI Agent落地的这帮人最近都在聊一个词Harness Engineering。我第一次听到这个概念是在一次内部架构评审会上大家讨论的不是模型选型也不是Prompt技巧而是怎么给智能体套上一层“缰绳”让它在生产环境里不乱跑、不越界、输出可控。会议室里的白板画满了输入过滤器、工具白名单、输出校验器那一刻我突然意识到AI工程化终于从“追着模型跑”进入到了“给模型修跑道”的阶段。但另一个问题紧接着就冒出来了既然我们有一套系统的、工程化的手段去约束AI了那以前那套“先写规范、再写实现”的SDDSpecification-Driven Development规范驱动开发方法论还有存在意义吗尤其是从MATLAB/Simulink时代传下来的那套规范驱动开发套路是不是已经被Harness Engineering替代了我的结论先放在这里SDD不仅没有被淘汰恰恰是Harness Engineering能不能真正落地的前提。这篇文章就围绕这个结论展开讲讲这两个东西到底各自解决什么问题怎么配合才有实战价值顺便把我自己踩过的坑和沉淀下来的方法一起分享出来。适合正在做AI Agent落地、研发效能治理、或者传统嵌入式规范开发想要转型的工程团队参考。1. 先搞清楚两个概念在解决什么问题1.1 SDD把“需求”变成可执行的工程契约SDD不是新东西。最早在MATLAB/Simulink生态和汽车电子、航空航天领域被大量使用核心思想就一句话在写代码之前先把“系统应该做什么、做到什么标准”用规范的形式固定下来然后整个开发过程围绕规范展开。一个标准的SDD流程大致包含这么几个环节需求分析把业务需求翻译成可验证的系统需求项每条需求都有唯一编号。规范定义用状态机、时序图、决策表、接口契约等形式把需求转成无歧义的技术规范。模型/设计基于规范搭建模型或设计文档形成设计基线。代码生成/实现依据规范进行编码要求每一行代码都能追溯到某条规范。验证与确认通过测试用例验证实现是否符合规范每个测试用例同样关联到具体需求。这套体系最大的价值不是“多了一个文档流程”而是建立了一个工程契约需求方、开发方、测试方都对着同一份无歧义的规范说话。规范明确“做正确的事”测试验证“正确地做事”贯穿全程的可追溯性让变更影响一目了然。但SDD的痛点也很明显它假设系统是确定的。状态机的下一个状态是可枚举的时序图的输入输出是可预测的决策表的条件组合是有限的。这套前提在传统嵌入式系统里成立在LLM驱动的智能体里就尴尬了——同一个Prompt喂一百次输出可能一百个样。规范写得再细兑现不了方法论就变成了纯文档负担。1.2 Harness Engineering给AI智能体装上“可控装置”Harness这个词本身就很有意思。最早出现在测试领域指的是test harness测试框架一套能挂载被测对象、执行用例、收集结果的装置。Harness Engineering在AI语境里的内涵要更宽指的是围绕AI智能体构建一整套可控性工程装置让它能在生产环境里稳定、安全、可预期地工作。这套装置通常覆盖几个层面输入层控制包括Prompt模板白名单、输入内容检测、意图路由闸门防止恶意输入和越权请求进入模型。工具层控制AI Agent要调用外部工具时做工具白名单校验、参数Schema校验、权限拦截。推理层控制对模型的思维链、中间决策过程做结构化约束避免模型在不可控路径上越走越远。输出层控制对生成结果做合规校验、格式校验、内容过滤不符合标准的输出直接拦截或降级。观测与评测层全链路日志、评测集自动回归、异常行为告警形成持续改进闭环。Harness Engineering的出现本质上是把AI系统当作一个“不可完全信任的执行体”来治理。非常像互联网架构里的API网关你没法保证每个上游服务都是可靠的所以用网关统一做鉴权、限流、熔断、协议转换。Harness就是AI时代的网关。1.3 两者的核心差异一个定义正确一个约束行为搞清楚SDD和Harness Engineering各自的定位之后就不难发现它们的差异不是“新旧替代”而是分工不同。SDD回答的是“什么是对的”系统的功能边界在哪里、最终交付物应该满足什么标准、每一项需求怎么验证。它产出的是契约。Harness Engineering回答的是“如何保证系统不跑偏”在运行过程中如何约束模型行为、拦截异常输出、记录违规动作。它产出的是装置。打个比方SDD像是建筑设计蓝图加监理规范规定了房子该盖成什么样、验收标准是什么Harness Engineering像是施工现场的脚手架、安全网和巡检制度保证施工过程不塌方、工人不掉下去。没有蓝图的脚手架是悬空的没有脚手架的蓝图只能挂在墙上。2. 为什么Harness Engineering离不开SDD式的规范体系2.1 Harness的评测标准来源只能是规范很多人一开始做Harness时容易犯一个错误先堆一堆评测集再搭一套Prompt约束觉得“看起来差不多”就上了。结果模型的行为稍微一偏评测数据就不收敛你不知道是模型的问题、评测集的问题还是约束条件本身就不对。我见过一个做客服Agent的团队他们花了两个月搭测试框架评测集攒了上千条结果线上还是出现了拿用户地址去调用天气接口的荒谬行为。后来复盘发现他们的测试用例里根本没有定义“什么场景允许调用天气接口”这条规范。评测集在测“模型答得像不像话”但规范在定义“这个Agent到底应不应该管天气”。这就是Harness Engineering对SDD的依赖Harness里每一项评测指标、每个约束规则、每个工具调用的开关策略都要有明确的标准来源。而这个来源只能是规范。规范的颗粒度决定了Harness的颗粒度。什么叫做规范的颗粒度不是“系统要友好地服务用户”这种心灵鸡汤式的描述而是类似“当用户意图为查询天气且定位信息在城市级别时系统才能调用weather/current接口未满足条件时必须明确告知用户当前不可用”这种可直接验证的条款。2.2 SDD在AI时代的问题恰是Harness的发力空间传统SDD放到AI系统里不好用核心原因是AI系统存在概率性和长尾性。你写了一个状态机定义了五个意图和对应的流转分支但用户输入的真实分布里总有6%的边角case落在状态机的盲区。规范覆盖不到开发就会陷入两难要么把规范不断加密最终变成一本没人看得完的天书要么妥协用“兜底回复”糊弄过去而兜底逻辑本身就是不可控的。Harness Engineering恰恰补上了这块拼图。标准SDD的“完全规范”假设在AI系统里不成立于是我们用harness来管理那些规范没覆盖到的模糊地带当模型输出落在规范定义之外时harness负责拦截、降级、告警而不是期待模型自己“良心发现”。但这里要注意一个反常识的点harness并不能代替规范去定义“什么样算违规”。如果系统没有事先约定“禁止调用非白名单工具”这个规则harness就无从判断当前这个工具调用是否合法。所以更准确地说harness是规范的执行器它的存在让规范在不确定性系统里变得可执行、可监督。2.3 从“规范-实现-测试”到“规范-约束-执行-评测”把两者结合起来我习惯用一个调整后的工程闭环来描述这套闭环不是说把SDD替换成了Harness Engineering而是把传统SDD的“实现”环节从“一份代码”扩展成了“一个不可完全预测的智能体一套约束装置”并且把“测试”扩展成了“全链路评测与动态观测”。在这个模型里SDD承担了顶层的系统设计职责它的输出是AI系统的“行为契约”Harness Engineering是这条契约的落地保障负责在运行时把契约翻译成具象的约束和判定逻辑。两者缺一不可。3. 实操把SDD和Harness结合做一个可控的AI客服智能体3.1 第一步用SDD方法定义行为规范理论说再多不如动手做一遍。下面用一个我从零搭建的“售后客服AI助手”来走一遍整个流程。这个Agent的职责包括解答退换货政策、查询订单状态、登记售后工单、处理用户的情绪化表达。这几个功能单看不难难点在于每个功能之间还有交互和优先级并且必须对接企业内部工单系统和订单系统。我做的第一件事不是写Prompt也不是选模型而是拉上业务、产品、法务一起开规范评审会。输出一份《客服Agent行为规范V1.0》里面包含几个关键部分意图范围定义明确系统必须支持的意图列表查询订单、申请退货、催发货、情绪安抚等以及明确禁止受理的高风险意图赔偿协商、法律纠纷、隐私数据修改。状态流转规则用状态机描述会话的生命周期从“未识别意图”到“待确认信息”到“工具调用中”到“会话结束”每个状态的合法迁移路径必须标明。工具调用契约每个工具订单查询、工单创建都定义前置条件、输入参数Schema、返回数据格式、超时与失败处理。兜底规范当用户输入无法映射到任何合法意图时系统必须使用标准话术引导严禁模型自由发挥编造功能。这份规范不是形而上的文档里面的每一条最终都会被映射到Harness的某个具体组件上。比如“严禁模型自由发挥编造功能”这条直接决定了输出层要挂一个“功能宣称校验器”扫描模型输出文本中是否包含未授权功能关键词。3.2 第二步搭建Harness约束与评测装置规范定完进入Harness工程搭建阶段。这块我拆成三层来做每一层都对应规范里的特定条款。输入层我做了“六个闸门”前三个负责鉴权用户身份校验、渠道校验、会话状态校验后三个负责范围控制敏感内容过滤、意图归一化路由、Prompt白名单匹配。很多人觉得输入层做Intent识别就够了其实不够。我去掉一个关键逻辑即使模型识别出了意图如果该意图未在授权意图列表里harness也必须强制拦截。这一层本质上是把规范的“意图范围定义”翻译成了可执行的代码闸门。工具层这里最容易出安全事故。LLM本身不执行代码但Agent有工具调用能力后LLM的输出就成了指令级风险源。我的做法是套两层校验第一层是工具白名单、第二层是参数Schema校验。白名单很好理解大模型只能在注册过的工具列表里选择选一个没注册的直接拒绝。参数Schema校验比白名单更关键举个例子模型有权调用订单查询工具但如果它试图传入一个不属于当前登录用户的订单号Saas层查询系统必须拒绝。这属于工具层的越权防护单靠Prompt约束根本拦不住。输出层我挂了一个四段式校验器格式校验输出是否符合预设的响应Schema。合规校验是否包含明文禁止的表述承诺赔偿、泄露其他用户信息等。行为校验模型是否宣称了系统实际不具备的功能。质量校验通过规则分类模型做粗粒度的情感与相关性评估。评测层的搭建相对独立但它和SDD的关系最紧密。我的原则是每条评测用例都映射到规范里的具体条款并且定期做覆盖率分析。比如规范里定义了“当用户情绪强烈时必须转入人工”评测集里就必须有一批测试用例专门验证这个场景并且标注触发“人工接管”的标志位。3.3 第三步规范和Harness的联动迭代规范和Harness不是一次性建完就互不相干的它们之间必须形成迭代闭环。我的团队每周跑一次全量回归评测评测结果有三类去向评测通过说明规范和Harness基本匹配进入常规监控。Harness拦截失败问题出在约束装置本身需要修Harness逻辑。Harness成功拦截但业务认为不该拦说明规范定义和业务预期出现偏差需要修订规范。最后一种情况特别容易被人忽视。很多团队遇到模型输出被harness拦截第一反应是认为harness太死板调低阈值了事。实际上如果Harrness按规范拦截了某句话而业务方不开心说明规范本身过时了。比如客服Agent早期规范明确禁止系统主动提供“仅退款”字眼后来公司策略调整了允许在特定条件下主动推送仅退款方案。如果我们不更新规范harness就会一直拦截新业务策略的落地。这时候不是去绕过harness而是要回到规范评审流程把新策略正式写进规范再同步修改harness的拦截规则。整个链路变成了业务变更 → 规范修订 → harness更新 → 评测回归。3.4 一个完整定位案例用户问“现在能退款吗”说一个具体的定位案例这是我个人印象最深的一次排查。客服Agent上线第二周线上反馈说用户问“现在能退款吗”系统回复了一堆退货政策还附赠了一句“京东自营商品可享7天无理由退货”但这家店铺根本没有入驻京东渠道。用户瞬间觉得客服是个骗子。排查路径是这样的第一步先看harness有没有拦截。日志显示输出层行为校验器没有拦截说明“京东自营”宣称不是预先定义的违规词校验器直接放行。第二步回看规范。规范里写了“系统不得声明平台政策之外的售后渠道”但这句话没有被翻译成Harness层可执行的关键词规则。规范有约束没跟上。第三步定位根因。问题不在模型而在于规范拆解到Harness组件时遗漏了“平台外渠道关键词”这一类目。于是我们修复了行为校验器增加了一组“平台外关键词”过滤规则并把“不得声明未经授权的渠道”升级为规范评审的重点检查项。这个case很小但它完整展示了SDD和Harness是如何在实战中配合的规范定义了“什么是错误的”Harness负责“把它拦下来”。两者脱节问题就会漏到线上。4. 常见问题、误区与落地建议4.1 误区一Harness Engineering只需要工程手段不需要规范这个误区在工程师圈子里特别普遍。因为Harness本身是技术装置看起来只要搭好过滤器、写好校验器、接上告警系统就安全了。但跑一段时间就会发现每个拦截规则的阈值从哪来评测集的判断标准从哪来模型行为出现漂移时以什么为基准去评价这几个问题绕来绕去最后都会回到一个原点你缺一份清晰、可验证的系统规范。没有规范的harness就像是拆掉了靶子的射击训练练得再勤也不知道有没有打中目标。所以我给团队定的规矩是任何一条harness规则必须能反向关联到一份可追溯的规范条款写不出条款的规则不配上。这条规矩看似增加了表格工作实际省掉的返工远超预期。4.2 误区二SDD会扼杀AI的灵活性还有一种声音认为SDD是一套确定性系统的方法论硬套到AI这种天然需要灵活的智能系统上会扼杀掉模型的生成能力。这个担忧有一定道理但过于一刀切。如果你在做的是创意写作AI那确实不适合用SDD约束死但如果你做的是有明确业务边界的生产系统——客服、交易、医疗辅助、工业控制——系统的不确定性恰恰是风险源规范性不是束缚而是底线。我用一个简单的梯度模型来决策一个AI系统到底需要多少SDD、多少Harness离用户越近、越涉及资金交易和法律风险的系统越需要高规范密度和高约束强度而离用户远、只做内部辅助生成的场景可以适当降低规范颗粒度用轻量评测替代完整SDD流程。这套梯度模型在团队内部说服力很强避免了一刀切导致的流程臃肿。4.3 误区三规范一开始就要完美SDD落地最大的阻力不是写规范难而是团队容易陷入“完美规范”的陷阱。尤其是当规范从传统嵌入式经验迁移过来时团队会觉得必须把所有可能的用户输入和模型输出都定义清楚才能开始做harness。这套思维在确定性系统里可行但在AI系统里状态空间是近乎无限的。更务实的做法是先定义最小可行规范集覆盖最高频和最高风险的场景然后让harness在运行中暴露规范缺口用迭代的方式持续补齐。我和团队说的一个原则是规范不是为了覆盖整个世界而是为了定义我们承诺的世界。AI能做什么我们控制不了但AI在这个系统里被允许做什么必须由我们说了算。4.4 落地建议从一个小域开始小步快跑如果看完这篇文章你正打算在团队里引入SDDHarness的组合打法我建议不要贪大求全。选一个边界清晰、价值凸显的业务场景作为试点。以我自己的经验一个售后客服Agent、一个工单流转Agent、或者一个数据查询Agent都是非常合适的试点对象。这类Agent天然具备几个特性意图边界明确、工具调用有限、风险场景可枚举、评测效果便于量化。把它们作为试验田先把规范、harness、评测闭环跑通再横向复制到更大范围的业务域。团队层面我建议至少保证三种角色的深度参与懂业务的人负责定义规范边界懂系统架构的人负责harness装置落地懂数据的人负责评测集和指标体系搭建。这三类人只要有人缺席闭环就会在某一个环节出现断层。5. 写在最后的实操体会回到题目本身的问题Harness Engineering来了SDD还有意义吗我对这个问题的回答是SDD的意义不仅没被削弱反而被放大了。Harness Engineering给了我们一套在不确定系统中建立确定性的工程手段但它需要一套清晰的标准来定义什么是“正确的行为”、什么是“可接受的边界”这个标准恰恰是SDD的看家本领。我自己在实际操作中的体会是两套思维融合之后有一个特别大的心态转变以前做SDD总想着把规范做全做到“无死角”最后被无穷无尽的边界条件拖垮现在做规范目标变成了“能定义Harness的判定依据”让每一个关键决策都有据可依。规范不是为了穷尽世界是为了让harness“有法可依”。最后再分享一个小技巧无论是写规范还是写harness规则都尽量留着来源追溯信息。一条规则只要标了“来源于哪个需求、哪个评审结论、哪个线上事故”未来返工找线索的时候能省几倍的时间。这个习惯救过我不少次强烈建议你也试试。

AI Agent可控性关键：Harness Engineering与SDD如何协同落地

相关推荐

awesome-math 里最值得收藏的 11 个数学学习资源，附自学路线建议

LeetCode-Go 题解：137. Single Number II —— 三进制状态机位运算消灭出现三次的元素

抛帐与过账：财务系统凭证流转的核心逻辑与实操详解

更多资讯

大数据隐私保护：技术挑战与工程实践

基于 agno Agent Skills 构建代码审查助手：以 code-review Skill 为例的完整实战指南

Python开发者如何构建高质量作品集

tldraw 同步服务端评论写授权：深入 @tldraw/sync-collaboration 的 createCommentAuthorizers 实战指南

MATLAB实现光波导FDM仿真：原理与代码详解

如何给 UI UX Pro Max 的 styles.csv 添加一个新 UI 风格？

今日更新

CopilotKit Vue Demo 与 React Demo 的 Parity 实现指南：路由、运行时端点与交互语义的全框架对齐

Harbor RBAC 实战：db_auth 模式下非管理员用户管理项目成员的完整验证与权限模型解析

STM32平衡车纯平衡程序从拆包到参数整定的完整调试指南

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？