AI编程进化史：从补全到Harness，智能体时代我们如何驾驭代码

大家好，我是小马过河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
   - 关键API：login(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 自主复现和验证（扩写）
import subprocess
import time
from typing import Dict, Any

class AgentEnvironment:
    def __init__(self, app_path: str, db_uri: str, mock_config: Dict):
        self.app_path = app_path
        self.db_uri = db_uri  # 隔离的数据库连接
        self.mock_config = mock_config  # 第三方mock规则
        self.process = None
        self.snapshot_id = None

    def start_app(self):
        # 启动应用，注入环境变量指向隔离DB和mock服务
        env = os.environ.copy()
        env["DATABASE_URL"] = self.db_uri
        env["MOCK_ENABLED"] = "true"
        self.process = subprocess.Popen(["npm", "start"], cwd=self.app_path, env=env)
        time.sleep(5)  # 等待服务就绪

    def capture_snapshot(self):
        # 创建代码和数据库的快照，用于回滚
        self.snapshot_id = f"snap_{int(time.time())}"
        subprocess.run(["git", "checkpoint", self.snapshot_id], cwd=self.app_path)
        # 数据库快照使用pg_dump或mongoexport
        return self.snapshot_id

    def reproduce_bug(self, bug_desc: str):
        # AI agent 与应用交互，复现 bug，比如发送特定请求
        print(f"复现 bug: {bug_desc}")
        # 调用内部测试客户端模拟用户操作
        response = test_client.post("/api/order", json={"product": bug_desc["product"]})
        return response.status_code, response.json()

    def verify_fix(self, fix_desc: str):
        # 运行全部单元测试和集成测试，并检查性能基线
        test_result = subprocess.run(["npm", "test"], cwd=self.app_path, capture_output=True)
        coverage = self.get_coverage()
        perf = self.get_perf_metrics()
        return {
            "tests_passed": test_result.returncode == 0,
            "coverage": coverage,
            "performance": perf
        }

③ 反馈循环（深度剖析）

这是Harness工程的“免疫系统”。核心是分层校验，每一层都有不同的时间粒度和故障代价：

• 最内层：即时校验（< 100ms）
  格式对不对（JSON/YAML语法）、语法有没有问题（AST解析）、API存在不存在（静态符号表查找）、类型是否匹配（TypeScript类型检查）。这层完全在内存中完成，不涉及外部调用，速度极快。一旦失败，Agent立即被中断并收到结构化错误反馈。

• 中间层：多维反馈（1~5分钟）
  单元测试过了吗？集成测试挂没挂？Lint有没有报错？代码风格是否符合规范？这一层需要实际运行测试套件，耗时稍长，但覆盖面广。我们还会引入变异测试——故意在代码中植入一些常见错误（如改变边界条件），看测试能否发现，以此评估测试质量。

• 最外层：效能保障（10分钟~小时级）
  性能有没有退化（对比历史基线）？安全漏洞有没有引入（SAST扫描）？依赖有没有新增高危版本（供应链安全检查）？资源消耗是否异常（内存泄漏检测）？这一层通常放在CI流水线中异步执行，不阻塞Agent的下一步，但如果发现问题会触发告警并自动回滚最近的变更。

每一层都是一道闸门，问题在越内层被发现，修复成本越低。我们的统计显示，即时校验拦截了约65%的错误，中间层拦截了约28%，最外层只拦截了7%。但正是那7%，往往是最致命的——比如性能滑坡和安全漏洞，早期难以感知，一旦上线就是大事故。

# 反馈循环示例：工具调用前后校验（扩写）
def validate_tool_call(tool_name: str, input_data: dict, context: dict) -> bool:
    # 第一层：格式校验
    if not isinstance(input_data, dict):
        return False, "输入必须是字典"
    # 第二层：安全校验——防止命令注入或路径遍历
    if "path" in input_data and "../" in input_data["path"]:
        return False, "非法路径访问"
    # 第三层：权限校验——该工具是否允许当前Agent角色调用
    if tool_name not in context["allowed_tools"]:
        return False, f"工具{tool_name}未授权"
    # 第四层：参数合法性——根据工具定义检查必填字段和值域
    schema = context["tool_schemas"][tool_name]
    for field, rules in schema.items():
        if rules.get("required") and field not in input_data:
            return False, f"缺少必填参数{field}"
        if "enum" in rules and input_data[field] not in rules["enum"]:
            return False, f"参数{field}值不在允许范围"
    return True, "校验通过"

④ 效能保障（量化实践）

说起来有点反直觉：要让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实践的分享——毕竟中文语境下的业务逻辑和代码库有自己独特的复杂性，这方面的本土经验尤为宝贵。