目录一、AI编程的三次跃迁从工具到伙伴1. 辅助时代行级补全只是个更快的打字员2. 对话时代Vibe Coding会说话就能写代码3. 智能体时代Harness工程人掌舵AI划船二、Harness工程到底在解决什么问题矛盾一能力越强越容易“野”矛盾二越“像人”越会“骗人”矛盾三偶尔“天才”经常“蠢材”三、行业里已经有人跑通了而且跑得还不错四、新范式下软件开发变成什么样了五、Harness工程的技术骨架四大组件六层架构深度详解四大核心组件扩展版六大准则与六层架构详细展开六、落地的坑四个绕不开的现实问题血泪经验1. 存量项目怎么接入Harness2. 多人协作怎么搞3. Harness是开箱即用的吗4. 非研发人员怎么参与七、写在最后深度展望大家好我是小马过河R最近这段时间小马一直在折腾Harness Engineering相关的落地实践。说来也巧从2022年一头扎进NLP领域开始到后来RAG、Agent、MCP一路摸爬滚打眼看着AI编程从“能帮我补两行代码”进化到“能自己干完一个模块”心里的感受挺复杂的——既有见证时代的兴奋也有“这玩意儿到底怎么落地才靠谱”的焦虑。今天这篇文章小马就想跟大家好好聊聊AI编程这一路走来的几个阶段以及当下火得一塌糊涂的Harness工程——它到底是什么、解决了什么问题、行业里谁已经跑通了、真正落地的时候又会踩哪些坑。都是小马最近实战下来的一些思考权当抛砖引玉。一、AI编程的三次跃迁从工具到伙伴说起来AI编程这几年的进化速度真的有点让人应接不暇。回头看看其实也就三四年的光景但感觉已经走过了好几个时代。每一次跃迁都不只是技术上的迭代更是我们对“编程”这件事本身的重新定义。1. 辅助时代行级补全只是个更快的打字员最早接触AI编码应该是GitHub Copilot刚出来那会儿。什么感觉呢就像给编辑器装了个超级自动补全——你写个函数开头它能帮你把后面几行补出来。敲个Tab省事不少。那时候我还在用VS Code每天最期待的就是Copilot能猜中我下一行要写什么偶尔猜中时那种“哇它懂我”的惊喜感现在想来还挺怀念。但冷静下来看这个阶段的AI本质上就是个熟练的打字员。它基于海量开源代码训练出来的统计规律能补全常见的模式——比如一个for循环、一个try-catch块、一个React useState的声明。可一旦你写的是业务逻辑特有的部分或者用到公司内部私有库它就彻底懵了。你得自己知道要写什么——逻辑你想架构你定bug你改AI充其量就是帮你省了点敲键盘的时间。编程的本质没变只是手速快了点。更有意思的是那个阶段大家对AI编程的态度两极分化。一部分人欢呼“程序员要失业了”另一部分人嗤之以鼻“这不就是个高级的IntelliSense吗”。事实证明两边都对了一点点——它确实只是个高级补全但也确实让很多重复劳动变轻了。我认识一个做后端的老哥用了Copilot之后每天能少敲2000行样板CRUD代码把精力腾出来琢磨数据库索引优化和缓存策略这才是真正的价值释放。2. 对话时代Vibe Coding会说话就能写代码大模型出来之后画风就变了。你用自然语言说一句“帮我写个用户登录的React组件要邮箱验证和密码强度检查”哗啦一下一整段代码就出来了。产品经理都能攒个原型出来玩编程门槛肉眼可见地往下掉。那段时间Twitter上全是“我用ChatGPT写了个小游戏”“我让Claude帮我搭了个博客”之类的帖子感觉人人都是程序员了。但问题也跟着来了。对话式AI嘛擅长的是单个的、逻辑清晰的小任务一旦你让它搞复杂项目——模块依赖、全局状态、长期维护——它就开始“失忆”了。上下文一长前面说的话后面就忘了改个bug改了这个坏了那个。小马自己就踩过不少坑最惨的一次是让AI帮我重构一个订单服务的状态机前后聊了二十几轮它每次都信誓旦旦说“这次没问题了”结果一跑单元测试就挂挂了它又改改了又挂别的最后我气得关掉对话自己花两小时重写了一遍——比跟AI掰扯快多了。古人云“纸上得来终觉浅”这话放在AI编程上也一样。光靠对话聊出来的代码看看Demo还行真要上生产心里总有点发虚。而且对话模式有一个天然缺陷人是线性提问AI也是线性回答但软件开发是网状结构——一个模块改了依赖它的十个地方都要跟着动这种复杂的连锁反应对话里根本说不清楚。所以那时候出现了一个很形象的词叫“Vibe Coding”——凭感觉写能不能跑看运气反正能跑就是赚到。3. 智能体时代Harness工程人掌舵AI划船现在我们正在进入第三个阶段。这不是简单的“对话更长了”或者“模型更强了”而是整个开发模式的底层逻辑变了。以前是人写代码AI辅助现在是人定规则和目标AI智能体自己跑完全流程——编码、测试、调试、甚至部署它都能干。你只需要给它一个需求描述它自己会去翻代码仓库、理解现有架构、设计实现方案、写代码、跑单测、修bug、提PR一气呵成。我在内部试用DeepSeek Harness的时候让它实现一个带缓存和重试机制的外部API调用模块它从理解现有的http客户端封装到写出完整的拦截器逻辑再到补充单元测试和集成测试一共用了不到二十分钟我只需要最后review一下合并——换作人工光写测试就要半小时。但要做到这一步光靠模型本身是不够的。你想啊大模型越强输出越不可控这是个反直觉但真实存在的矛盾。能力强的模型发散性也高“胡说八道”起来比谁都像真的。GPT-4能给你编一个有鼻子有眼的API连参数和返回值都设计得清清楚楚结果一查——根本不存在。Claude 3.5写代码速度快得惊人但也经常自作聪明地引入一些不存在的库函数。直接让这么个“天才选手”裸奔着写生产代码那跟裸奔着上高速没什么区别。所以就需要一套东西把AI的能力给“框”住——不是限制它而是让它在可控的范围内把能力发挥到最大。这就是Harness Engineering要干的事。“Harness”这个词原意是马具、挽具意思很形象不是把马拴住不让跑而是给它套上缰绳和马鞍让它朝着你想去的方向跑而且跑得稳、跑得远。它是一整套工程实践、架构准则、工具链和流程规范的集合体而不是某个单一的产品。二、Harness工程到底在解决什么问题说穿了Harness工程的核心价值就一件事把概率性输出的大模型变成一套可靠、可控、可审计的生产级执行系统。这个目标听起来简单但里面藏着三个深层次的矛盾Harness就是专门用来解这些矛盾的。矛盾一能力越强越容易“野”大模型的训练目标是“最大化下一个token的预测准确率”而不是“写出符合你项目规范的代码”。所以它天然倾向于给出最“自然”的答案而这个“自然”往往意味着用最通用的写法、最流行的库、最花哨的语法。但你的项目可能有自己的技术债、自己的命名规范、自己的私有基础设施——这些训练数据里可没有。于是AI写出来的代码虽然能跑但风格完全格格不入侵入性极强人工接手维护时痛苦不堪。Harness的第一板斧就是约束输出域。通过在意图定义阶段明确指定技术栈版本、依赖白名单、代码风格规则比如ESLint配置直接挂载到Agent的上下文里AI的候选输出空间被大大压缩。好比让一个画家只能用三种颜色画画虽然创意受限但每笔都在预期之内。再配合格式校验和类型检查凡是调用不存在的API、导入未声明的模块在第一层即时校验就会被拦截根本不会进入后续流程。矛盾二越“像人”越会“骗人”这是最头疼的幻觉问题。以前的规则引擎如果犯错错得明明白白——你一眼就能看出哪里逻辑不对。但大模型犯错是“一本正经地胡说八道”。它能给你生成一整段看起来完美无缺的代码注释写得比教科书还清楚可里面调用的一个工具函数压根不存在或者参数顺序反了。这种错误在Code Review时极难发现因为人的注意力会被代码的“表面合理性”带走只有真正运行时才会暴露。Harness应对这个问题的策略是多重验证钩子——不是等AI写完了再检查而是每生成一个代码块、每调用一个工具都触发实时的验证链路。比如Agent想调用一个sendEmail函数验证钩子会去检查当前项目的API清单里有没有这个函数签名是否匹配权限是否允许。如果没有直接拒绝并让Agent换一种实现。这就像给AI装了一个“实时事实核查员”让它不能信口开河。更有意思的是这些验证钩子本身也可以由AI生成和维护形成一个自我进化的验证体系。矛盾三偶尔“天才”经常“蠢材”用过Claude 3.7或DeepSeek-V3的人都知道这些模型有时候能给你一个惊艳的算法优化让你拍案叫绝但下一秒它可能连最简单的循环边界都写错。这种不稳定性在生产环境里是致命的——你不能指望今天的部署靠运气明天出问题再打补丁。Harness的解法是把“天才感”拉平均。通过效能保障层的指标监控比如圈复杂度、测试覆盖率、重复率、性能基线每当AI提交一次变更系统就自动运行完整的评估套件。如果某次提交导致性能下降超过5%或者覆盖率降低会触发回滚并记录这次“失败尝试”进入记忆库下次AI遇到类似场景时会避开这个坑。久而久之AI的行为模式被“驯化”得越来越稳虽然可能失去一些极端创新的可能性但换来了99%情况下的可靠交付。在工业界稳定压倒一切。这一切靠的是四个关键机制意图对齐确保AI理解的目标和人想的是一回事通过结构化需求文档和实例约束实现、环境编排给AI一个能自己跑、自己测的隔离沙箱包括数据库、mock服务、日志收集器、确定性治理每一步都有明确的校验规则规则本身用代码而非自然语言描述避免歧义、反馈循环出了问题能自动修还能记住教训形成持续改进的正向闭环。三、行业里已经有人跑通了而且跑得还不错Harness不是什么空中楼阁几家公司已经拿出了实打实的成果。小马给大家捋几个有代表性的从中可以看到不同路线上的不同收获。OpenAI Frontier应该是目前走得最远的。他们基于Electron架构用Codex Agent在5个月时间里自动生成了大约100万行代码基本做到了“零手写”的大规模开发。这个案例的震撼点不在于“AI能写代码”——这个大家都知道了——而在于AI已经能作为主力开发力量交付大型项目了。据公开资料Frontier项目涉及多个微服务、前端桌面应用和底层通信协议整个开发过程中人工只负责设计评审和关键安全审计。100万行代码如果换算成人月按一个高级工程师日均300行有效代码算大概是13人年的工作量而他们在5个月内完成效率提升超30倍。这件事的象征意义怎么强调都不过分。LangChain的故事更有启发。他们没有换模型而是深度优化了Harness评测框架结果在编码基准测试中从30多名直接冲到了Top 5。这说明什么模型能力是基础但工程化的约束和评测体系带来的提升可能更大。具体来说LangChain团队构建了一个包含数千个实际开发场景的评测集每个场景都配有正确的实现方案和常见的错误陷阱。他们的Harness框架会针对每个场景动态调整AI的上下文——比如对于涉及异步编程的任务会显式注入Python asyncio的最佳实践文档对于涉及数据库的任务会注入对应的ORM使用示例。这种“场景感知”的Harness设计让同样的模型在不同的任务上都能发挥出最优水平。这就是Harness的杠杆效应——同样的模型用不同的工程方法驾驭效果天差地别。Anthropic走了另一条路。他们搞了个“生成器-评估器”的对抗架构专门解决长代码开发的上下文瓶颈。简单说就是一个AI负责写代码另一个AI专门负责挑毛病两边对抗着迭代。生成器每产出一段代码评估器就模拟各种输入测试它找出边缘情况和潜在bug然后生成器根据反馈修改反复多轮直到评估器找不出问题。效果相当惊人——只用自然语言描述需求就能交付带物理引擎的2D游戏和专业编曲软件。这种“左右互搏”的思路小马觉得特别有意思它本质上是在Harness内部再嵌套了一层自我对抗机制不依赖外部验证而是用模型自身的能力来互相制衡。缺点是计算成本翻倍但对于高价值模块来说是值得的。腾讯则是大厂落地的代表。CodeBuddy、WorkBuddy、Marvis、光子游戏Agent……这些项目背后都有Harness工程化的影子。从辅助编码到端到端的业务场景落地腾讯的实践说明一个事Harness不是创业公司的玩具大厂同样在用而且用得很深。尤其值得一提的是腾讯的“光子游戏Agent”它被用于游戏内的NPC对话生成和任务逻辑编写要求极高的实时性和一致性。他们专门为游戏场景定制了Harness的约束层——限制AI只能使用预定义的游戏API禁止生成任何外部网络请求并对所有生成内容做严格的合规审查。这种垂直领域的Harness定制是未来最有潜力的方向之一。除了这几家还有不少公司在默默探索。比如GitLab正在把Harness理念融入他们的AI辅助DevOps产品Replit已经推出了基于Agent的完整项目生成功能背后有一套轻量级的Harness框架甚至连一些传统金融企业也在用Harness来约束AI编写合规的报表生成代码——因为金融行业的监管审计要求极高AI的自由发挥空间必须被严格控制。四、新范式下软件开发变成什么样了说了这么多案例可能有人会问Harness工程到底改变了什么不就是加了个AI助手吗还真不是。它改变的是软件开发的流程和角色是底层的生产关系甚至改变了“好代码”的定义。首先交付速度完全不一样了。传统开发里大量时间花在哪写样板代码、跑测试、改bug、做Code Review、等环境部署……这些冗余链路在Harness范式下被大幅压缩。AI写完代码立刻自己跑测试发现问题自己修人工只在关键节点介入。整个交付周期被压得很短短到什么程度以前按周算的需求现在可能按天甚至按小时算。我们内部做过一个对比实验一个中等复杂度的用户画像服务重构纯人工开发预估5个工作日Harness辅助下实际用了1.5天其中人工投入只有4个小时的架构设计和最终Code Review。剩下的时间AI在后台自动迭代人可以去处理其他更高优先级的任务。多任务并行这是传统模式给不了的。其次参与软件开发的人变了。以前写代码是研发的专属领地产品、设计、运营只能在外围提需求。现在不一样了——只要能把需求说清楚、把规则定义明白非技术人员也能通过AI智能体深度参与到软件构建中。我见过一个团队的产品经理自己用Harness的意图定义模块写了一份详细的需求规格说明用Markdown示例JSON然后触发AI Agent直接生成了一版可运行的原型前后不到一小时。这在以前要经历需求评审、技术方案设计、排期开发、测试至少一周。团队协作的边界被拓宽了这可能是比“效率提升”更深远的变化。当人人都能“召唤”代码时组织的创新速度会指数级上升。最后也是最根本的——开发者的角色变了。以后的开发者不再是天天埋头写代码的人而更像三种角色的混合体环境设计师搭建适合AI工作的开发环境和工具链包括CI/CD流水线适配、测试数据工厂、mock服务、日志聚合系统让AI能在这个环境里自由驰骋而不破坏生产。意图定义者把模糊的业务需求翻译成AI能理解的精确指令和规则这需要有很强的抽象能力和业务理解力而不是单纯的编码技巧。反馈循环搭建者设计校验机制和纠错路径让AI能自己发现问题、修复问题这本质上是“元编程”——写代码来管理代码的生成过程。至于编码的具体执行交给AI就好了。打个比方以前开发者是厨师自己切菜自己炒菜以后更像餐厅经理——定菜单、控品质、培训后厨具体烹饪工作由智能体厨房来完成。这个转变对很多老程序员来说是挑战因为他们习惯了亲手敲代码的掌控感但也是机遇因为那些重复性劳动被剥离后人的创造力和决策力会被放大到前所未有的程度。五、Harness工程的技术骨架四大组件六层架构深度详解说了这么多“是什么”和“为什么”接下来聊聊“怎么做”。Harness工程到底由什么构成这里我会深入到一些技术细节给真正想落地的朋友一些可操作的参考。四大核心组件扩展版一个完整的Harness体系离不开这四根支柱每一根都有丰富的内部设计。① 意图定义让AI理解项目结构和业务规则不能每次对话都从零开始讲一遍。实践中的做法是把代码仓库作为“唯一真理源”用一个大约100行的AGENTS.md文件做导航索引指向各个模块的结构化文档。再配一个文档维护Agent确保文档和代码同步更新——不然文档是三年前的AI照着写肯定出问题。但意图定义远不止一个导航文件。深度的做法还包括需求规格库用Gherkin语法Given-When-Then编写的用户故事AI可以直接解析成行为驱动开发的测试用例。API契约集OpenAPI/Swagger文件明确每个接口的输入输出、错误码、权限要求。数据字典每个数据实体User、Order、Product等的字段定义、校验规则、关联关系。业务规则引擎把业务逻辑封装成可执行的规则比如“折扣不能超过20%”、“库存不足时自动下架”AI在生成代码时必须引用这些规则而非自己发明。所有这些结构化知识通过RAG检索增强生成方式在AI每次行动前注入上下文。关键是时效性——文档一旦变更索引必须同步刷新否则AI就会基于旧信息决策。我们内部用了一个变更监听器每次合并到主分支的文档变更都会触发重新索引延迟不超过30秒。# AGENTS.md 导航索引示例扩写 1. **用户认证模块** - 描述处理登录、注册、用户资料管理 - 位置/src/modules/auth - 依赖Firebase Auth、React - 关键APIlogin(email, password) → UserToken, register(userData) → User - 异常场景密码错误超过5次锁定账号需captcha验证 2. **仪表盘模块** - 描述展示用户数据分析和控制面板 - 位置/src/modules/dashboard - 依赖Chart.js、React、Redux - 数据源从/api/dashboard/stats获取聚合数据缓存5分钟 3. **支付模块**核心业务 - 位置/src/modules/payment - 依赖Stripe SDK、数据库事务 - 规则订单金额500元需二次确认支付失败自动重试3次间隔2秒② 执行环境AI不能只靠“想”来写代码它得有地方“试”。面向Agent改造的执行环境需要支持独立启动应用实例让Agent自己去复现bug、验证修复。这个环境不是简单的本地沙箱而是一整套镜像基础设施隔离的数据库实例每个Agent会话拥有独立的schema或数据库避免数据污染。模拟外部依赖用WireMock或类似工具模拟第三方API让AI能测试各种异常响应超时、500错误、限流。可观测性埋点每个Agent操作都生成分布式追踪span记录它执行了哪些命令、调用了哪些工具、看到了哪些输出。快速回滚能力每次Agent修改代码前自动创建代码快照和数据库快照一旦验证失败一键回滚到上一个稳定状态。更重要的是要给Agent提供“感官输入”——UI截图、DOM快照、全链路遥测数据。我们给Agent集成了一套轻量级的UI自动化框架当它修改了前端代码后可以自动打开无头浏览器渲染页面截取关键界面并与预期设计稿比对用视觉模型判断差异。后端改动则通过日志聚合和APM数据来验证性能指标。就像给盲人配上眼睛和耳朵它才能在复杂工程里自己找到问题、纠正错误。没有这些输入AI就是在黑暗里摸索写出来的代码能不能跑全靠猜。# 执行环境示例让 Agent 自主复现和验证扩写importsubprocessimporttimefromtypingimportDict,AnyclassAgentEnvironment:def__init__(self,app_path:str,db_uri:str,mock_config:Dict):self.app_pathapp_path self.db_uridb_uri# 隔离的数据库连接self.mock_configmock_config# 第三方mock规则self.processNoneself.snapshot_idNonedefstart_app(self):# 启动应用注入环境变量指向隔离DB和mock服务envos.environ.copy()env[DATABASE_URL]self.db_uri env[MOCK_ENABLED]trueself.processsubprocess.Popen([npm,start],cwdself.app_path,envenv)time.sleep(5)# 等待服务就绪defcapture_snapshot(self):# 创建代码和数据库的快照用于回滚self.snapshot_idfsnap_{int(time.time())}subprocess.run([git,checkpoint,self.snapshot_id],cwdself.app_path)# 数据库快照使用pg_dump或mongoexportreturnself.snapshot_iddefreproduce_bug(self,bug_desc:str):# AI agent 与应用交互复现 bug比如发送特定请求print(f复现 bug:{bug_desc})# 调用内部测试客户端模拟用户操作responsetest_client.post(/api/order,json{product:bug_desc[product]})returnresponse.status_code,response.json()defverify_fix(self,fix_desc:str):# 运行全部单元测试和集成测试并检查性能基线test_resultsubprocess.run([npm,test],cwdself.app_path,capture_outputTrue)coverageself.get_coverage()perfself.get_perf_metrics()return{tests_passed:test_result.returncode0,coverage:coverage,performance:perf}③ 反馈循环深度剖析这是Harness工程的“免疫系统”。核心是分层校验每一层都有不同的时间粒度和故障代价最内层即时校验 100ms格式对不对JSON/YAML语法、语法有没有问题AST解析、API存在不存在静态符号表查找、类型是否匹配TypeScript类型检查。这层完全在内存中完成不涉及外部调用速度极快。一旦失败Agent立即被中断并收到结构化错误反馈。中间层多维反馈1~5分钟单元测试过了吗集成测试挂没挂Lint有没有报错代码风格是否符合规范这一层需要实际运行测试套件耗时稍长但覆盖面广。我们还会引入变异测试——故意在代码中植入一些常见错误如改变边界条件看测试能否发现以此评估测试质量。最外层效能保障10分钟~小时级性能有没有退化对比历史基线安全漏洞有没有引入SAST扫描依赖有没有新增高危版本供应链安全检查资源消耗是否异常内存泄漏检测这一层通常放在CI流水线中异步执行不阻塞Agent的下一步但如果发现问题会触发告警并自动回滚最近的变更。每一层都是一道闸门问题在越内层被发现修复成本越低。我们的统计显示即时校验拦截了约65%的错误中间层拦截了约28%最外层只拦截了7%。但正是那7%往往是最致命的——比如性能滑坡和安全漏洞早期难以感知一旦上线就是大事故。# 反馈循环示例工具调用前后校验扩写defvalidate_tool_call(tool_name:str,input_data:dict,context:dict)-bool:# 第一层格式校验ifnotisinstance(input_data,dict):returnFalse,输入必须是字典# 第二层安全校验——防止命令注入或路径遍历ifpathininput_dataand../ininput_data[path]:returnFalse,非法路径访问# 第三层权限校验——该工具是否允许当前Agent角色调用iftool_namenotincontext[allowed_tools]:returnFalse,f工具{tool_name}未授权# 第四层参数合法性——根据工具定义检查必填字段和值域schemacontext[tool_schemas][tool_name]forfield,rulesinschema.items():ifrules.get(required)andfieldnotininput_data:returnFalse,f缺少必填参数{field}ifenuminrulesandinput_data[field]notinrules[enum]:returnFalse,f参数{field}值不在允许范围returnTrue,校验通过④ 效能保障量化实践说起来有点反直觉要让AI写代码写得好技术栈不能太花哨。选那些训练数据里出现频率高、生态成熟的“低复杂度”技术栈AI对它们更熟悉出错概率低很多。我们内部有一个“技术栈适应性评分”——针对每个框架/库统计它在主流LLM训练数据中的token覆盖率和最新版本的API正确率。比如Python的FastAPI和Django得分很高而一些冷门的纯函数式语言如Elm得分很低。你在选型时就要权衡新技术固然有优势但AI的驾驭成本会直线上升。除了技术栈选择效能保障还包括代码复杂度门禁AI生成的函数圈复杂度不能超过10否则强制要求拆分重构。重复率监控如果AI在多个地方生成相似的代码块提示它提取公共函数。可维护性索引结合注释率、命名规范性、模块耦合度等综合评分低于阈值则触发人工review。知识沉淀每次AI成功修复一个复杂bug我们将修复过程和根因分析写入“经验库”以后遇到类似问题直接检索复用。六大准则与六层架构详细展开落地Harness工程有六个核心准则要守住每一条背后都有大量实战教训上下文架构信息怎么组织、怎么喂给AI。不是一股脑把所有文件都塞进prompt而是根据当前任务类型动态检索最相关的模块文档和代码片段。我们采用向量数据库索引整个代码库每次任务开始时做语义相似度检索只注入top-k个最相关的上下文片段。架构约束不能让AI随便改核心代码。核心模块如鉴权、数据库连接池、核心业务实体要有保护在AGENTS.md中明确标记为“只读”或“需人工审批”AI如果尝试修改会被拦截并引导它提供修改建议而非直接执行。自验证循环自己写的代码自己测写完就跑测试。我们强制要求AI在提交任何代码变更前必须运行至少一个相关的测试用例并通过。如果AI无法写出测试它会被要求先写测试再写实现——TDD测试驱动开发被强制嵌入Harness。上下文隔离不同任务互不干扰避免串味。每个Agent会话有独立的临时分支和沙箱环境任务完成后合并到主线。如果多个Agent同时修改同一文件我们借鉴Git的冲突检测机制在合并时由AI辅助解决冲突。熵治理防止代码库越改越乱。我们定期运行代码健康度扫描如果发现技术债指标持续恶化如循环依赖增多、抽象层次混乱会触发一个“重构Agent”专门负责清理保持代码库整洁。可拆卸设计出问题能快速回退不能一崩全崩。所有AI生成的变更都以PR形式提交且每个PR的每个commit都对应一个可独立回滚的功能点一旦发现问题可以精确回滚到任意历史状态。具体实现上是六层架构从下到上分别是┌─────────────────────────────────────┐ │ ⑥ 观测与评估体系 干得好不好 │ 这一层负责收集所有指标、生成报告、提供可视化仪表盘让团队对AI的贡献和风险一目了然。 ├─────────────────────────────────────┤ │ ⑤ 约束与恢复机制 出问题怎么办 │ 当错误发生时自动触发回滚、降级或人工介入流程有完整的应急预案。 ├─────────────────────────────────────┤ │ ④ 验证钩子 对不对 │ 即前文的多层校验每个工具调用和代码产出都经过严格验证。 ├─────────────────────────────────────┤ │ ③ 记忆与状态管理 记住了什么 │ 维护跨会话的长期记忆经验库、技术决策记录和短期状态当前任务进度、已修改文件列表。 ├─────────────────────────────────────┤ │ ② 执行编排 怎么干活 │ 负责任务拆解、工具分配、执行顺序调度类似一个AI的“操作系统调度器”。 ├─────────────────────────────────────┤ │ ① 信息边界与工具规范知道什么、能用什么│ 明确AI能访问哪些文件、调用哪些API、使用哪些外部服务所有工具的schema和权限都在这层定义。 └─────────────────────────────────────┘底层管“AI知道什么、能用什么”中间管“AI怎么干活、怎么记东西”上层管“干得对不对、出问题怎么办、怎么知道效果好不好”。这六层叠在一起才构成了Harness工程的完整技术骨架。每一层都可以独立迭代优化比如你发现验证钩子漏掉了某种错误可以单独加强第四层而不影响其他层。六、落地的坑四个绕不开的现实问题血泪经验前面讲的都是理想状态。真正落到实际项目里麻烦事不少。下面这四个问题是小马这段时间实战下来感触最深的几乎所有尝试Harness工程的团队都会碰到。1. 存量项目怎么接入Harness新项目可以从零开始搭但已有的存量项目怎么办架构复杂、文档缺失、技术债一堆——这都是现实。我们团队接手的是一个有六年历史的后端系统光Java代码就有50万行服务间调用关系像蜘蛛网一样复杂。一开始想全量引入Harness结果Agent光理解代码结构就花了半天生成的第一个PR直接导致集成测试大面积失败。小马的经验是先建地图再逐步套壳。第一步不是上来就让AI写代码而是先做代码和业务的梳理。用分析工具如jQAssistant、SonarQube的依赖图把代码结构、依赖关系摸清楚建一个“检索地图”让AI至少能看懂项目长什么样。同时从规则和记忆入手把缺失的文档和规范慢慢补起来。我们专门安排了一个实习生花了两周时间把各个模块的职责、关键接口、数据流向整理成文档并编写了对应的AGENTS.md索引。这个过程虽然辛苦但本身就是一次很好的知识沉淀。然后用渐进式策略优先挑核心业务和高频变更的模块下手——这些模块改得多、价值也大先把单个模块的Harness搭起来、跑通、验证效果再逐步扩大范围。比如我们第一个试点是“用户通知服务”——负责发送邮件和短信业务逻辑相对独立变更频繁。仅针对这个模块配置了完整的意图定义、执行环境和验证钩子运行了两周效果不错再推广到订单服务和支付服务。一上来就想整个项目全覆盖大概率会翻车。2. 多人协作怎么搞Harness不是一个人的玩具真实环境里都是团队一起用。多人用一个Harness框架权限怎么分任务怎么拆代码怎么合一个思路是权限分层。把Harness里的共享资产——规则、技能、钩子配置、manifest文件——按权限等级管理。高级别的人架构师、Tech Lead才能改核心规则普通开发者主要在业务代码层面操作而新人可能只被允许在隔离的沙箱里实验性使用。这样既保证了框架的稳定性又不影响日常开发效率。我们采用RBAC模型将Harness配置文件和代码仓库的权限绑定同一个Git分支的保护规则也同步应用到Harness操作。另一个关键是环境隔离和任务解耦。每个人有自己的独立开发环境基于容器化互不干扰任务完成后再合并到主环境。每个任务都拆解成原子性的用户故事每个故事对应一个独立分支。任务拆解得越干净代码冲突越少。某种程度上这和微服务的思路是通的——把大系统拆成小模块各管各的通过接口交互。我们在任务拆解阶段专门安排了一个“Harness 规划师”角色由资深开发担任负责将大的需求拆成AI能独立完成的子任务并排定依赖顺序。3. Harness是开箱即用的吗很多人刚接触的时候会问“有没有现成的Harness框架我拿来装一下就能用”真实答案是不是而且差得远。Harness不是一个产品而是一个持续收紧、不断演进的过程。每个项目的业务需求、技术架构、团队成熟度都不一样没有放之四海而皆准的方案。金融项目和社交项目对安全和性能的要求天差地别它们的Harness框架自然也会长得不一样。比如金融项目要求所有AI生成的代码必须经过静态安全分析和模糊测试而社交项目可能更关注UI的响应速度和A/B测试能力。规则和约束不是一次性定死的而是随着业务发展、团队壮大逐步加严。项目初期可能只要基本语法规范到了后期就得加上代码复杂度分析、覆盖率检查、安全扫描等等。我们的经验是每个季度review一次Harness配置根据过去三个月的故障回顾和效率数据调整各层校验的阈值和规则。比如发现最近API幻觉问题增多就加强“即时校验”中的API存在性检查发现性能退化频繁就调低效能保障层的性能退化容忍度。指望买一个Harness工具然后就万事大吉是不现实的。它更像一套方法论需要结合具体项目慢慢打磨。市面上有些所谓的“Harness平台”其实只是提供了脚手架和可视化配置界面核心的规则编写、测试适配、异常场景覆盖还得团队自己来。4. 非研发人员怎么参与Harness降低了编程门槛但产品经理、测试人员这些非研发角色具体怎么和AI智能体协作一种模式是**“双轨制”**——研发有研发的仓库分支和规则分支非研发有自己的分支。研发在开发分支上写代码、改规则非研发在自己的分支上写需求文档、设计测试用例两边在关键节点上同步对齐。产品经理可以直接在自己的分支上更新需求AI智能体根据最新需求调整开发方向减少了大量中间传话的损耗。我们曾有一个需求变更以前要经过产品→开发→测试来回三四天现在产品在分支上修改需求文档触发Harness的变更监听AI自动感知并重新生成对应的实现和测试整个流程压缩到半天以内。还有一种更彻底的方式仓库脱离规则共享。非研发人员有自己独立的仓库和工作流程不用碰研发的代码库但底层的Harness规则是共享的。比如测试团队维护自己的测试用例仓库用Cucumber或类似框架AI根据研发的代码变更自动拉取对应的测试用例跑一遍结果反馈给两边。两边的仓库在物理上是分开的但通过Harness的规则体系连在了一起——规则里定义了哪个测试套件对应哪个模块变更时自动触发关联测试。这些模式目前都还在探索中没有标准答案。但方向是明确的软件开发不再只是工程师的事越来越多角色会参与进来。我们甚至尝试让UI设计师通过上传Figma设计稿Harness自动解析成前端组件的布局代码设计师不需要写一行CSS就能看到可交互的页面原型。七、写在最后深度展望聊到这里有几个问题其实一直萦绕着小马。你手头的项目现在有没有引入Harness如果有效果怎么样是真的提升了效率还是只是多了个“高级Copilot”的噱头这个问题的答案决定了Harness工程到底是下一个大趋势还是又一轮技术泡沫。从我看到的趋势来说Harness的落地效果取决于投入的深度——浅尝辄止的团队往往只得到10%20%的效率提升而深度定制、持续优化的团队能获得50%80%的显著改善。关键在于是否把Harness当成一项战略性投资而非临时工具。开发者该怎么选市面上已经有DeepSeek Harness、CodeX Harness这些工具了还有更多正在冒出来。选哪个、怎么落地、投入多少资源——这些决策没有标准答案只能靠团队自己摸索。我的建议是先拿一个非核心但真实的小项目做PoC概念验证跑通全流程评估投入产出比再决定是否大范围推广。不要一上来就被厂商的宣传牵着走要结合自己团队的技能栈和业务痛点来定制。还有一个更大的问题Harness的边界在哪里现在大家讨论的都是软件开发但这套方法论——给AI建约束、做验证、搭反馈循环——能不能用到别的地方自动化运维让AI自主修复线上故障但要限制它不能重启关键服务、智能客服AI回答客户问题但需要校验合规性和情绪语气、数据分析AI生成SQL查询但必须经过成本预估和权限审查、甚至设计和内容创作AI生成图片和文案但要符合品牌指南和版权规则——只要有AI智能体参与的场景似乎都需要某种形式的“Harness”。我甚至设想过一个“通用Harness框架”抽象出约束定义、验证钩子、反馈循环等核心组件适配不同领域的AI应用那将是一个基础设施级别的产品。如果真是这样那Harness工程的意义就远不止“改变软件开发”这么简单了。它可能是我们学会和高能AI共处的第一套系统性方法——怎么让强大但不稳定的智能体在人类设定的轨道上稳定地干活、持续地产出价值。它关乎信任——我们信任AI的输出不是因为AI不会错而是因为我们有能力检测和纠正它的错误。这种“信任但验证”的关系可能是未来人机协作的主旋律。这件事刚刚开始。未来几年我们会看到更多实践、更多踩坑、也更多真正跑通的案例。作为开发者与其焦虑“AI会不会取代我”不如早点琢磨怎么当那个“搭Harness的人”——毕竟厨房里的智能体再多总得有人来当经理吧。而且这个经理的角色比现在的工程师更有趣、更有挑战性——你需要懂业务、懂架构、懂AI的脾气、懂工程化的约束设计还要有很好的沟通能力来协调各方。这是一个复合型角色的崛起值得我们为之准备。最后我还想提一下成本问题。Harness工程不是免费的——模型调用费用、额外的算力用于验证和对抗、环境维护成本、人力投入配置规则、维护文档、设计评测集都不低。但相对于它带来的效率提升和质量保障大部分团队在规模到达一定级别后都会是净收益。小团队可以走轻量化路线用开源模型简化版的验证钩子先跑起来再慢慢加厚。一斤代码二两酒码路漫漫咱们边走边看。希望这篇文章能给你一些启发也希望未来能看到更多国产Harness实践的分享——毕竟中文语境下的业务逻辑和代码库有自己独特的复杂性这方面的本土经验尤为宝贵。
AI编程进化史：从补全到Harness，智能体时代我们如何驾驭代码
目录一、AI编程的三次跃迁从工具到伙伴1. 辅助时代行级补全只是个更快的打字员2. 对话时代Vibe Coding会说话就能写代码3. 智能体时代Harness工程人掌舵AI划船二、Harness工程到底在解决什么问题矛盾一能力越强越容易“野”矛盾二越“像人”越会“骗人”矛盾三偶尔“天才”经常“蠢材”三、行业里已经有人跑通了而且跑得还不错四、新范式下软件开发变成什么样了五、Harness工程的技术骨架四大组件六层架构深度详解四大核心组件扩展版六大准则与六层架构详细展开六、落地的坑四个绕不开的现实问题血泪经验1. 存量项目怎么接入Harness2. 多人协作怎么搞3. Harness是开箱即用的吗4. 非研发人员怎么参与七、写在最后深度展望大家好我是小马过河R最近这段时间小马一直在折腾Harness Engineering相关的落地实践。说来也巧从2022年一头扎进NLP领域开始到后来RAG、Agent、MCP一路摸爬滚打眼看着AI编程从“能帮我补两行代码”进化到“能自己干完一个模块”心里的感受挺复杂的——既有见证时代的兴奋也有“这玩意儿到底怎么落地才靠谱”的焦虑。今天这篇文章小马就想跟大家好好聊聊AI编程这一路走来的几个阶段以及当下火得一塌糊涂的Harness工程——它到底是什么、解决了什么问题、行业里谁已经跑通了、真正落地的时候又会踩哪些坑。都是小马最近实战下来的一些思考权当抛砖引玉。一、AI编程的三次跃迁从工具到伙伴说起来AI编程这几年的进化速度真的有点让人应接不暇。回头看看其实也就三四年的光景但感觉已经走过了好几个时代。每一次跃迁都不只是技术上的迭代更是我们对“编程”这件事本身的重新定义。1. 辅助时代行级补全只是个更快的打字员最早接触AI编码应该是GitHub Copilot刚出来那会儿。什么感觉呢就像给编辑器装了个超级自动补全——你写个函数开头它能帮你把后面几行补出来。敲个Tab省事不少。那时候我还在用VS Code每天最期待的就是Copilot能猜中我下一行要写什么偶尔猜中时那种“哇它懂我”的惊喜感现在想来还挺怀念。但冷静下来看这个阶段的AI本质上就是个熟练的打字员。它基于海量开源代码训练出来的统计规律能补全常见的模式——比如一个for循环、一个try-catch块、一个React useState的声明。可一旦你写的是业务逻辑特有的部分或者用到公司内部私有库它就彻底懵了。你得自己知道要写什么——逻辑你想架构你定bug你改AI充其量就是帮你省了点敲键盘的时间。编程的本质没变只是手速快了点。更有意思的是那个阶段大家对AI编程的态度两极分化。一部分人欢呼“程序员要失业了”另一部分人嗤之以鼻“这不就是个高级的IntelliSense吗”。事实证明两边都对了一点点——它确实只是个高级补全但也确实让很多重复劳动变轻了。我认识一个做后端的老哥用了Copilot之后每天能少敲2000行样板CRUD代码把精力腾出来琢磨数据库索引优化和缓存策略这才是真正的价值释放。2. 对话时代Vibe Coding会说话就能写代码大模型出来之后画风就变了。你用自然语言说一句“帮我写个用户登录的React组件要邮箱验证和密码强度检查”哗啦一下一整段代码就出来了。产品经理都能攒个原型出来玩编程门槛肉眼可见地往下掉。那段时间Twitter上全是“我用ChatGPT写了个小游戏”“我让Claude帮我搭了个博客”之类的帖子感觉人人都是程序员了。但问题也跟着来了。对话式AI嘛擅长的是单个的、逻辑清晰的小任务一旦你让它搞复杂项目——模块依赖、全局状态、长期维护——它就开始“失忆”了。上下文一长前面说的话后面就忘了改个bug改了这个坏了那个。小马自己就踩过不少坑最惨的一次是让AI帮我重构一个订单服务的状态机前后聊了二十几轮它每次都信誓旦旦说“这次没问题了”结果一跑单元测试就挂挂了它又改改了又挂别的最后我气得关掉对话自己花两小时重写了一遍——比跟AI掰扯快多了。古人云“纸上得来终觉浅”这话放在AI编程上也一样。光靠对话聊出来的代码看看Demo还行真要上生产心里总有点发虚。而且对话模式有一个天然缺陷人是线性提问AI也是线性回答但软件开发是网状结构——一个模块改了依赖它的十个地方都要跟着动这种复杂的连锁反应对话里根本说不清楚。所以那时候出现了一个很形象的词叫“Vibe Coding”——凭感觉写能不能跑看运气反正能跑就是赚到。3. 智能体时代Harness工程人掌舵AI划船现在我们正在进入第三个阶段。这不是简单的“对话更长了”或者“模型更强了”而是整个开发模式的底层逻辑变了。以前是人写代码AI辅助现在是人定规则和目标AI智能体自己跑完全流程——编码、测试、调试、甚至部署它都能干。你只需要给它一个需求描述它自己会去翻代码仓库、理解现有架构、设计实现方案、写代码、跑单测、修bug、提PR一气呵成。我在内部试用DeepSeek Harness的时候让它实现一个带缓存和重试机制的外部API调用模块它从理解现有的http客户端封装到写出完整的拦截器逻辑再到补充单元测试和集成测试一共用了不到二十分钟我只需要最后review一下合并——换作人工光写测试就要半小时。但要做到这一步光靠模型本身是不够的。你想啊大模型越强输出越不可控这是个反直觉但真实存在的矛盾。能力强的模型发散性也高“胡说八道”起来比谁都像真的。GPT-4能给你编一个有鼻子有眼的API连参数和返回值都设计得清清楚楚结果一查——根本不存在。Claude 3.5写代码速度快得惊人但也经常自作聪明地引入一些不存在的库函数。直接让这么个“天才选手”裸奔着写生产代码那跟裸奔着上高速没什么区别。所以就需要一套东西把AI的能力给“框”住——不是限制它而是让它在可控的范围内把能力发挥到最大。这就是Harness Engineering要干的事。“Harness”这个词原意是马具、挽具意思很形象不是把马拴住不让跑而是给它套上缰绳和马鞍让它朝着你想去的方向跑而且跑得稳、跑得远。它是一整套工程实践、架构准则、工具链和流程规范的集合体而不是某个单一的产品。二、Harness工程到底在解决什么问题说穿了Harness工程的核心价值就一件事把概率性输出的大模型变成一套可靠、可控、可审计的生产级执行系统。这个目标听起来简单但里面藏着三个深层次的矛盾Harness就是专门用来解这些矛盾的。矛盾一能力越强越容易“野”大模型的训练目标是“最大化下一个token的预测准确率”而不是“写出符合你项目规范的代码”。所以它天然倾向于给出最“自然”的答案而这个“自然”往往意味着用最通用的写法、最流行的库、最花哨的语法。但你的项目可能有自己的技术债、自己的命名规范、自己的私有基础设施——这些训练数据里可没有。于是AI写出来的代码虽然能跑但风格完全格格不入侵入性极强人工接手维护时痛苦不堪。Harness的第一板斧就是约束输出域。通过在意图定义阶段明确指定技术栈版本、依赖白名单、代码风格规则比如ESLint配置直接挂载到Agent的上下文里AI的候选输出空间被大大压缩。好比让一个画家只能用三种颜色画画虽然创意受限但每笔都在预期之内。再配合格式校验和类型检查凡是调用不存在的API、导入未声明的模块在第一层即时校验就会被拦截根本不会进入后续流程。矛盾二越“像人”越会“骗人”这是最头疼的幻觉问题。以前的规则引擎如果犯错错得明明白白——你一眼就能看出哪里逻辑不对。但大模型犯错是“一本正经地胡说八道”。它能给你生成一整段看起来完美无缺的代码注释写得比教科书还清楚可里面调用的一个工具函数压根不存在或者参数顺序反了。这种错误在Code Review时极难发现因为人的注意力会被代码的“表面合理性”带走只有真正运行时才会暴露。Harness应对这个问题的策略是多重验证钩子——不是等AI写完了再检查而是每生成一个代码块、每调用一个工具都触发实时的验证链路。比如Agent想调用一个sendEmail函数验证钩子会去检查当前项目的API清单里有没有这个函数签名是否匹配权限是否允许。如果没有直接拒绝并让Agent换一种实现。这就像给AI装了一个“实时事实核查员”让它不能信口开河。更有意思的是这些验证钩子本身也可以由AI生成和维护形成一个自我进化的验证体系。矛盾三偶尔“天才”经常“蠢材”用过Claude 3.7或DeepSeek-V3的人都知道这些模型有时候能给你一个惊艳的算法优化让你拍案叫绝但下一秒它可能连最简单的循环边界都写错。这种不稳定性在生产环境里是致命的——你不能指望今天的部署靠运气明天出问题再打补丁。Harness的解法是把“天才感”拉平均。通过效能保障层的指标监控比如圈复杂度、测试覆盖率、重复率、性能基线每当AI提交一次变更系统就自动运行完整的评估套件。如果某次提交导致性能下降超过5%或者覆盖率降低会触发回滚并记录这次“失败尝试”进入记忆库下次AI遇到类似场景时会避开这个坑。久而久之AI的行为模式被“驯化”得越来越稳虽然可能失去一些极端创新的可能性但换来了99%情况下的可靠交付。在工业界稳定压倒一切。这一切靠的是四个关键机制意图对齐确保AI理解的目标和人想的是一回事通过结构化需求文档和实例约束实现、环境编排给AI一个能自己跑、自己测的隔离沙箱包括数据库、mock服务、日志收集器、确定性治理每一步都有明确的校验规则规则本身用代码而非自然语言描述避免歧义、反馈循环出了问题能自动修还能记住教训形成持续改进的正向闭环。三、行业里已经有人跑通了而且跑得还不错Harness不是什么空中楼阁几家公司已经拿出了实打实的成果。小马给大家捋几个有代表性的从中可以看到不同路线上的不同收获。OpenAI Frontier应该是目前走得最远的。他们基于Electron架构用Codex Agent在5个月时间里自动生成了大约100万行代码基本做到了“零手写”的大规模开发。这个案例的震撼点不在于“AI能写代码”——这个大家都知道了——而在于AI已经能作为主力开发力量交付大型项目了。据公开资料Frontier项目涉及多个微服务、前端桌面应用和底层通信协议整个开发过程中人工只负责设计评审和关键安全审计。100万行代码如果换算成人月按一个高级工程师日均300行有效代码算大概是13人年的工作量而他们在5个月内完成效率提升超30倍。这件事的象征意义怎么强调都不过分。LangChain的故事更有启发。他们没有换模型而是深度优化了Harness评测框架结果在编码基准测试中从30多名直接冲到了Top 5。这说明什么模型能力是基础但工程化的约束和评测体系带来的提升可能更大。具体来说LangChain团队构建了一个包含数千个实际开发场景的评测集每个场景都配有正确的实现方案和常见的错误陷阱。他们的Harness框架会针对每个场景动态调整AI的上下文——比如对于涉及异步编程的任务会显式注入Python asyncio的最佳实践文档对于涉及数据库的任务会注入对应的ORM使用示例。这种“场景感知”的Harness设计让同样的模型在不同的任务上都能发挥出最优水平。这就是Harness的杠杆效应——同样的模型用不同的工程方法驾驭效果天差地别。Anthropic走了另一条路。他们搞了个“生成器-评估器”的对抗架构专门解决长代码开发的上下文瓶颈。简单说就是一个AI负责写代码另一个AI专门负责挑毛病两边对抗着迭代。生成器每产出一段代码评估器就模拟各种输入测试它找出边缘情况和潜在bug然后生成器根据反馈修改反复多轮直到评估器找不出问题。效果相当惊人——只用自然语言描述需求就能交付带物理引擎的2D游戏和专业编曲软件。这种“左右互搏”的思路小马觉得特别有意思它本质上是在Harness内部再嵌套了一层自我对抗机制不依赖外部验证而是用模型自身的能力来互相制衡。缺点是计算成本翻倍但对于高价值模块来说是值得的。腾讯则是大厂落地的代表。CodeBuddy、WorkBuddy、Marvis、光子游戏Agent……这些项目背后都有Harness工程化的影子。从辅助编码到端到端的业务场景落地腾讯的实践说明一个事Harness不是创业公司的玩具大厂同样在用而且用得很深。尤其值得一提的是腾讯的“光子游戏Agent”它被用于游戏内的NPC对话生成和任务逻辑编写要求极高的实时性和一致性。他们专门为游戏场景定制了Harness的约束层——限制AI只能使用预定义的游戏API禁止生成任何外部网络请求并对所有生成内容做严格的合规审查。这种垂直领域的Harness定制是未来最有潜力的方向之一。除了这几家还有不少公司在默默探索。比如GitLab正在把Harness理念融入他们的AI辅助DevOps产品Replit已经推出了基于Agent的完整项目生成功能背后有一套轻量级的Harness框架甚至连一些传统金融企业也在用Harness来约束AI编写合规的报表生成代码——因为金融行业的监管审计要求极高AI的自由发挥空间必须被严格控制。四、新范式下软件开发变成什么样了说了这么多案例可能有人会问Harness工程到底改变了什么不就是加了个AI助手吗还真不是。它改变的是软件开发的流程和角色是底层的生产关系甚至改变了“好代码”的定义。首先交付速度完全不一样了。传统开发里大量时间花在哪写样板代码、跑测试、改bug、做Code Review、等环境部署……这些冗余链路在Harness范式下被大幅压缩。AI写完代码立刻自己跑测试发现问题自己修人工只在关键节点介入。整个交付周期被压得很短短到什么程度以前按周算的需求现在可能按天甚至按小时算。我们内部做过一个对比实验一个中等复杂度的用户画像服务重构纯人工开发预估5个工作日Harness辅助下实际用了1.5天其中人工投入只有4个小时的架构设计和最终Code Review。剩下的时间AI在后台自动迭代人可以去处理其他更高优先级的任务。多任务并行这是传统模式给不了的。其次参与软件开发的人变了。以前写代码是研发的专属领地产品、设计、运营只能在外围提需求。现在不一样了——只要能把需求说清楚、把规则定义明白非技术人员也能通过AI智能体深度参与到软件构建中。我见过一个团队的产品经理自己用Harness的意图定义模块写了一份详细的需求规格说明用Markdown示例JSON然后触发AI Agent直接生成了一版可运行的原型前后不到一小时。这在以前要经历需求评审、技术方案设计、排期开发、测试至少一周。团队协作的边界被拓宽了这可能是比“效率提升”更深远的变化。当人人都能“召唤”代码时组织的创新速度会指数级上升。最后也是最根本的——开发者的角色变了。以后的开发者不再是天天埋头写代码的人而更像三种角色的混合体环境设计师搭建适合AI工作的开发环境和工具链包括CI/CD流水线适配、测试数据工厂、mock服务、日志聚合系统让AI能在这个环境里自由驰骋而不破坏生产。意图定义者把模糊的业务需求翻译成AI能理解的精确指令和规则这需要有很强的抽象能力和业务理解力而不是单纯的编码技巧。反馈循环搭建者设计校验机制和纠错路径让AI能自己发现问题、修复问题这本质上是“元编程”——写代码来管理代码的生成过程。至于编码的具体执行交给AI就好了。打个比方以前开发者是厨师自己切菜自己炒菜以后更像餐厅经理——定菜单、控品质、培训后厨具体烹饪工作由智能体厨房来完成。这个转变对很多老程序员来说是挑战因为他们习惯了亲手敲代码的掌控感但也是机遇因为那些重复性劳动被剥离后人的创造力和决策力会被放大到前所未有的程度。五、Harness工程的技术骨架四大组件六层架构深度详解说了这么多“是什么”和“为什么”接下来聊聊“怎么做”。Harness工程到底由什么构成这里我会深入到一些技术细节给真正想落地的朋友一些可操作的参考。四大核心组件扩展版一个完整的Harness体系离不开这四根支柱每一根都有丰富的内部设计。① 意图定义让AI理解项目结构和业务规则不能每次对话都从零开始讲一遍。实践中的做法是把代码仓库作为“唯一真理源”用一个大约100行的AGENTS.md文件做导航索引指向各个模块的结构化文档。再配一个文档维护Agent确保文档和代码同步更新——不然文档是三年前的AI照着写肯定出问题。但意图定义远不止一个导航文件。深度的做法还包括需求规格库用Gherkin语法Given-When-Then编写的用户故事AI可以直接解析成行为驱动开发的测试用例。API契约集OpenAPI/Swagger文件明确每个接口的输入输出、错误码、权限要求。数据字典每个数据实体User、Order、Product等的字段定义、校验规则、关联关系。业务规则引擎把业务逻辑封装成可执行的规则比如“折扣不能超过20%”、“库存不足时自动下架”AI在生成代码时必须引用这些规则而非自己发明。所有这些结构化知识通过RAG检索增强生成方式在AI每次行动前注入上下文。关键是时效性——文档一旦变更索引必须同步刷新否则AI就会基于旧信息决策。我们内部用了一个变更监听器每次合并到主分支的文档变更都会触发重新索引延迟不超过30秒。# AGENTS.md 导航索引示例扩写 1. **用户认证模块** - 描述处理登录、注册、用户资料管理 - 位置/src/modules/auth - 依赖Firebase Auth、React - 关键APIlogin(email, password) → UserToken, register(userData) → User - 异常场景密码错误超过5次锁定账号需captcha验证 2. **仪表盘模块** - 描述展示用户数据分析和控制面板 - 位置/src/modules/dashboard - 依赖Chart.js、React、Redux - 数据源从/api/dashboard/stats获取聚合数据缓存5分钟 3. **支付模块**核心业务 - 位置/src/modules/payment - 依赖Stripe SDK、数据库事务 - 规则订单金额500元需二次确认支付失败自动重试3次间隔2秒② 执行环境AI不能只靠“想”来写代码它得有地方“试”。面向Agent改造的执行环境需要支持独立启动应用实例让Agent自己去复现bug、验证修复。这个环境不是简单的本地沙箱而是一整套镜像基础设施隔离的数据库实例每个Agent会话拥有独立的schema或数据库避免数据污染。模拟外部依赖用WireMock或类似工具模拟第三方API让AI能测试各种异常响应超时、500错误、限流。可观测性埋点每个Agent操作都生成分布式追踪span记录它执行了哪些命令、调用了哪些工具、看到了哪些输出。快速回滚能力每次Agent修改代码前自动创建代码快照和数据库快照一旦验证失败一键回滚到上一个稳定状态。更重要的是要给Agent提供“感官输入”——UI截图、DOM快照、全链路遥测数据。我们给Agent集成了一套轻量级的UI自动化框架当它修改了前端代码后可以自动打开无头浏览器渲染页面截取关键界面并与预期设计稿比对用视觉模型判断差异。后端改动则通过日志聚合和APM数据来验证性能指标。就像给盲人配上眼睛和耳朵它才能在复杂工程里自己找到问题、纠正错误。没有这些输入AI就是在黑暗里摸索写出来的代码能不能跑全靠猜。# 执行环境示例让 Agent 自主复现和验证扩写importsubprocessimporttimefromtypingimportDict,AnyclassAgentEnvironment:def__init__(self,app_path:str,db_uri:str,mock_config:Dict):self.app_pathapp_path self.db_uridb_uri# 隔离的数据库连接self.mock_configmock_config# 第三方mock规则self.processNoneself.snapshot_idNonedefstart_app(self):# 启动应用注入环境变量指向隔离DB和mock服务envos.environ.copy()env[DATABASE_URL]self.db_uri env[MOCK_ENABLED]trueself.processsubprocess.Popen([npm,start],cwdself.app_path,envenv)time.sleep(5)# 等待服务就绪defcapture_snapshot(self):# 创建代码和数据库的快照用于回滚self.snapshot_idfsnap_{int(time.time())}subprocess.run([git,checkpoint,self.snapshot_id],cwdself.app_path)# 数据库快照使用pg_dump或mongoexportreturnself.snapshot_iddefreproduce_bug(self,bug_desc:str):# AI agent 与应用交互复现 bug比如发送特定请求print(f复现 bug:{bug_desc})# 调用内部测试客户端模拟用户操作responsetest_client.post(/api/order,json{product:bug_desc[product]})returnresponse.status_code,response.json()defverify_fix(self,fix_desc:str):# 运行全部单元测试和集成测试并检查性能基线test_resultsubprocess.run([npm,test],cwdself.app_path,capture_outputTrue)coverageself.get_coverage()perfself.get_perf_metrics()return{tests_passed:test_result.returncode0,coverage:coverage,performance:perf}③ 反馈循环深度剖析这是Harness工程的“免疫系统”。核心是分层校验每一层都有不同的时间粒度和故障代价最内层即时校验 100ms格式对不对JSON/YAML语法、语法有没有问题AST解析、API存在不存在静态符号表查找、类型是否匹配TypeScript类型检查。这层完全在内存中完成不涉及外部调用速度极快。一旦失败Agent立即被中断并收到结构化错误反馈。中间层多维反馈1~5分钟单元测试过了吗集成测试挂没挂Lint有没有报错代码风格是否符合规范这一层需要实际运行测试套件耗时稍长但覆盖面广。我们还会引入变异测试——故意在代码中植入一些常见错误如改变边界条件看测试能否发现以此评估测试质量。最外层效能保障10分钟~小时级性能有没有退化对比历史基线安全漏洞有没有引入SAST扫描依赖有没有新增高危版本供应链安全检查资源消耗是否异常内存泄漏检测这一层通常放在CI流水线中异步执行不阻塞Agent的下一步但如果发现问题会触发告警并自动回滚最近的变更。每一层都是一道闸门问题在越内层被发现修复成本越低。我们的统计显示即时校验拦截了约65%的错误中间层拦截了约28%最外层只拦截了7%。但正是那7%往往是最致命的——比如性能滑坡和安全漏洞早期难以感知一旦上线就是大事故。# 反馈循环示例工具调用前后校验扩写defvalidate_tool_call(tool_name:str,input_data:dict,context:dict)-bool:# 第一层格式校验ifnotisinstance(input_data,dict):returnFalse,输入必须是字典# 第二层安全校验——防止命令注入或路径遍历ifpathininput_dataand../ininput_data[path]:returnFalse,非法路径访问# 第三层权限校验——该工具是否允许当前Agent角色调用iftool_namenotincontext[allowed_tools]:returnFalse,f工具{tool_name}未授权# 第四层参数合法性——根据工具定义检查必填字段和值域schemacontext[tool_schemas][tool_name]forfield,rulesinschema.items():ifrules.get(required)andfieldnotininput_data:returnFalse,f缺少必填参数{field}ifenuminrulesandinput_data[field]notinrules[enum]:returnFalse,f参数{field}值不在允许范围returnTrue,校验通过④ 效能保障量化实践说起来有点反直觉要让AI写代码写得好技术栈不能太花哨。选那些训练数据里出现频率高、生态成熟的“低复杂度”技术栈AI对它们更熟悉出错概率低很多。我们内部有一个“技术栈适应性评分”——针对每个框架/库统计它在主流LLM训练数据中的token覆盖率和最新版本的API正确率。比如Python的FastAPI和Django得分很高而一些冷门的纯函数式语言如Elm得分很低。你在选型时就要权衡新技术固然有优势但AI的驾驭成本会直线上升。除了技术栈选择效能保障还包括代码复杂度门禁AI生成的函数圈复杂度不能超过10否则强制要求拆分重构。重复率监控如果AI在多个地方生成相似的代码块提示它提取公共函数。可维护性索引结合注释率、命名规范性、模块耦合度等综合评分低于阈值则触发人工review。知识沉淀每次AI成功修复一个复杂bug我们将修复过程和根因分析写入“经验库”以后遇到类似问题直接检索复用。六大准则与六层架构详细展开落地Harness工程有六个核心准则要守住每一条背后都有大量实战教训上下文架构信息怎么组织、怎么喂给AI。不是一股脑把所有文件都塞进prompt而是根据当前任务类型动态检索最相关的模块文档和代码片段。我们采用向量数据库索引整个代码库每次任务开始时做语义相似度检索只注入top-k个最相关的上下文片段。架构约束不能让AI随便改核心代码。核心模块如鉴权、数据库连接池、核心业务实体要有保护在AGENTS.md中明确标记为“只读”或“需人工审批”AI如果尝试修改会被拦截并引导它提供修改建议而非直接执行。自验证循环自己写的代码自己测写完就跑测试。我们强制要求AI在提交任何代码变更前必须运行至少一个相关的测试用例并通过。如果AI无法写出测试它会被要求先写测试再写实现——TDD测试驱动开发被强制嵌入Harness。上下文隔离不同任务互不干扰避免串味。每个Agent会话有独立的临时分支和沙箱环境任务完成后合并到主线。如果多个Agent同时修改同一文件我们借鉴Git的冲突检测机制在合并时由AI辅助解决冲突。熵治理防止代码库越改越乱。我们定期运行代码健康度扫描如果发现技术债指标持续恶化如循环依赖增多、抽象层次混乱会触发一个“重构Agent”专门负责清理保持代码库整洁。可拆卸设计出问题能快速回退不能一崩全崩。所有AI生成的变更都以PR形式提交且每个PR的每个commit都对应一个可独立回滚的功能点一旦发现问题可以精确回滚到任意历史状态。具体实现上是六层架构从下到上分别是┌─────────────────────────────────────┐ │ ⑥ 观测与评估体系 干得好不好 │ 这一层负责收集所有指标、生成报告、提供可视化仪表盘让团队对AI的贡献和风险一目了然。 ├─────────────────────────────────────┤ │ ⑤ 约束与恢复机制 出问题怎么办 │ 当错误发生时自动触发回滚、降级或人工介入流程有完整的应急预案。 ├─────────────────────────────────────┤ │ ④ 验证钩子 对不对 │ 即前文的多层校验每个工具调用和代码产出都经过严格验证。 ├─────────────────────────────────────┤ │ ③ 记忆与状态管理 记住了什么 │ 维护跨会话的长期记忆经验库、技术决策记录和短期状态当前任务进度、已修改文件列表。 ├─────────────────────────────────────┤ │ ② 执行编排 怎么干活 │ 负责任务拆解、工具分配、执行顺序调度类似一个AI的“操作系统调度器”。 ├─────────────────────────────────────┤ │ ① 信息边界与工具规范知道什么、能用什么│ 明确AI能访问哪些文件、调用哪些API、使用哪些外部服务所有工具的schema和权限都在这层定义。 └─────────────────────────────────────┘底层管“AI知道什么、能用什么”中间管“AI怎么干活、怎么记东西”上层管“干得对不对、出问题怎么办、怎么知道效果好不好”。这六层叠在一起才构成了Harness工程的完整技术骨架。每一层都可以独立迭代优化比如你发现验证钩子漏掉了某种错误可以单独加强第四层而不影响其他层。六、落地的坑四个绕不开的现实问题血泪经验前面讲的都是理想状态。真正落到实际项目里麻烦事不少。下面这四个问题是小马这段时间实战下来感触最深的几乎所有尝试Harness工程的团队都会碰到。1. 存量项目怎么接入Harness新项目可以从零开始搭但已有的存量项目怎么办架构复杂、文档缺失、技术债一堆——这都是现实。我们团队接手的是一个有六年历史的后端系统光Java代码就有50万行服务间调用关系像蜘蛛网一样复杂。一开始想全量引入Harness结果Agent光理解代码结构就花了半天生成的第一个PR直接导致集成测试大面积失败。小马的经验是先建地图再逐步套壳。第一步不是上来就让AI写代码而是先做代码和业务的梳理。用分析工具如jQAssistant、SonarQube的依赖图把代码结构、依赖关系摸清楚建一个“检索地图”让AI至少能看懂项目长什么样。同时从规则和记忆入手把缺失的文档和规范慢慢补起来。我们专门安排了一个实习生花了两周时间把各个模块的职责、关键接口、数据流向整理成文档并编写了对应的AGENTS.md索引。这个过程虽然辛苦但本身就是一次很好的知识沉淀。然后用渐进式策略优先挑核心业务和高频变更的模块下手——这些模块改得多、价值也大先把单个模块的Harness搭起来、跑通、验证效果再逐步扩大范围。比如我们第一个试点是“用户通知服务”——负责发送邮件和短信业务逻辑相对独立变更频繁。仅针对这个模块配置了完整的意图定义、执行环境和验证钩子运行了两周效果不错再推广到订单服务和支付服务。一上来就想整个项目全覆盖大概率会翻车。2. 多人协作怎么搞Harness不是一个人的玩具真实环境里都是团队一起用。多人用一个Harness框架权限怎么分任务怎么拆代码怎么合一个思路是权限分层。把Harness里的共享资产——规则、技能、钩子配置、manifest文件——按权限等级管理。高级别的人架构师、Tech Lead才能改核心规则普通开发者主要在业务代码层面操作而新人可能只被允许在隔离的沙箱里实验性使用。这样既保证了框架的稳定性又不影响日常开发效率。我们采用RBAC模型将Harness配置文件和代码仓库的权限绑定同一个Git分支的保护规则也同步应用到Harness操作。另一个关键是环境隔离和任务解耦。每个人有自己的独立开发环境基于容器化互不干扰任务完成后再合并到主环境。每个任务都拆解成原子性的用户故事每个故事对应一个独立分支。任务拆解得越干净代码冲突越少。某种程度上这和微服务的思路是通的——把大系统拆成小模块各管各的通过接口交互。我们在任务拆解阶段专门安排了一个“Harness 规划师”角色由资深开发担任负责将大的需求拆成AI能独立完成的子任务并排定依赖顺序。3. Harness是开箱即用的吗很多人刚接触的时候会问“有没有现成的Harness框架我拿来装一下就能用”真实答案是不是而且差得远。Harness不是一个产品而是一个持续收紧、不断演进的过程。每个项目的业务需求、技术架构、团队成熟度都不一样没有放之四海而皆准的方案。金融项目和社交项目对安全和性能的要求天差地别它们的Harness框架自然也会长得不一样。比如金融项目要求所有AI生成的代码必须经过静态安全分析和模糊测试而社交项目可能更关注UI的响应速度和A/B测试能力。规则和约束不是一次性定死的而是随着业务发展、团队壮大逐步加严。项目初期可能只要基本语法规范到了后期就得加上代码复杂度分析、覆盖率检查、安全扫描等等。我们的经验是每个季度review一次Harness配置根据过去三个月的故障回顾和效率数据调整各层校验的阈值和规则。比如发现最近API幻觉问题增多就加强“即时校验”中的API存在性检查发现性能退化频繁就调低效能保障层的性能退化容忍度。指望买一个Harness工具然后就万事大吉是不现实的。它更像一套方法论需要结合具体项目慢慢打磨。市面上有些所谓的“Harness平台”其实只是提供了脚手架和可视化配置界面核心的规则编写、测试适配、异常场景覆盖还得团队自己来。4. 非研发人员怎么参与Harness降低了编程门槛但产品经理、测试人员这些非研发角色具体怎么和AI智能体协作一种模式是**“双轨制”**——研发有研发的仓库分支和规则分支非研发有自己的分支。研发在开发分支上写代码、改规则非研发在自己的分支上写需求文档、设计测试用例两边在关键节点上同步对齐。产品经理可以直接在自己的分支上更新需求AI智能体根据最新需求调整开发方向减少了大量中间传话的损耗。我们曾有一个需求变更以前要经过产品→开发→测试来回三四天现在产品在分支上修改需求文档触发Harness的变更监听AI自动感知并重新生成对应的实现和测试整个流程压缩到半天以内。还有一种更彻底的方式仓库脱离规则共享。非研发人员有自己独立的仓库和工作流程不用碰研发的代码库但底层的Harness规则是共享的。比如测试团队维护自己的测试用例仓库用Cucumber或类似框架AI根据研发的代码变更自动拉取对应的测试用例跑一遍结果反馈给两边。两边的仓库在物理上是分开的但通过Harness的规则体系连在了一起——规则里定义了哪个测试套件对应哪个模块变更时自动触发关联测试。这些模式目前都还在探索中没有标准答案。但方向是明确的软件开发不再只是工程师的事越来越多角色会参与进来。我们甚至尝试让UI设计师通过上传Figma设计稿Harness自动解析成前端组件的布局代码设计师不需要写一行CSS就能看到可交互的页面原型。七、写在最后深度展望聊到这里有几个问题其实一直萦绕着小马。你手头的项目现在有没有引入Harness如果有效果怎么样是真的提升了效率还是只是多了个“高级Copilot”的噱头这个问题的答案决定了Harness工程到底是下一个大趋势还是又一轮技术泡沫。从我看到的趋势来说Harness的落地效果取决于投入的深度——浅尝辄止的团队往往只得到10%20%的效率提升而深度定制、持续优化的团队能获得50%80%的显著改善。关键在于是否把Harness当成一项战略性投资而非临时工具。开发者该怎么选市面上已经有DeepSeek Harness、CodeX Harness这些工具了还有更多正在冒出来。选哪个、怎么落地、投入多少资源——这些决策没有标准答案只能靠团队自己摸索。我的建议是先拿一个非核心但真实的小项目做PoC概念验证跑通全流程评估投入产出比再决定是否大范围推广。不要一上来就被厂商的宣传牵着走要结合自己团队的技能栈和业务痛点来定制。还有一个更大的问题Harness的边界在哪里现在大家讨论的都是软件开发但这套方法论——给AI建约束、做验证、搭反馈循环——能不能用到别的地方自动化运维让AI自主修复线上故障但要限制它不能重启关键服务、智能客服AI回答客户问题但需要校验合规性和情绪语气、数据分析AI生成SQL查询但必须经过成本预估和权限审查、甚至设计和内容创作AI生成图片和文案但要符合品牌指南和版权规则——只要有AI智能体参与的场景似乎都需要某种形式的“Harness”。我甚至设想过一个“通用Harness框架”抽象出约束定义、验证钩子、反馈循环等核心组件适配不同领域的AI应用那将是一个基础设施级别的产品。如果真是这样那Harness工程的意义就远不止“改变软件开发”这么简单了。它可能是我们学会和高能AI共处的第一套系统性方法——怎么让强大但不稳定的智能体在人类设定的轨道上稳定地干活、持续地产出价值。它关乎信任——我们信任AI的输出不是因为AI不会错而是因为我们有能力检测和纠正它的错误。这种“信任但验证”的关系可能是未来人机协作的主旋律。这件事刚刚开始。未来几年我们会看到更多实践、更多踩坑、也更多真正跑通的案例。作为开发者与其焦虑“AI会不会取代我”不如早点琢磨怎么当那个“搭Harness的人”——毕竟厨房里的智能体再多总得有人来当经理吧。而且这个经理的角色比现在的工程师更有趣、更有挑战性——你需要懂业务、懂架构、懂AI的脾气、懂工程化的约束设计还要有很好的沟通能力来协调各方。这是一个复合型角色的崛起值得我们为之准备。最后我还想提一下成本问题。Harness工程不是免费的——模型调用费用、额外的算力用于验证和对抗、环境维护成本、人力投入配置规则、维护文档、设计评测集都不低。但相对于它带来的效率提升和质量保障大部分团队在规模到达一定级别后都会是净收益。小团队可以走轻量化路线用开源模型简化版的验证钩子先跑起来再慢慢加厚。一斤代码二两酒码路漫漫咱们边走边看。希望这篇文章能给你一些启发也希望未来能看到更多国产Harness实践的分享——毕竟中文语境下的业务逻辑和代码库有自己独特的复杂性这方面的本土经验尤为宝贵。