Harness Engineering 技术原理（二）：Feedforward、Feedback 与六层架构详解
深入讲解Harness的两大控制机制：Feedforward（引导）和Feedback（反馈）。详解六层架构每一层的职责、ReAct循环原理、以及最重要的40%上下文阈值管理策略。
约 15 分钟阅读4,245 字117 次阅读博主
深入讲解Harness的两大控制机制：Feedforward（引导）和Feedback（反馈）。详解六层架构每一层的职责、ReAct循环原理、以及最重要的40%上下文阈值管理策略。
📚 本系列目录：《Harness Engineering》 当前第 4/10 篇 · 上一篇：Harness Engineering 入门（一）：为什么说"你不是模型，那你就是 Harness" · 下一篇：Harness Engineering 架构设计（三）：记忆系统、工具设计与沙箱隔离
《Harness Engineering》共 10 篇，本篇是第 4 篇。
← 上一篇：Harness Engineering 入门（一）：为什么说"你不是模型，那你就是 Harness"
下一篇：Harness Engineering 架构设计（三）：记忆系统、工具设计与沙箱隔离 →
第一篇我们建立了核心认知：Agent = Model + Harness，模型决定上限，Harness 决定底线。
这一篇来深入技术原理——Harness 是如何通过**引导（Feedforward）和反馈（Feedback）**两大机制来控制 Agent 行为的？六层架构每层解决什么问题？ReAct 循环是怎么运转的？
Martin Fowler 在深度分析中提出了一个关键框架——Harness 本质上是一个控制论调节器（cybernetic governor），通过引导和反馈两条路径将代码库调节到期望状态。
引导（Feedforward Controls）：
事前约束——在 Agent 行动之前就设定好边界和方向，提升它第一次就做对的概率。
反馈（Feedback Controls）：
事后检测——在 Agent 行动之后观察结果，帮助它自我修正。
两者的关键区别：
| 维度 | Feedforward（引导） | Feedback（反馈） |
|---|---|---|
| 时机 | 行动之前 | 行动之后 |
| 目的 | 预防问题 | 发现并修正问题 |
| 本质 | 塑造概率空间 | 提供验证信号 |
| 典型实现 | AGENTS.md、Skill、Linter 规则 | 测试、CI、浏览器自动化 |
为什么缺一不可？
引导和反馈各自有两种执行方式：
| 类型 | 特点 | 执行速度 | 可靠性 | 典型实现 |
|---|---|---|---|---|
| Computational（计算型） | 确定性强，CPU 执行 | 毫秒~秒级 | 高 | Linter、测试、类型检查、ArchUnit |
| Inferential（推理型） | 语义分析，GPU/NPU 执行 | 秒~分钟级 | 中等（概率性） | AI Code Review、LLM as Judge |
Computational 的价值：用确定性工具提升好结果出现的概率。速度快到可以每次变更都运行。
Inferential 的价值：处理需要语义判断的问题——同类语义重复代码检测、过度设计的解决方案识别等。但成本高、不确定，不能每次 commit 都跑。
核心问题：定义 Agent 该知道什么、不该知道什么，避免它对无关信息做出反应。
关键设计：
典型实现：
# AGENTS.md（入口文件，约100行）
## 角色
你是一个专门处理 [具体系统] 的后端工程师。
## 关注范围
- 只修改 `src/services/` 和 `src/models/` 目录
- 不碰基础设施代码（CI、部署脚本）
## 当前任务状态
[见 progress.md]
核心问题：Agent 需要用哪些工具？什么时候调用？结果怎么提炼？
工具分类：
| 工具类型 | 作用 | 例子 |
|---|---|---|
| Bash | 通用命令执行 | 运行测试、构建、脚本 |
| Filesystem | 安全文件操作 | 读、写、搜索，带路径验证 |
| State Management | 会话内任务追踪 | Todo list、进度文件 |
| Orchestration | 派生子 Agent | OpenCode task tool、Claude Code agent tool |
| MCP Servers | 外部系统集成 | GitHub、Slack、数据库 |
工具调用设计原则：
核心问题：让模型像人一样走完"理解目标→判断信息→分析→生成→检查"的完整轨道。
ReAct 循环（Reasoning + Acting）：
用户请求 → 模型接收当前状态
→ Reasoning（推理）：思考下一步做什么
→ Acting（行动）：通过工具执行
→ Observation（观察）：获取结果
→ 循环直到满足停止条件
举例：用户让 Agent 修复一个失败的测试。
停止条件的设定至关重要：没有明确停止条件，Agent 会无限循环或过早退出。
核心问题：长任务中间结果怎么管？防止系统混乱。
三层记忆架构：
| 层级 | 存储 | 持久性 | 作用 |
|---|---|---|---|
| Filesystem | 磁盘 | 永久 | 进度文件、git 历史、session 记录 |
| RAM | 内存 | 会话内 | 对话历史、工具结果 |
| Context Window | 模型上下文 | 当前请求 | 模型实际看到的 |
状态持久化最佳实践（Anthropic）：
核心问题：Agent 怎么知道自己做对了？建立独立于生成过程的验证机制。
验证方式：
| 验证类型 | 例子 | 优点 |
|---|---|---|
| Computational | 单元测试、集成测试、架构测试（ArchUnit） | 快速、确定性强 |
| Inferential | AI Code Review、AI-generated tests | 能验证语义正确性 |
| Human-in-loop | 人工审查 | 最终保障 |
Boris Cherny 的洞察：给模型验证自己工作的方式，质量提升 2-3 倍。
核心问题：预设规则拦截错误，失败时提供重试或回滚机制。
约束类型：
| 类型 | 例子 |
|---|---|
| 架构约束 | 自定义 Linter 检查分层结构，违反报错 |
| 安全约束 | 白名单工具调用、文件系统路径限制 |
| 格式约束 | ESLint、Prettier 代码风格 |
| 恢复机制 | API 超时重试、上下文超限重启 |
OpenAI 的原则："If it cannot be enforced mechanically, agents will deviate."——文档中记录约束是不够的，如果不能机械化地强制执行，Agent 就会偏离。
Dex Horthy 的研究：168K token 上下文窗口，用到约 40%（~67K tokens）时，Agent 输出质量急剧下降。
| 区间 | 表现 |
|---|---|
| Smart Zone（0-40%） | 推理聚焦、工具调用准确、代码质量高 |
| Dumb Zone（>40%） | 幻觉增多、兜圈子、格式混乱 |
Anthropic 把这个问题叫"上下文焦虑"——Sonnet 4.5 快到上下文上限时变得犹豫，倾向于提前收工。
策略一：压缩（Compaction）
将上下文中的冗长内容压缩为 LLM 摘要要点，保留关键信息的同时减少 token 占用。
策略二：上下文重置（Context Reset）（Anthropic 的选择）
不压缩，而是把当前任务状态、已完成工作、待办事项结构化提取出来，然后启动一个全新的干净 Agent，把交接文档交给它。
这就像程序碰到内存泄漏时的解法——不是手动释放每一个内存块，而是直接重启进程从检查点恢复。
策略三：渐进式披露（Progressive Disclosure）
不要把整个 AGENTS.md 塞进上下文。而是把 AGENTS.md 当目录用（约 100 行），指向深层文档，Agent 需要什么再加载什么。
设置 40% 阈值告警——当 Agent 上下文占用超过 40% 时，触发上下文压缩或任务交接。等 Agent 已经变蠢了再处理就晚了。
Human's job is to steer the agent by iterating on the harness——每当 Agent 多次犯同一个错误，就要改进 Feedforward 和 Feedback 控制，让这个问题在未来更少发生甚至完全防止。
Agent 犯错 → 人类分析根因 → 改进 Harness（规则/工具/验证）→ Agent 不再犯
Böckeler 提出的一个关键观点：Harness 是需要维护的软件。
AI 也可以用来改进 Harness 本身：
CI/CD 的成熟团队早就知道：检查越早发现错误，修复成本越低。
Harness Engineering 同样适用：
| 时机 | 应该做什么 |
|---|---|
| Commit 前（最左） | Linter、快速测试、基本代码审查 |
| Commit 后 | 慢速测试、mutation testing |
| 集成后 | 全面代码审查、端到端测试 |
除了变更生命周期，还需要持续运行的监控：
Harness 的技术原理可以浓缩为三个核心机制：
1. Feedforward + Feedback 双轨控制：事前引导 + 事后验证，缺一不可
2. 六层各司其职：L1 定义边界 → L2 装备工具 → L3 编排执行 → L4 管理记忆 → L5 验证结果 → L6 兜底恢复
3. 上下文是硬约束：40% 是红线，超过后质量断崖式下跌；重置优于压缩
下一期我们将从系统设计的角度，讲解生产级 Harness 的架构——记忆系统、工具设计、沙箱隔离、多 Agent 编排。
标签：#AI #Agent #HarnessEngineering #ReAct #Feedforward #Feedback #六层架构
Series Index
Harness Engineering 指南Conversation
0 条