概述

本文由Kief Morris撰写，发表于Martin Fowler的网站，探讨了在生成式AI时代人类工程师应该如何定位自己与AI Agent的关系。文章提出了一个核心框架：人类应该处于"on the loop"（在循环之上），而非"in the loop"（在循环之中）或完全脱离循环。作者区分了"Why Loop"（从想法到软件的战略循环）和"How Loop"（构建产物的执行循环），并提出了"Harness Engineering"（驾驭工程）的概念——通过构建规范和检查机制，让Agent能够自我纠正，最终形成持续改进的"Agentic Flywheel"（Agent飞轮）。

详细内容

核心概念：三种人机协作模式

模式对比

模式	英文表述	人类角色	Agent角色	适用场景
在循环之中	In the loop	手动审查每个输出	辅助生成	高风险、关键系统
在循环之上	On the loop	管理流程和规范	自主执行	大多数开发工作
脱离循环	Out of the loop	完全不参与	全权负责	低风险、标准化任务
氛围编程	Vibe coding	描述意图	完全自主	原型、个人项目

可视化理解

In the Loop（在循环之中）:
人类 → Agent → 输出 → [人类审查] → 使用
              ↑_______________|

On the Loop（在循环之上）:
人类制定规范 → Agent执行 → 自动检查 → 通过/反馈
      ↑________________________________|

Out of the Loop（脱离循环）:
人类设定目标 → [Agent全权处理] → 结果

Vibe Coding（氛围编程）:
人类描述氛围 → Agent生成 → 即时反馈 → 迭代

Why Loop vs How Loop

两个层次的循环

Why Loop（为什么循环）——战略层：

起点：业务需求、用户问题、市场机会
终点：可工作的软件解决方案
核心问题："我们为什么要构建这个？"
关键决策：功能范围、架构方向、技术选型

How Loop（如何循环）——执行层：

起点：确定要构建的功能
终点：具体的代码产物
核心问题："我们如何构建这个？"
关键决策：实现细节、代码结构、算法选择

传统开发 vs AI辅助开发

传统开发：

人类同时主导Why Loop和How Loop
从需求到代码的转换完全由人类完成
迭代速度受限于人类编码速度

AI辅助开发：

人类主导Why Loop（战略决策）
Agent主导How Loop（执行实现）
人类通过规范和检查来"驾驭"Agent

氛围编程（Vibe Coding）的局限

什么是Vibe Coding

"氛围编程"是指人类通过描述"氛围"或"感觉"来让AI生成代码，而不关注具体实现细节。

典型场景：

"给我做一个复古风格的任务管理应用"
"让这个页面感觉更现代、更流畅"
"添加一些有趣的动画效果"

为什么不适合专业开发

氛围编程	专业开发需求
关注感觉和外观	需要精确的功能实现
迭代基于视觉反馈	需要满足严格的业务逻辑
个人项目适用	团队协作需要一致性
快速原型	长期维护需要可预测性

核心问题

氛围编程将How Loop完全交给Agent，但：

缺乏可重复性
难以调试和维护
无法保证质量一致性
不适合团队协作

Harness Engineering：驾驭工程

核心理念

Harness Engineering（驾驭工程）是指构建规范和检查机制，使Agent能够在How Loop中自我纠正。

关键要素

1. 规范（Specifications）

明确告诉Agent应该做什么：

功能需求文档
API契约定义
架构约束
编码规范

示例：

## 用户认证模块规范

### 功能要求
- 支持邮箱/密码登录
- 密码必须加密存储（bcrypt）
- 登录失败3次后锁定账户15分钟

### 技术约束
- 使用JWT进行会话管理
- Token有效期24小时
- 刷新Token有效期7天

### 安全要求
- 所有密码传输必须使用HTTPS
- 实现CSRF保护
- 记录所有登录尝试日志

2. 检查（Checks）

验证Agent的输出是否符合规范：

自动化测试
静态代码分析
安全扫描
性能基准测试

检查层次：

Level 1: 语法检查（编译/解析）
Level 2: 风格检查（Linting）
Level 3: 单元测试
Level 4: 集成测试
Level 5: 安全扫描
Level 6: 性能测试
Level 7: 人工审查（关键变更）

3. 反馈循环

当检查失败时，Agent应该能够：

理解失败原因
自动修复问题
重新提交验证

Agentic Flywheel：Agent飞轮

概念定义

Agentic Flywheel 是一个自我强化的系统，其中Agent不仅执行代码，还改进自己的工作流程。

飞轮运转机制

        ┌─────────────────────────────────────┐
        │                                     │
        ▼                                     │
┌───────────────┐    ┌───────────────┐    ┌──────────┐
│ 人类定义规范   │───▶│ Agent执行代码  │───▶│ 自动检查  │
└───────────────┘    └───────────────┘    └────┬─────┘
                                               │
                    ┌──────────────────────────┘
                    │
                    ▼
        ┌───────────────────┐
        │ 检查通过？         │
        └─────────┬─────────┘
                  │
        ┌─────────┴─────────┐
        │                   │
        ▼                   ▼
┌───────────────┐    ┌───────────────┐
│ 部署/交付      │    │ Agent自我纠正  │
└───────────────┘    └───────┬───────┘
                             │
                             └──────────────┐
                                             │
        ┌────────────────────────────────────┘
        │
        ▼
┌─────────────────────────────────────┐
│ 流程改进：Agent学习失败模式，        │
│ 更新内部策略以避免重复错误           │
└─────────────────────────────────────┘

飞轮的三个阶段

阶段1：执行（Execution）

Agent根据规范生成代码
自动化检查验证输出
人类监督但不介入每个细节

阶段2：纠正（Correction）

当检查失败时，Agent自动修复
学习失败模式
更新生成策略

阶段3：进化（Evolution）

Agent分析常见失败模式
建议改进规范或检查
优化整个工作流程

实践建议

对于个人开发者

1. 从规范开始

不要直接让Agent写代码
先花时间明确需求和约束
将规范作为与Agent的"契约"

2. 建立检查清单

为每个项目定义最低质量标准
使用自动化工具执行检查
逐步增加检查覆盖率

3. 保持人类判断

在关键决策点保留人类审查
不盲目接受Agent的所有输出
定期回顾和优化规范

对于团队

1. 标准化规范格式

建立团队级的规范模板
使用结构化格式（如YAML frontmatter）
版本控制规范文档

2. 共享检查配置

统一的Lint规则
共享的测试框架和基准
团队级的安全检查清单

3. 建立反馈机制

记录Agent的常见错误
更新规范以避免重复问题
分享有效的Prompt模式

对于组织

1. 投资于工具链

自动化检查基础设施
Agent友好的CI/CD流程
规范管理和版本控制工具

2. 培养Harness Engineering能力

培训工程师编写有效规范
建立检查即代码（Checks as Code）的文化
奖励规范和检查的贡献

3. 渐进式采用

从低风险项目开始
逐步扩大Agent自主范围
持续评估和调整策略

与其他方法的对比

vs 传统软件开发

维度	传统开发	Harness Engineering
人类角色	编码+审查	规范+监督
迭代速度	慢（人类编码）	快（Agent编码）
一致性	依赖个人习惯	依赖规范执行
可扩展性	受限于团队规模	可自动化扩展

vs 完全自动化（Out of the Loop）

维度	完全自动化	On the Loop
人类参与	无	规范和监督
适用场景	标准化任务	复杂创新工作
风险	高（无监督）	可控（有检查）
灵活性	低	高

vs 氛围编程（Vibe Coding）

维度	Vibe Coding	Harness Engineering
规范明确性	模糊	精确
质量保证	无	有检查机制
可维护性	低	高
适用场景	原型/个人项目	生产系统

核心洞察

人类的独特价值

在Agentic时代，人类工程师的价值不在于编写代码，而在于：

问题定义：识别真正需要解决的问题
价值判断：决定什么是重要的，什么是可以妥协的
系统设计：定义架构和接口
质量把控：建立和维护质量标准
持续改进：优化整个开发流程

Agent的独特价值

Agent在以下方面超越人类：

执行速度：快速生成大量代码
知识广度：掌握多种语言和框架
不知疲倦：可以持续迭代和修正
一致性：严格遵循规范（如果规范清晰）
模式识别：从大量失败中学习

协作的本质

"最好的结果来自于人类和Agent各自发挥所长，通过明确的规范和检查机制形成协作。"

这不是人类 vs Agent，而是：

人类负责战略（Why）
Agent负责执行（How）
规范负责对齐（Alignment）
检查负责质量保证（Quality）

观点存疑

"On the Loop"是否过于理想化？
- 实践中，定义完美的规范可能比直接写代码更难
- 规范的维护成本可能很高，特别是在需求频繁变化的项目中
- 需要验证这种模式的实际效率是否真的高于传统方法
检查机制的全面性存疑
- 自动化检查能否真正捕获所有重要问题？
- 某些质量问题（如代码可读性、架构合理性）可能难以自动化检查
- 过度依赖检查可能导致"检查通过但质量低下"的情况
对Agent自我纠正能力的假设
- 当前Agent在理解复杂错误和自动修复方面的能力有限
- "Agentic Flywheel"的自我进化能力可能被过度夸大
- 需要更多实际案例来验证这一概念的可行性
忽视了团队协作的复杂性
- 文章主要关注个人与Agent的协作
- 在多团队成员、多Agent的场景下，规范和检查的协调更加复杂
- 冲突解决和责任归属问题未被充分讨论
规范编写的技能要求
- 编写有效的规范本身就是一种高级技能
- 可能需要比编码更强的抽象和沟通能力
- 团队中的初级工程师可能难以胜任这一角色
与现有开发流程的整合
- 如何将Harness Engineering融入现有的敏捷/Scrum流程？
- 估算、规划、回顾等传统活动如何调整？
- 需要更多关于组织变革管理的指导
Agent能力的快速发展
- 如果Agent能力继续快速提升，"On the Loop"的边界可能需要不断调整
- 今天的"需要人类监督"的任务，明天可能完全自动化
- 这种动态变化给策略制定带来挑战

软件工程中的人类与Agent（读书笔记）

概述