可控涌现：AVL Code 的工程范式（下）——从理论到实践与七条工程原则

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

上篇确定了涌现的概念边界：功能性行为可以从系统中涌现，但不能据此推断认知。中篇给出了方法：Harness 把能力接到真实世界，Loop 在无法完全建模的对象上实施反馈控制。

方法能不能落到一个真实产品上，是另一个问题：阶段边界是否由运行时强制，目标能否跨回合持久化，权限能否真正拒绝越界动作，异常路径有没有兜底。本篇把这些方法对照到 AVL Code 的具体机制。

六、从理论到实践：AVL Code 的 Harness 与 GOAL Loop

我们做 AVL Code，不是为了给某个 LLM 套上一层桌面界面，而是要把模型能力变成一套真正能在工程现场工作的 Agent 系统。模型负责提出候选行动，工作模式划定阶段，Context 组织当轮条件，Tool 与权限管理现实动作，GOAL 维持跨回合目标，检查门禁提供事实证据，自愈与看门狗处理异常。我们要解决的不是“怎样让模型再多做几步”，而是“怎样让一项长任务在真实环境中持续推进，并在完成、阻塞或越界时可靠停下”。这就是 AVL Code 对 Harness 与 Loop 的工程回答。

1. 用工作模式建立阶段状态机

AVL Code 用户手册定义了 auto、plan、prepare、execute、assess 五种工作模式，并推荐 plan → prepare → execute → assess 的阶段流程。其中 plan 与 assess 是运行时强制只读，不能靠提示词或 Hook 绕过。

这项设计的系统意义不是给界面增加五个标签，而是把不同阶段的目标和可用执行器分开：

阶段	主要任务	控制作用
auto	根据任务直接组织理解、行动与反馈	自动选择行动路径和 Tool，适合目标清晰、风险较低、无需严格分阶段的小任务
plan	理解问题、读取信息、形成方案	在事实和方案未确认前保持执行器隔离，不产生写副作用
prepare	整理依赖、环境和执行清单	降低执行阶段的不确定性
execute	编辑、运行、测试和修复	开放必要执行器，进入闭环控制
assess	只读验收与复盘	把“生成结果”和“评价结果”分离，避免边评边改掩盖问题

auto 并不是 plan → prepare → execute → assess 中的一个固定工序，而是面向轻量任务的一站式自主模式：运行时允许 Agent 根据当前 Context 直接选择回答或调用 Tool，减少人工切换阶段的成本。任务一旦涉及较大改动、需求歧义或较高风险，显式进入分阶段流程，仍然更容易建立确认点、权限边界和验收证据。

模式切换同时改变助手配置和 Tool 权限集合，说明阶段边界由运行时实施，而不只是要求模型“自觉”。工作模式与 GOAL 并不是两套互相替代的流程：模式回答“这一阶段允许怎样工作”，GOAL 回答“围绕什么目标持续推进、何时继续或停止”。

2. 用 GOAL 持久化目标，用 Context 组织当轮状态

中篇介绍的 GOAL 是会话级稳定控制状态：它保存 Objective、active / paused / complete / budget_limited 状态、Token 预算、用量与连续续转计数。Context 则是每一轮重新组装的工作面，承载当前目标块、历史消息、Tool 结果、项目指令以及运行中的局部状态。把二者分开，才能避免把“目标仍然存在”误解为“目标必须原样占据每一轮全部提示词”。

AVL Code 支持将 AGENT.md、AGENTS.md 或 CLAUDE.md 作为项目指令注入 Context；Skill 用于封装领域工作流；Plan 描述阶段、输入、输出与风险；Todo 记录待办、进行中、完成、跳过或失败状态。GOAL 负责稳定主线，这些 Context 成分负责告诉模型当前处境和可用方法。

当历史接近上下文上限时，Compact 会压缩早期消息，但保留计划、待办、关键 Tool 结论、用户决策和必要事实。工具结果还会受到大小钳制，发送前进行上下文容量预估。这些机制解决的不是“模型参数不够聪明”，而是长程任务中的状态可见性与信号质量问题。

可以把 GOAL 理解为控制环的参考输入与持久状态，把 Context Harness 理解为状态估计器：前者稳定回答“最终要去哪里”，后者持续回答“现在在哪里、哪些观测可信、下一步还缺什么”。

3. 用 Tool、权限与沙箱分离“建议”和“行动”

AVL Code 把文件、命令、版本控制、代码智能、安全分析和外部服务组织为 Tool。模型提出 Tool 调用后，运行时仍要根据“启用 / 询问 / 禁用”三态权限决定是否执行；需要审批时，用户看到工具名、参数和影响范围，超时未响应按拒绝处理。

更重要的是，部分底线独立于普通授权存在。例如 samples/ 样本目录强制禁用执行类工具，破坏性命令和危险注入仍受参数校验。这条线在真实分析里一直生效：无论是研判 fast16 恶意代码、还原 Darkhotel 藏在 JPEG 里的隐写载荷，还是核验 Grok Build CLI 的离线安装包，样本全程待在只读沙箱内。这里体现了 Harness 的关键原则：

模型可以建议动作，但动作的合法性、权限和副作用边界必须由模型之外的确定性机制裁决。

这既减少了非期望涌现的破坏半径，也使更积极的功能性涌现成为可能——只有执行边界可信，系统才适合获得更大的行动空间。GOAL 可以请求系统继续推进，却不能绕过 Tool Schema、权限审批、路径边界或沙箱；持续性与行动合法性由不同层分别负责。

4. 用检查门禁为 GOAL 回合提供事实反馈

中篇的图 5 已经给出了 GOAL 的主控制环，这里再放一次，便于对照：

AVL Code GOAL 会话级目标自动续转机制 — 图 5（回顾）：AVL Code GOAL 将目标注入、Agent 回合、用量核算、停止信号、自动续转与人工控制组织成会话级闭环。检查门禁位于回合终点，不是另一套平行循环。

在这个环上，LSP 诊断、测试、Lint、SAST 和人工验收不是另一套平行循环，而是回合终点的事实观测与证据门禁。把它们直接画成“修改—检查—修复”的主循环，会遗漏持久目标、自动续转、预算和人工接管等更关键的控制状态。

启用自检门禁后，运行时可以先执行选定检查：失败时把结构化结果写回 Context 并要求 Agent 继续处理；通过或没有适用检查时，再把续转权交回 GOAL。门禁区分 block 与 report，限定检查范围并设置连续注入上限，避免 flaky 测试或不可修问题造成死循环。

两者分工清晰：GOAL 决定“任务是否仍应推进”，检查门禁回答“本轮结果是否获得足够证据”。前者维持目标、状态、预算、自动推进和人工接管条件，后者提高观测质量并阻止缺少证据的“假完成”。

5. 用自愈、预算和看门狗处理非理想运行

GOAL 处理的是正常回合之间的继续与停止，现实运行还需要处理异常路径：上下文超限、供应商过载、网络抖动、输出截断、重复推理和长期无进展。AVL Code 的自修复机制会按错误类别选择压缩重试、供应商兜底、退避重试或停止并交还用户；同一检查反复失败时会提示换思路，到达上限后停止。

子任务也设置空闲看门狗和绝对时间兜底；并行任务有并发数与等待上限；长程后台任务会保存进度并支持中断恢复（多 Agent 并行分析 Android 银行木马用的正是这套并行机制）。它们共同回答了闭环系统最容易被忽视的问题：

如果观测暂时缺失，是否误判任务已经死亡？
如果持续有输出但没有进展，如何识别“忙碌式失稳”？
如果自动修复无效，何时停止消耗资源？
如果系统崩溃，状态能否恢复而不是从头猜测？

这些机制与 GOAL 的 Token 预算、终态错误停转和 50 轮自动续转上限共同构成多层保护。没有这些边界，“自主”很容易退化成无限循环；有了这些边界，系统才可能在长任务中保持可预测的失败方式。

6. 一次任务中的可控涌现

以“为现有服务增加输入校验并通过安全检查”为例，AVL Code Harness 可以形成如下运行链：

用户用 /goal 固化任务目标并按需设置 Token 预算，GOAL 进入 active；
在 plan 模式下只读扫描仓库、项目指令和相关 Skill，形成影响范围、测试策略与风险说明；
用户确认计划后切换到 execute，运行时把 GOAL 目标块与当前 Plan、Todo、文件和历史观测组装进 Context；
LLM 提出编辑或 Tool 调用，Tool 网关完成参数校验、权限判断和必要审批后才作用于工作区；
LSP、测试、Lint 或 SAST 在回合终点返回事实观测；失败结果被结构化写回 Context，由 Agent 在下一轮继续处理；
如果任务尚未完成且没有停止信号，GOAL 追加隐藏续转消息，保持同一目标自动进入下一回合，而不是等待用户反复输入“继续”；
技术门禁通过后，可切换到 assess 只读检查 Diff、需求覆盖和风险；确认达成时以 complete 收尾；
若需要用户决策、发生终态错误、达到预算或连续续转上限，运行时停止自动推进并交还控制权。

这里没有哪一步需要假设“模型产生了意识”。但从系统边界观察，确实出现了任何单个部分都不具备的整体属性：在组织规则和安全边界内，围绕持久目标跨回合感知、行动、纠错，并在有证据或触及边界时收束。

这就是 AVL Code 所体现的功能性行为涌现，也是 Harness 工程试图控制和放大的对象。

上面是一条示意性的运行链。真实的链条长什么样，不必靠想象：官网公开案例把每一次会话原样挂了出来——智甲 EPP 自动巡检与 CVE 漏洞扫描是一条典型的长任务闭环，等保 2.0 基线核查则展示了门禁与证据如何驱动结论。它们的推理、工具调用、报错与恢复全程可查，也包括判断失误后退回重来的那几步。这些机制写在用户手册与参考手册里，同一套东西也运行在这些会话中——不是发布时补写的承诺。

七、可控涌现的七条工程原则

1. 先定义系统边界，再谈智能

明确评价对象是裸模型、带 Context 的模型服务、Agent，还是包含人和组织流程的工程系统。边界不同，属性归属也不同。

2. 用可验收行为描述涌现

少问“它是否真的会思考”，多定义“它能否在指定仓库、权限和时间预算内完成任务，并提交哪些证据”。

3. 把软约束与硬约束分开

项目说明、Skill 和提示词负责提高正确行为概率；权限、Schema、沙箱、审批、门禁和预算负责阻止不可接受行为。

4. 优先改善事实反馈，而不是无限加长提示词

真实文件、编译器、测试、日志和 Tool 执行结果，构成可核验的事实反馈，通常比模型自我断言更有价值。高质量、低噪声、结构化的事实反馈，是闭环收敛的基础。

5. 所有 Loop 都必须有停止条件

至少定义成功、失败、阻塞、风险、时间、Token、重试和人工接管条件。不能停止的 Agent 不是更自主，只是更不可控。

6. 同时做 Verification 与 Validation

测试通过证明实现满足某些技术条件，不证明需求一定正确；用户满意证明方向可能正确，也不证明实现没有缺陷。

7. 把失败轨迹变成系统资产

保留关键观测、设计决策、有效模式和失败反模式，并经过审查后进入组织知识。可控涌现不是一次性的“灵光”，而是跨任务积累出来的工程能力。

结语

LLM 是生成式 AI 系统的重要能力源，但不是完整的工程产品。真正把概率生成转化为生产力的，是模型周围的 Context、Tool、State、Policy、Loop、V&V 与 Human，以及它们之间经过设计的关系。

涌现告诉我们，系统整体可以具有部分所不具有的属性；控制工程告诉我们，能力必须放进观测—反馈—纠偏—停止的闭环；系统工程则要求我们从利益相关方目标、生命周期、风险和证据出发管理这个整体。三者结合起来，得到的不是“证明 AI 已经像人一样思考”，而是一条更务实的道路：

不神化模型，不否认系统能力；不追求无边界自主，而是用 Harness 约束行动、用 Loop 驱动收敛、用系统工程验证整体价值。

从这个意义上说，AVL Code 的工程范式不是等待智能神秘涌现，而是主动设计条件，让有价值的功能行为更可能出现、被真实证据检验，并在失败时被安全收束。这就是可控涌现。

可控涌现：AVL Code 的工程范式（下）
——从理论到实践与七条工程原则