本文是《可控涌现：AVL Code 的工程范式》系列的中篇，全系列分三天发布：（7 月 16 日）· 中篇（本文，7 月 17 日）· 下篇《从理论到实践与七条工程原则》（7 月 18 日）。

上篇确定了两件事：涌现是系统整体相对于部分多出来的、可观察可测量的属性；LLM 与 Context、Tool、运行时结合后涌现的是功能性行为，而不是认知结论。

但“功能行为可以涌现”只回答了现象是什么，没有回答工程该怎么做。模型只是提出建议，真正决定这些建议能否变成受约束的现实动作的，是模型之外的那一层结构。本篇讨论这一层：Harness 负责把能力接到真实世界，Loop 负责让系统在多轮运行中收敛并停下来。

三、Harness 工程：把模型能力接到真实世界

Harness 原意是挽具：它不替代动力源，却把动力连接到方向、负载和制动系统。对生成式 AI 工程来说，Harness 是包围模型的一组工程结构，负责把概率输出转化为受约束的任务执行。

一个实用的 Agent 系统可以近似表示为：

其中，Harness 通常覆盖模型之外的主要部分：

Harness 不是一段更长的系统提示词。提示词、AGENTS.md 和 Skill 主要形成软约束，通过 Context 改变输出概率；权限校验、JSON Schema、路径边界、审批、超时、测试门禁和沙箱属于硬约束，由确定性代码在模型之外实施。

生成式 AI 工程的关键，不是要求概率模型自己变成确定性程序，而是让确定性机制管理它与现实世界的接触面。

四、Loop 工程：在不完全模型上实施反馈控制

如果 Harness 决定“系统由什么组成、边界在哪里”，Loop 决定“系统怎样在多轮运行中保持目标、利用反馈，并在合适的条件下继续或停止”。它不是“模型多回答几次”，也不等同于“修改代码后反复运行测试”，而是由目标状态、Context 更新、动作执行、结果观测、资源预算和停止条件共同组成的运行时控制环。

一次 Agent 循环仍可以抽象为：

其中，rr 是目标与验收标准，zk是模型给出的文本或动作建议，GG 按权限策略 PP 校验和放行动作，TT 是 Tool，EE 是外部环境，Ok+1是本轮获得的事实观测，UU 则把动作、结果和任务状态重新组织进下一轮 Context。真正困难的不是写出这组公式，而是把“继续还是停止”从一句模糊提示变成可执行的状态机。

AVL Code 的 GOAL 命令正是一个具体实现。它把长任务的目标、状态、Token 预算、用量和连续自动续转计数保存在 Session 中，使控制环不依赖模型临时“记得自己还要做什么”。

1. GOAL 把长任务变成有状态的闭环

用户用 /goal <目标> 创建或更新目标，用 /goal budget N 设置 Token 预算，并可通过 pause、resume、complete、clear 控制生命周期。GOAL 的持久状态只有 active、paused、complete 和 budget_limited 四种；目标发生变化时，下一轮会收到重新对齐引导，而不是沿着旧目标惯性继续。

当 GOAL 处于 active 时，运行时把目标块注入 Context，Agent 据此读取环境、调用 Tool 或子代理并完成一个回合。回合终点到达后，系统先累计自身与子代理的 Token 用量和 Tool 调用，再执行续转判定：

• 总用量达到预算，状态转为 budget_limited，停止自动续转；
• 回合以终态错误结束，停止续转但保留 active，把控制权交还用户；
• 回应末行是 <goal-status>complete</goal-status>，状态转为 complete；
• 回应末行是 <goal-status>need-input</goal-status>，等待用户提供必要决策；
• 其余情况，包括没有输出标签，均默认继续：系统追加隐藏消息“继续推进目标”，自动启动下一轮。

连续自动续转超过 50 轮时，运行时停止自动推进并提示用户检查进展；真实用户介入会清零连续续转计数。这里体现的不是“让模型自己决定一切”，而是由模型报告语义状态，由确定性运行时验证信号、记账、迁移状态并实施上限。

这与控制工程的基本思想同构，但对应关系已经从抽象比喻落到了可检查的产品机制：

测试、Lint、SAST 和人工验收仍然重要，但它们是回合终点的观测与门禁，可以接管一次续转判定；它们不是 GOAL 主状态机本身。GOAL 负责“围绕什么目标继续、当前处于什么状态、还能消耗多少资源、何时必须停”，检查门禁负责提供“这一步是否满足技术约束”的事实证据。

2. 它不是传统控制器的简单复制

AI 工程中的“控制器”具有概率性，代码库和外部服务是高维、离散、时变的环境，成功标准往往含有语义判断，传感器也只能观察局部状态。工程师通常既没有被控对象的完整模型，也无法证明每次动作都单调接近目标。

所以 Loop 工程不能照搬一个固定 PID 参数，而要吸收更一般的控制思想：

• 小步执行，缩短开环距离：一次修改越大，失败后越难定位因果；
• 提高观测质量：优先使用编译器、测试、静态分析和真实 Tool 结果，而不是让模型猜测——复杂业务系统网络故障分析是个现成的例子，一桩五年未直接定位的网络沉疴，是从 2.2 GB 流量包的证据里一步步走到根因的，不是靠猜；
• 控制反馈增益：失败信息应相关、结构化、不过量，避免整段日志淹没有效信号；
• 加入阻尼与保护：对重试、轮数、时间、Token、并发和副作用设置上限；
• 识别振荡和失稳：连续重复同一修复、反复改回、待办长期不前进时应换策略或停止；
• 保留人工控制权：高风险动作、需求歧义和不可逆变更必须设置确认点。

Loop 的目的不是“让 Agent 永远运行”，而是让它围绕稳定目标持续获得事实反馈，并在完成、阻塞、错误、预算或人工边界出现时可预期地退出。AVL Code GOAL 的价值，正在于把这种继续与停止的控制权从提示词愿望变成运行时机制。

五、系统工程：Harness 与 Loop 之上的完整视角

Harness 工程主要处理能力接入与边界，Loop 工程主要处理运行时反馈与收敛；系统工程则要覆盖从需求到退役的完整生命周期。

SEBoK 的 Systems Engineering Core Concepts把组件、内部网络、外部环境、边界、行为和历史都纳入系统描述，并把涌现与反馈视为系统科学的核心概念。这提示我们：AI 产品的 System-of-Interest不应只画成一个模型 API，而应至少包括运行时、工作区、Tool、组织规则、用户和外部环境。

1. 验证与确认是两条不同的反馈线

SEBoK 的 System Verification强调用客观证据检查系统是否满足规定的要求、架构和设计属性；System Validation则关注系统是否在预期环境中满足特定用途和利益相关方目标。用常见的工程说法：

• Verification：是否把系统做对了？ 例如代码能否编译、测试是否通过、权限是否按设计生效；
• Validation：是否做了正确的系统？ 例如修改是否真正解决用户问题、结果是否适合实际工作流。

只做测试门禁可能得到“全部测试通过，但需求理解错了”的结果；只让用户凭感觉验收，又可能漏掉实现缺陷。可控涌现需要机器证据与人的目的判断共同闭环。

2. AI 系统的 V&V 必须贯穿生命周期

SEBoK 关于 AI 系统 V&V 的条目指出，AI 子系统存在判定 oracle 缺失、不可能百分之百准确、未测试输入行为不确定、对训练数据高度依赖等特征。因此，V&V 不能是上线前的一次考试，而要进入需求、设计、集成、运行和更新全过程。

对 Agent 产品而言，这意味着既要评估模型，也要评估 Context 组装、Tool 接口、权限策略、Loop 稳定性、失败恢复以及人在环流程。模型升级后，旧 Harness 的行为可能改变；Tool Schema 变化后，旧 Skill 可能失效；权限放宽后，同一个规划能力可能产生不同风险。系统工程负责管理这些联动，而不是只比较模型榜单。

小结与下篇预告

Harness 回答“系统由什么组成、边界在哪里”，Loop 回答“怎样根据反馈继续或停止”，系统工程则要求我们从利益相关方目标、生命周期、风险和证据出发管理整体。

这三层说的都是方法。它们能不能落到一个真实产品上，是另一个问题：阶段边界是否由运行时强制，目标能否跨回合持久化，权限能否真正拒绝越界动作，异常路径有没有兜底。下篇《从理论到实践与七条工程原则》（7 月 18 日发布）将把这些方法对照到 AVL Code 的具体机制——工作模式、GOAL、Tool 与权限、检查门禁、自愈与看门狗——并给出可控涌现的七条工程原则。

参考资料

系统工程主要资料

• SEBoK：Systems Engineering Core Concepts
• SEBoK：System Verification
• SEBoK：System Validation
• SEBoK：Verification and Validation of Systems in Which AI is a Key Element

AVL Code 主要资料

• AVL Code 官网
• AVL Code 用户手册
• AVL Code 参考手册