可控涌现：AVL Code 的工程范式（中）—

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

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

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

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

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

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

Agent\ System = LLM + Context + Tool + State + Policy + Loop + V\&V + Human

Agent 运行时通过编排、授权和外部 Tool 把模型能力接入真实世界 — 图 4：Agent 运行时把 LLM 的概率决策交给编排与执行层，经校验、授权和超时控制后调用外部 Tool，再把结果写回 Context；模型能力由此成为可约束、可反馈的现实动作。

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

Harness 组件	回答的问题
模型与供应商适配	调哪个模型，失败时是否切换，参数如何设置
Context 组装	哪些指令、文件、历史、Skill 和 Tool 结果进入本轮
Tool 网关	模型能提出哪些动作，参数如何校验，结果如何回写
状态管理	目标、计划、待办、工件、检查结果怎样持久化
权限与沙箱	哪些动作允许、需审批或必须拒绝
Loop 控制	什么情况下继续、换策略、重试、暂停或停止
验证与评估	如何判断“做对了”和“做的是对的事”
可观测与恢复	如何审查轨迹、定位失败、从中断处继续

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

约束方式	例子	能否强制保证
软约束	“先读代码再修改”“遵守团队命名规范”	只能提高遵循概率
结构约束	Tool Schema、状态机、限定输出格式	可限制表达和流转空间
硬约束	禁止写入、沙箱、参数校验、审批、预算上限	可在运行时拒绝越界动作
证据门禁	编译、测试、Lint、SAST、人工验收	可阻止未达标准的结果被宣告完成

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

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

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

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

\begin{aligned} z_k &\sim \pi_\theta(\cdot \mid C_k) \\ a_k &= G(z_k, P) \\ o_{k+1} &= E(T(a_k)) \\ C_{k+1} &= U(C_k, a_k, o_{k+1}, r) \end{aligned}

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

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

AVL Code GOAL 会话级目标自动续转机制 — 图 5：AVL Code GOAL 将目标注入、Agent 回合、用量核算、停止信号、自动续转与人工控制组织成会话级闭环。正常终态默认继续；完成、等待用户、终态错误、预算耗尽和连续续转上限构成明确的停止条件。

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

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

控制工程概念	AVL Code GOAL 中的对应物
参考输入	Session 中持久化的 `Objective` 与用户验收要求
控制器	LLM 的动作建议 + GOAL 自动续转判定
被控对象	代码库、构建环境、外部服务及任务工件
执行器	Tool、子代理以及受权限控制的运行时动作
观测	Tool 结果、终态回应、错误和用量统计
状态估计	Context、GOAL 状态、Plan、Todo 与历史摘要
控制动作	目标块注入、隐藏续转消息、暂停、恢复和人工接管
保护装置	Token 预算、终态错误停转、50 轮上限、权限与审批

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

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

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

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

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

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

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

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

层次	核心问题	典型产物
Harness 工程	怎样把模型、上下文、工具、权限和状态可靠接起来	Tool 网关、Context 管线、权限策略、状态机
Loop 工程	怎样根据观测纠偏，何时继续、换路或停止	反馈回路、门禁、重试策略、预算、看门狗
系统工程	为什么建、为谁建、整体是否满足使命、全生命周期风险如何管理	需求、架构、V&V、风险、配置、运维和演进机制

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 与权限、检查门禁、自愈与看门狗——并给出可控涌现的七条工程原则。

参考资料

系统工程主要资料

AVL Code 主要资料

AVL Code，AVL 安全引擎，与智能随行。安天澜砥团队出品。