---
title: Harness Engineering：AI 能在真正"出事会炸"的后端系统里写代码吗？
source_url: https://mp.weixin.qq.com/s/VJgVPeJ5GZhVwbRtneEk_Q
publish_date: 2026-04-28
tags: [wechat, article, openai, agent, harness, coding]
review_value: 7
review_confidence: 7
review_recommendation: neutral
sha256: 8142956d7f58b4d4ae7476bc44bbcd2ab2d757d1572248156221023f821fea08
---
# Harness Engineering：AI 能在真正"出事会炸"的后端系统里写代码吗？
原创 腾讯程序员 腾讯技术工程
2026年4月21日 18:26 广东
作者：lancelotluo
## 引言
当 AI Coding 的聚光灯几乎全部打在前端和客户端——生成一个页面、写一个 App......的时候，一个重要的问题却似乎被回避了：AI 能在真正"出事会炸"的后端系统里写代码吗？
腾讯CDN LEGO项目就是这样一个系统。100万行核心代码、300万行深度改造的第三方库，服务亿级用户，承担流量调度、协议解析、安全防护、缓存加速等关键职责。它面对的不是确定性的输入输出，而是不可控的客户端、不可控的源站、多协议、多配置、公网全量攻击面——这些因素维度的叠加不是简单相加，而是乘积式的复杂度爆炸，理论组合路径高达 13,824 × N 种。在这样的复杂的系统里让 AI 写代码，一行失误就可能是一场全网事故。
但正因为难，才值得做。 我们系统性地探索了 AI Coding 在高风险后端场景的落地路径：一方面，用 AI 零人工代码实现了一个 Rust 版 Nonstop 代理框架，以此探测 AI 编码的能力边界与行为特性；另一方面，在超大规模 C++ LEGO项目中构建了 Harness Engineering 五层架构和多模型对抗式CR，为 AI 产出的每一行代码建立从生成到上线的完整质量屏障。
## 一、背景与挑战
### 1.1 项目规模与复杂性
LEGO系统作为腾讯CDN的核心接入层，承载着腾讯几乎所有CDN和EdgeOne业务流量的大型分布式系统：
- 代码规模：核心代码超过100万行，多线程全异步非阻塞架构
- 第三方依赖：深度改造第三方库超过300万行（包括OpenSSL、QUIC、LUA、JavaScript等）
- 服务规模：每天处理的请求量以万亿计，亿级用户
### 1.2 开发和运营痛点
**不可控因素众多：**
- 客户端：浏览器、App、爬虫、攻击工具，涵盖数十亿设备和数百种实现
- 源站：客户自建、云存储、第三方API，涉及数百万域名和各种行为
- 协议支持：HTTP/1.1、HTTP/2、HTTP/3/QUIC、WebSocket、TLS等多协议并存
**维度组合复杂性（13,824 × N 种）：**
| 维度 | 数量 | 说明 |
|------|------|------|
| 请求协议 | 3种 | HTTP/1.1, HTTP/2, HTTP/3 |
| 回源协议 | 2种 | HTTP/1.1, HTTP/2 |
| TLS版本 | 4种 | 不同版本的TLS协议 |
| 缓存状态 | 4种 | 不同的缓存策略 |
| 域名配置 | 百万种 | 不同客户的域名配置 |
| 脚本逻辑 | 4种 | 不同的脚本处理逻辑 |
| 安全规则 | 4种 | 不同的安全策略 |
| 源站行为 | 5种 | 不同源站的响应行为 |
| 客户端行为 | 3种 | 不同客户端的请求模式 |
## 二、Nonstop项目：20天AI零人工代码开发Rust代理框架
用20天实现AI Rust零人工代码开发nonstop代理框架项目，探测AI编码的能力边界与行为特性。
**核心特性：**
- 功能全面：支持L4/L7代理
- 协议先进：支持HTTP/3和QUIC协议
- 安全防护：内置WAF纵深防御机制
- 边缘计算：集成V8 JavaScript引擎，支持JS Workers边缘计算能力
- 部署便捷：单二进制部署，零停机热加载
**nonstop项目成果数据：**
- 20天内由1人+AI开发团队完成
- 实测：42,052 QPS / 5000并发 0错误 / P50延迟 1.1ms / 6层纵深防御
## 三、AI Coding在大型项目里为什么容易翻车？
### 3.1 13类典型问题（基于57个真实案例）
| 序号 | 问题类型 | 严重程度 | 来源 |
|------|----------|----------|------|
| 1 | 异步语义误用（blocking send in tokio） | Critical | nonstop |
| 2 | 幻觉（调用/配置不存在的API） | High | 两项目 |
| 3 | 改不全（insert无cleanup） | High | 两项目 |
| 4 | 配置与实现脱节 | High | nonstop |
| 5 | 安全盲区（时序攻击/SSRF/JWT） | Critical | nonstop |
| 6 | 测试Flaky（平台差异） | Medium | nonstop |
| 7 | 内存泄漏（DashMap只增不减） | Critical | nonstop |
| 8 | 协议实现不完整 | Critical | nonstop |
| 9 | 底层未读就改上层 | High | LEGO |
| 10 | 源码分析替代实测 | High | LEGO |
| 11 | 大文件编辑损坏 | Medium | nonstop |
| 12 | 环境盲区 | Medium | LEGO |
| 13 | 不会说"我不知道" | 最高 | LEGO |
### 3.2 5大根因
- **不会说"我不知道"**：AI用自信的语气输出错误结论，反而降低人的审查意愿
- **幻觉**：编造函数签名、编造RFC章节号、编造百分比数据
- **改不全**：局部修改，遗忘全局影响
- **模式匹配代替验证**：代码相似就推断行为相同，跳过实测
- **缺乏环境意识**：不区分容器/宿主机，不查配置直接猜
根本原因：AI缺乏"不确定性意识"和"全局视野"。
## 四、LEGO AI Coding实践：Harness Engineering五层架构
### 4.1 核心理念
将AI尽量harness在单个模块、单个文件、单个函数内实现。
核心三要素：**上下文、约束和反馈**。
### 4.2 五层架构
围绕"上下文、约束和反馈"三大核心要素构建：
- 工程体系才是核心资产，而不是某个模型或prompt
## 五、三大实践抓手
### 5.1 上下文建设——消除AI的"记忆偏差"
**四层递进的上下文体系：**
1. **Agent.md（项目宪法）**：项目结构即上下文，架构模式即约束，内联反馈注释
2. **安全纪律**：用"反例免疫"替代"正面说教"，每条规则都有错误写法和正确写法
3. **领域知识（可复用模式库）**：CR检查清单来自真实问题且经过A/B验证
4. **专业Skill**：覆盖友商实现、协议RFC、开源代码等领域知识
**技术决策三问：**
1. RFC怎么说？（标准规范）
2. 业界怎么做？（最佳实践）
3. LEGO有什么差别？（定制化需求）
**Agent团队：**
- 竞品调研Agent团队：并行调研多个竞品
- 协议安全测试Agent团队：专注安全防护深度验证
### 5.2 约束——用结构化约束替代语言化期望
**三层约束架构：**
- Layer 1：权限安全基座
- Layer 2：代码规则即编译器
- Layer 3：流程约束——测试不可跳过（功能实现→单元测试→代码审查，严格阻塞顺序）
**五条核心约束：**
| 序号 | 约束 | 踩坑来源 |
|------|------|----------|
| 1 | 单项目调研：每次只调研一个竞品 | 多竞品混合分析时C和C++代码模式互相干扰 |
| 2 | 严禁网络操作 | AI联网搜索时返回的竞品信息可能过时或不准确 |
| 3 | 本地不存在则跳过 | 无源码时AI用训练数据编造了"源码分析" |
| 4 | 不修改lego_server代码 | 职责隔离：调研Agent不能有副作用 |
| 5 | 严格搜索范围 | 防止Agent在系统目录或LEGO目录中搜索污染分析结果 |
### 5.3 反馈——踩坑→规则→Skill的进化闭环
**三条并行反馈通道：**
- 通道1：自动采集（Hook）
- 通道2：踩坑日志（Pitfall Journal）
- 通道3：**.md内联反馈
**进化闭环示例：**
- PIT-001 (mmap nullptr→SIGSEGV) → 写入R2规则 → AI自动使用MAP_FAILED
- 问题9 (未读底层就改上层) → Pattern #8 → A/B验证显著 → 保留
**多模型多Agent对抗式CR：**
单模型CR的三个盲区：
- 知识盲区：每个模型的训练数据不同
- 注意力盲区：500+行diff时后半部分审查质量下降
- 确认偏差：发现一个问题后倾向于沿同一方向继续找
对抗式CR核心思想：
- 模型A独立审查 → 发现问题集{a1, a2, a3}
- 模型B独立审查 → 发现问题集{b1, b2, a2}
- 模型C独立审查 → 发现问题集{c1, a1, b1}
- 交叉验证：a2被A和B同时发现 → 高置信度
**对抗式CR vs 业界对比：**
| 维度 | GitHub Copilot CR | OpenAI Codex Review | LEGO对抗式CR |
|------|-------------------|---------------------|--------------|
| 模型数 | 1 | 1-2 | 3 |
| 执行方式 | 串行单次 | 串行两次 | 并行+交叉迭代 |
| 交互方式 | 静态扫描 | 静态扫描 | 辩论式（同意/反对/维持） |
| 收敛机制 | 无（一次性） | 固定轮数 | 全员无新发现自动收敛 |
## 六、阶段性收益
- **综合效率提升20%**（含Review成本与学习曲线）
- 竞品调研：3人天→1天（~3x）
- 方案设计：2-3人天→1天（~2x）
- 协议安全测试：3-5人天→1天（~4x）
- 代码审查：等待1-3天→30分钟
- cpplint通过率：>95%
- CVE防护覆盖：100%
**知识资产：** 86,422行代码、31个Skill、34条踩坑规则、4竞品并行调研、3组A/B实验
## 七、发现的问题
- 误报率36%：9个代码问题中真实P0仅1个
- 文档爆炸：8个需求生成99个文件，人难以全部确认
- AI的"自信"会传染：格式工整的文档反而降低审查意愿
- 团队能力退化风险：AI用多了，工程师的专业和文档能力可能下滑
## 八、AI Coding时代——后台开发的角色演变
**角色重新定义：**
- 初级开发 → 驾驭AI写代码的操作员
- 高级开发 → Harness工程师，核心工作是设计AI的约束、上下文与规则
- 架构师 → 重心从系统设计转向人机协作架构
- 测试/安全工程师 → AI质量工程师与AI安全专家
**能力转型四维度：**
1. 写代码 → 写约束
2. 解决问题 → 防止问题
3. 个人深度 → 知识表达
4. 全栈开发 → 人机协作
**团队建设渐进路径：**
- 第1-2月（会用）：全员掌握全流程、对抗式CR和14条安全规则
- 第2-4月（会建）：骨干编写团队专属Skill，通过A/B实验验证效果
- 第4-12月（会进化）：推动Harness自动化，跨团队知识共享