大模型的根本限制：它没有「长期记忆」，更没有「方向感」
大模型有一个根本限制。
不是上下文窗口大小。不是推理能力。不是工具调用。
是它没有「长期记忆」，更没有「方向感」。
它被训练成在单次对话、单次任务轨迹中完成当前目标。 但它不知道：经过几十次 plan、上百次 commit、多轮 AI 修改之后，系统是否仍然朝同一个架构方向收敛。
问题的本质：单次样本优化 vs 长期工程演化
大模型的训练形态：
- 单次样本
- 单次对话
- 单次任务轨迹
模型被优化成：
- 理解当前任务
- 调用工具
- 修改文件
- 运行验证
- 给出结果
但这只是「一次 run」。
长期工程的现实：
- 几十次 plan
- 上百次 commit
- 多轮 AI 修改
- 多个人、多个 Agent 参与
- 跨越几天、几周、几个月
问题是：
即使模型可以读写仓库文件，也不等于它天然拥有：
- 跨 session 的项目记忆
- 架构方向感
- 长期责任链
当前的解决方案：Harness（控制闭包）
业界正在尝试的方案：
NLAHs（Natural-Language Agent Harnesses）
- 用自然语言定义 harness policy
- 用 IHR（Intelligent Harness Runtime）组织一次 task run
- 确保单次执行更可靠、可审计、可恢复
OpenProse
- 用 responsibility 定义任务边界
- 用 fingerprint 确保局部不变量
- 用 deterministic runtime 维护一致性
它们解决的是： "
"如何让一次 run、一个 responsibility、一个 harness 控制闭包更可靠？"
它们能做什么：
- 让局部执行更稳定
- 让单次任务更可审计
- 让失败更容易恢复
但它们解决不了什么：
"经过几十次 plan、上百次 commit、多轮 AI 修改之后，系统是否仍然朝同一个架构方向收敛？"
为什么？
因为 harness 主要面向「当前任务 contract」。
它可以让局部成功。
但它不知道：
- 哪些局部成功正在累积成「长期漂移」
- 哪些短期优化正在破坏「长期一致性」
- 哪些架构决策正在被「无声地侵蚀」
核心问题：Run-Level Harness vs Evolution-Level Direction
Run-Level Harness（当前工具能做的）：
| 能力 | 范围 | 限制 |
|---|---|---|
| 单次任务执行 | 当前 run | 不知道历史 |
| 局部不变量维护 | 当前文件 | 不知道全局影响 |
| 失败恢复 | 当前任务 | 不知道长期趋势 |
| 审计日志 | 当前操作 | 不知道架构方向 |
Evolution-Level Direction（真正需要的）：
| 能力 | 范围 | 为什么需要 |
|---|---|---|
| 项目记忆 | 跨 session | 知道过去做了什么 |
| 架构方向感 | 跨版本 | 知道系统要去哪里 |
| 长期责任链 | 跨 commit | 知道谁对什么负责 |
| 漂移检测 | 跨时间 | 知道系统是否偏航 |
问题：
Run-Level Harness 让「每一步」都正确。
但它不知道「这一步」是否让系统朝正确的「方向」走。
解决方案：Attractor-Guided Engineering（AGE）
核心思想：
借用动力系统中的 "attractor"（吸引子） 概念。
什么是 attractor？
在动力系统中，attractor 是系统「倾向于回到」的状态。
比如：
- 一个摆在重力作用下最终会停下来的位置
- 一个生态系统中最终会形成的物种平衡
AGE 的核心隐喻：
工程演化也是一个动力系统。
我们需要定义「吸引子」——系统应该回到的地方。
然后持续检查：系统是否正在朝吸引子收敛？
AGE 的七层外部结构
AGE 通过七层外部结构，定义和校正「系统应该回到哪里」。
1. Owner-Doc（所有者文档）
## Owner-Doc
### System Purpose
这是一个电商平台的订单系统
### Architectural Direction
- 微服务架构
- 每个服务独立部署
- 服务间通过事件总线通信
- 数据最终一致性
### Non-Negotiables
- 不允许服务间直接调用数据库
- 不允许同步跨服务事务
- 不允许业务逻辑散落多处作用： 定义系统的「北极星」。
2. Architecture Rule（架构规则）
## Architecture Rules
### Rule 1: Service Boundary
每个服务必须：
- 拥有独立的数据存储
- 通过 API Gateway 暴露接口
- 发布领域事件给其他服务
### Rule 2: Data Consistency
跨服务数据必须：
- 使用 Saga 模式
- 记录每个事务的状态
- 提供补偿机制作用： 定义「不可违反的约束」。
3. Plan Lineage（计划谱系）
Plan-001: 重构订单服务
├─ Commit-1: 提取事件发布逻辑
├─ Commit-2: 实现 Saga 协调器
└─ Commit-3: 添加补偿事务
Plan-002: 优化查询性能
├─ Commit-1: 添加缓存层
└─ Commit-2: 实现读写分离作用： 追踪「每次改动属于哪个战略计划」。
4. Bug Note（Bug 记录）
## Bug-2024-001: 库存超卖
### Root Cause
订单服务和库存服务同时扣减库存，没有分布式锁
### Fix Applied
添加 Redis 分布式锁
### Architecture Rule Violated
Rule 2: Data Consistency
### Preventative Guardrail
所有扣减操作必须经过分布式锁作用： 记录「Bug 和架构规则的关联」。
5. Audit Record（审计记录）
## Audit-2024-06-01
### Violation Detected
订单服务直接调用了库存服务的数据库
### Architectural Rule Violated
Rule 1: Service Boundary
### Corrective Action
重构为事件驱动通信
### Status
✅ Fixed作用： 持续检查「是否违反架构规则」。
6. CI Gate（CI 门禁）
# ci-gate.yml
gates:
- name: architecture-check
run: |
- 检查是否有服务间直接数据库调用
- 检查是否有同步跨服务事务
- 检查是否有业务逻辑散落
fail_if: any_violation作用： 在 CI 层面「强制执行架构规则」。
7. Guardrail（护栏）
## Guardrail: 数据一致性
### Before
任何修改库存、订单、支付的代码
### Must
- 检查是否有分布式锁
- 检查是否有补偿机制
- 检查是否有事务日志
### Otherwise
CI 失败，代码不能合并作用： 在代码层面「防止违反架构决策」。
AGE 如何工作？
场景：系统经过多轮 AI 修改后，是否仍然朝同一个方向收敛？
第 1 步：定义 Attractor（吸引子）
Owner-Doc 定义：
- 微服务架构
- 事件驱动通信
- 数据最终一致性第 2 步：建立 Architecture Rules（架构规则）
Rule 1: 服务边界
Rule 2: 数据一致性
Rule 3: 业务逻辑集中第 3 步：每次改动都记录 Lineage（谱系）
每次 commit 都标记属于哪个 Plan
每个 Plan 都关联到 Architecture Rules第 4 步：持续 Audit（审计）
CI Gate 每次运行检查：
- 是否违反架构规则？
- 是否偏离 Owner-Doc 定义的方向？第 5 步：当偏离发生时，触发 Guardrail（护栏）
检测到违反 Rule 2：
→ 阻止合并
→ 生成 Audit Record
→ 要求修复第 6 步：Bug Note 记录学习
Bug 修复后：
→ 记录到 Bug Note
→ 更新 Guardrail
→ 防止同类问题再次发生AGE vs Harness：互补，不是替代
| 维度 | Harness（NLAHs / OpenProse） | AGE（Attractor-Guided Engineering） |
|---|---|---|
| 粒度 | Run-Level（单次任务） | Evolution-Level（长期演化） |
| 范围 | 当前任务执行 | 项目整体方向 |
| 目标 | 让单次 run 更可靠 | 让长期演化更一致 |
| 能力 | 局部不变量维护 | 全局方向控制 |
| 记忆 | 当前上下文 | 跨 session 记忆 |
| 审计 | 当前操作日志 | 跨 commit 审计记录 |
| 恢复 | 当前任务失败恢复 | 长期漂移检测和校正 |
它们解决不同层次的问题：
- Harness： 确保「这次 run」能成功
- AGE： 确保「一百次 run 后」系统仍然朝正确方向走
它们是互补的：
- AGE 定义「去哪里」
- Harness 确保「如何到达」
- AGE 检查「是否偏航」
- Harness 提供「失败恢复」
未来：流程能力的内化 vs 战略方向的外化
未来会发生什么？
流程能力的内化
模型会越来越擅长：
- 何时规划
- 何时验证
- 何时审计
- 何时沉淀 guardrail
这会内化进模型权重。
战略方向的外化
但以下能力仍然需要外部结构：
- 项目记忆（过去做了什么）
- 架构方向（系统要去哪里）
- 长期责任链（谁对什么负责）
- 漂移检测（是否偏航）
这需要 AGE 式的外部结构来承载。
为什么？
因为：
- 记忆有上限 —— 上下文窗口永远有限，外部记忆可以无限
- 方向有历史 —— 方向是跨时间的一致性，模型无法跨 session 维持
- 责任有追溯 —— 谁在什么时候做了什么决策，需要外部审计记录
- 漂移有累积 —— 小的偏离会累积成大的漂移，需要持续检测
写在最后：工程智能的两层
第一层：Run-Level 智能
- 模型越来越擅长执行单次任务
- Harness 让执行更可靠、可审计
- 这会内化进模型权重
第二层：Evolution-Level 智能
- 项目需要跨 session 的记忆
- 系统需要长期方向感
- 工程需要漂移检测和校正
这需要外部结构来承载。
AGE 是什么？
- 不是替代模型
- 不是替代 Harness
- 是在模型和 Harness 之上，再加一层「外部化记忆和方向控制」
大模型的根本限制：
它没有「长期记忆」，更没有「方向感」。
AGE 的解决方案：
用外部结构承载记忆，用 attractor 定义方向，持续检查系统是否朝正确方向收敛。
这不是技术问题。
这是工程哲学问题。
单次优化的模型 vs 长期演化的工程。
Run-Level Harness vs Evolution-Level Direction。
未来属于那些能把两者结合起来的人。