1. 从“知道”到“做到”：为什么17-2这一节卡住了很多人
如果你在追一份系统的AGI基础理论学习路线，看到“17-2 执行功能与认知控制”这个编号出现在目录里，大概率意味着前面已经铺垫完了感知、表征、学习、记忆、注意力这些构件，终于轮到那个最难讲清楚、也最容易被跳过的话题：系统到底由谁来调度，才能像一个有目标的个体那样行动。
我先说一个可能有点反直觉的判断。执行功能和认知控制，看起来不像反向传播、注意力机制那样有漂亮的数学形式，也没有一个能在排行榜上刷分的标准benchmark。但过去几年，我在看各种多任务强化学习、具身智能、对话智能体项目时越来越确信：那些训练时表现很好、一放到开放环境就崩的系统，缺的往往不是更大的模型，不是更多的数据，而是一个真正在线的“目标控制层”。它负责在信息过载时压住无关冲动，在任务切换时清掉旧上下文，在目标漂移时把系统拉回主线。这就是执行功能的职责；它是把“知道”变成“做到”的那一层胶水。
这篇内容适合谁？两类人。一类是做认知架构、元学习、多任务强化学习的研究者，另一类是正在搭智能体框架、被“模型很强但系统不稳”困扰的工程师。我下面会把这节内容拆成三块来聊：执行功能与认知控制在认知科学里到底指什么、有哪些可以直接搬进AGI设计的计算模型思路、以及一个可运行的最小实现长什么样——最后附带我踩过的一些坑。
1.1 先从一段混乱的厨房里认识执行功能
给你描述一个日常到不能再日常的场景。你在做红烧肉，炖到一半发现锅里冒烟需要关小火；这时手机响了，你去接电话；回到厨房你还记得要先把火调小，而不是顺手去刷手机；肉终于盛盘了，但你发现餐桌还没擦——这时候你得克制住“先吃一口”的冲动，把收尾流程做完。整个过程里，任何一个决策失误都会导致菜糊了、电话漏接、饭后还得多打扫一轮。
这种在信息混乱、干扰不断的条件下，按时间顺序逼近既定目标的能力，就是执行功能的基本写照。它通常被拆成几个可操作的部分：记住目标并持续刷新（工作记忆更新）、压住环境触发的自动化反应（抑制控制）、在多个规则之间来回调度（任务切换）、以及监控整体进度是否偏移。
神经心理学里有一个很经典的临床现象，我只说现象不点名。某些额叶区域受损的个体，洗脸、刷牙、按固定路线走路这类高度自动化流程完全没问题；可一旦流程被环境触发启动，就停不下来。让他往杯子里倒水，杯子满了水还继续在流；你中途把他叫到另一个目的地，他依然会按老路线的惯性往前走。这个现象极其深刻地说明了一件事：执行功能管不是“会不会做”，而是“能不能按当前目标动态地做”。如果一个智能体只知道顺着统计惯性往下生成，没有随时可以被外部目标打断并重定向的能力，它在真实世界里就跟这类患者面对的场景一样危险。
1.2 执行功能和认知控制：两个术语，一套机制
在AGI基础理论里，执行功能和认知控制经常被混着用，严格说二者有侧重。执行功能更像一个能力簇的统称，描述的是系统具备哪些高层能力：计划、抑制、更新、切换、监控。认知控制则更偏在线加工机制，强调的是在当前时刻，目标驱动的信号如何压过刺激驱动的信号，把注意力资源分配到该去的地方。用一句比较好记的话概括：执行功能是组织架构，认知控制是日常调度，两者共享同一套底层资源。
过去的神经心理学和个体差异研究给过一个非常有用的坐标。研究者同时测一大批人的三类能力：优势反应抑制（能压住最顺手的自动化冲动）、任务转移（能在两套规则之间快速切换）、信息更新（能不停刷新工作记忆里的最新内容）。结果发现两件事：这三类能力明显正相关，说明背后有个共同的执行控制因子在起作用；但它们又各有不可替代的独特成分，说明不能把它们抹平成一个“万能控制旋钮”。这个发现放到AGI设计里，几乎就是工程结论：既要有统一的中枢协调，也得保留不同控制通道的独立参数和语义。后面我会照着这个原则给出一套具体方案。
还有一个更底层的机制值得记住：认知控制是分“增强”和“抑制”两条腿走路的。走增强通道时，系统会放大与当前目标一致的信号；走抑制通道时，系统会压低当前时刻不需要的强先验或旧习惯。两条腿不对称。增强信号给太多，系统会偏执，只看得到目标相关的信息；抑制给太多，系统会僵住，什么都不敢动。这个矛盾会贯穿后面所有关于调参的讨论。
1.3 为什么AGI基础理论要在这里“接棒”
任何AGI体系说到底都要回答一个问题：智能体如何在资源有限、信息噪声高、目标可能动态变化的世界里，长时间维持行动的一致性。感知、记忆、学习模型解决的是“从环境里得到什么”和“怎么改变参数”，但如果不引入一个目标定向的控制层，这些能力就是一盘散沙。一个语言模型能流畅续写文本，却可能在开放对话里被一句无关刺激带跑，本质上是缺少控制层对生成通道的目标约束。
所以把“17-2 执行功能与认知控制”放在AGI基础理论体系里，我觉得用意非常清楚：前面教的都是构件，这一节才开始讲系统的操作系统。没有这个操作系统，再多的知识库和模式识别器也组合不出一个“能成事”的智能体。现在业界越来越多讨论“agentic AI”，我观察到的最大瓶颈不是模型智力，而是系统在执行多步骤目标时缺乏鲁棒的监控和自纠偏结构。理论上的解决路径，就藏在执行功能与认知控制这几个被很多人当文科概念略过的词里。
2. 认知科学留下的三套“计算模型级”遗产
认知科学里关于执行功能的研究早就超越了心理学描述层面，很多成果本质上就是计算模型，可以直接做工程映射。我挑三个启发最大、也最常被引用的思路展开。
2.1 工作记忆的“中央执行器+从属系统”：给AGI的黑板架构背书
认知心理学里最经典的工作记忆模型，把记忆分成三个部分：一个容量有限的中央执行器，外加两个专门存储临时信息的从属系统（一个管语音类的序列信息，一个管视觉空间类的结构化信息）。中央执行器的职责不是存东西，而是分配注意、激活策略、协调两个从属系统。这个思路放到AGI架构里，对应的是“全局工作空间”或“黑板系统”那一脉的设计哲学：全局目标不散落在各个子模块的参数里，而是收拢在一个中央位置，由执行器统一维护和广播。
工程上有个经常被忽略的推论：中央控制需要两个看得见摸得着的侧翼缓冲区。一个缓冲面向“当前正在操作和表达的内容”，相当于临时复述用的语音回路；另一个缓冲面向“当前环境的空间/拓扑结构”，相当于视空间画板。我见过很多开放式对话系统的表现特别飘，深挖下去发现不是模型知识不够，而是没有一个像样的“会话情境缓冲”让执行器在这些上下文上做递归操作。系统一边生成一边把之前的计划忘得干干净净，这就是没有中央执行器架构的典型症状。
2.2 冲突监控与门控：从“色字干扰”到注意力调制
认知控制一个最经典的体验场景，是屏幕上用蓝色墨水写一个大大的“红”字，让你立刻说出墨水的颜色。几乎所有人都会明显迟疑。读字是自动化加工，颜色命名需要控制信号介入，两个过程同时激活，在大脑里产生了冲突。冲突强度越大，控制系统就越需要介入。这个现象直接带出了一个计算模型思路：系统应该有一个“冲突监控器”，实时比较当前正在做的动作和当下目标的一致性；一旦一致性被无关竞争者压制，监控器就发出信号，要求控制器提高目标相关通道的增益。
把这件事翻译成深度学习语言，几乎就是门控机制的本质。循环网络里的LSTM门结构就是最接近这个思想的可执行之物，只不过它是在长程梯度误差的压力下慢慢被优化出来的，而不是真的“看见”了冲突。真正接执行功能理论的AGI架构，应该在门控之上再显式加一层：冲突监控器输出一个数值化的“冲突强度”，控制器基于这个强度动态决定是否干预主网络的输出通道。这套回路有点像操作系统的中断处理——不是每个中断都要响应，而是优先级和冲突阈值说了算。
2.3 统一性与多样性之争：控制器该做一个还是做一套
如果你用一批被试同时测抑制、切换、更新这三类执行功能，再用统计方法分析分数结构，会看到一个非常有意思的结果：三类分数显著正相关，暗示它们背后共享一个通用执行控制因子；但相关不等于同一，每个子功能还保留着自己独立的方差来源。这个结论在文献里被称作“统一性与多样性并存”，它几乎是给AGI系统设计下的判决书。
我刚接触这个研究结论时很受触动，因为它直接影响一个工程决策：我们到底应该做一个“万能中央控制器”，还是一套互相独立的模块化控制器？我现在的实践观点很明确：先按不同控制类型分模块，再通过一个共通的中央执行器协调，而不是一上来就做一个巨型总控大脑。原因很务实：AGI各个子目标函数差异太大，语言建模、环境导航、社会推理的奖励信号没有天然的统度量纲；强行塞进一个总控模块，容易在训练中出现梯度互踩、控制指令错位。先让不同规格的控制通道各自优化，再在高层做轮询式协调，稳定性要好得多。
3. 从“能回答”到“能成事”：AGI必须补的四门控制课
这一节我把执行功能拆成四门具体能力，每门对应一个AGI系统在真实部署时一定会撞上的技术难点。不只是讲理论，我更想说明每个难点背后隐藏的设计需求。
3.1 目标保持：控制信号不能像梯度一样衰减
做深度网络的朋友都对梯度衰减有直觉：长程目标在反向传播里经过多层之后会变得微弱，残差连接部分缓解了这个问题。但目标保持问题比梯度衰减更内在。一个系统在长时段运行中，要持续维持“我当前到底要完成什么”这个信号，而且这个信号不能因为中间做了几件分心的小任务就指数衰减。
我在自己搭的多智能体实验里发现一个很有代表性的现象：目标缓冲的刷新周期如果设置得太长，系统会慢慢忘掉原始目标，而且它不是出现“没有目标”的状态，而是会自动编造出一个更短的、更近期的替代目标。这非常像人类的“目标漂移”——你在写周报时想起要回消息，回完消息又去整理桌面，最后整个下午过去了，周报没写完，你甚至一度以为“整理桌面”才是下午的任务。所以设计目标保持机制时，至少要满足两点：目标必须放进一个显式的、容量有限的缓冲区，而不是隐式藏在权重分布里；目标需要定期再激活或复述机制。我现在的做法是在每个决策循环里都做一次快速检查：当前正在推进的，是上线前的原始目标，还是已经漂了几轮的幸存者？
3.2 抑制控制：被海量先验带跑的危险
一个在超大语料上训练过的对话模型，如果系统提示明确要求它只谈论某一类产品，用户抛出一个强情绪词，模型大多数情况还是会顺着语境滑向更宽泛的表达。这不是模型笨，而是统计先验太强：通往“最顺滑的续写”的那条通道，和当前目标约束之间发生了冲突。计算版的“优势反应压制失败”，就是这么发生的。
抑制控制落到工程实现上，核心是一个阈值决策：只有当某个候选动作与当前目标的相关性低到一定程度，或者与目标直接冲突时，控制信号才介入踩刹车。这个阈值太敏感，系统会变得犹豫，每个候选动作都被怀疑，训练成本高且动作卡顿；阈值太迟钝，系统又会被惯性带跑。我的经验是先不加抑制项跑一个基线，统计目标冲突信号的自然分布，再取分布靠后的某个分位数作为阈值，完全不建议上来就拍一个值。抑制通道还有一个很容易被忽略的特性：它最好能快速生效，也能快速释放。如果抑制信号一直挂在那里不松开，系统就从一个失控状态走进另一个僵化状态。
3.3 任务切换：从多任务学习到议程调度
AGI系统天然是多个能力在同一套参数或同一套模块上共存的。它可能上一秒在写代码，下一秒需要响应环境里的紧急异常。任何系统做任务切换都有代价：深度学习里叫任务干扰，对话系统里叫上下文切换，机器人控制里叫运动重规划。认知科学对人类行为的一个稳定发现是“切换成本”：切到新任务时，即使任务本身的难度没有变化，响应速度也会明显下降，错误率会阶段性升高。切换成本不是bug，它是一种资源缓冲，说明旧任务的惯性正在被解除，新任务的上下文正在被装载。
但从系统设计角度看，切换成本必须被显式建模进调度器里，而不能让它随机发生。我做过一个多任务强化学习对比实验：一个带显式切换控制器的系统，和一个只依赖网络自适应切换的系统。前几十个episode二者平均奖励差别不大，但跑长以后，无控制系统的行为明显开始“串场”——把上一局里比较好的动作偏好带进新一局，即使新一局的规则不同。而带控制器的系统，在三两个episode内就能完成上下文清理并稳定下来。差异的关键，就是控制器在“保持旧上下文”与“清除旧上下文”之间做了一个基于冲突信号的动态平衡。
3.4 自我监控与错误校正：控制器也要有眼睛
控制不能只对着未来做规划，还得回头看看刚才有没有偏差。认知神经科学里有个很有名的发现：人犯了错误之后，大脑会在几十毫秒内产生一个错误相关的电位，这个电位出现得比人的主观感知还早，而且它自动地、持续地运行。翻译成AGI术语：系统需要一种“内生的模型偏差检测器”，每次决策后快速对结果做一个预测错误评估，当偏差超限时，不只是让主模型更新参数，还要给执行器发一个强“重新激活”信号。
现在很多系统把这项任务外包给RLHF或外部的规则校验器，能是能，但太慢，不适合在线闭环。更廉价的做法是在架构内部加入一个自监督冲突检测器：实时计算当前隐状态和当前目标子空间的余弦距离。如果这个距离持续增大，说明系统的表征正在滑出目标通道，这时候可以提前触发上下文刷新、降低温度系数、或者干脆请求外部干预。我后来在多个项目里都把“目标子空间距离”当成调试日志里的固定指标，它比loss曲线更早知道系统要失控。
4. 实操：给认知架构加一个“执行功能调度器”
理论说得再多，不如动手做一个小而能跑的模块。这一节我会给一个教学级的最小实现——不是生产级框架，而是让你能直观感受“执行功能”在工程里到底长什么样的骨架上位。
4.1 整体设计与模块拆分
我把执行功能调度器拆成四个模块，每个模块对应一个认知功能子项。目标缓冲区（GoalBuffer）负责存储和排序当前目标，相当于工作记忆的中央执行器视野；上下文累积器（ContextAccumulator）负责把最近状态、场景标签、时间戳整合成控制决策的输入；冲突监控器（ConflictMonitor）实时计算当前主网络输出与目标子空间的一致性；切换控制器（SwitchController）拿到冲突分数后，决定是增强当前通道、释放抑制信号、还是触发一次切换。
这四个模块之间只有一条主数据流：感知信息进来后，先进上下文累积器打包；冲突监控器拿打包结果和目标做相关性打分；打分超过阈值时，切换控制器输出一个门控调制信号给主网络。目标缓冲区搁在顶层，只被切换控制器和冲突监控器读写，不参与具体特征计算。这样做的设计意图很明确：全局目标只有一个读写入口，避免子模块各自夹带私货。
4.2 核心流程与参数计算过程
下面给出一段可以跑通思路的Python风格伪代码，核心逻辑在三个方法里：更新目标的刷新、冲突分数的计算、切换控制的决策。你不需要直接拿去生产，但值得逐行读一遍感受一下控制信号是怎么流动的。
import numpy as np from collections import deque class GoalBuffer: def __init__(self, capacity=5, decay=0.95): self.stack = deque(maxlen=capacity) self.decay = decay # 目标信号衰减系数 def push(self, goal_vector, priority=1.0): # 新目标进来时，以衰减后的优先级进入缓冲 entry = { 'vector': goal_vector, 'priority': priority, 'age': 0 } self.stack.append(entry) def top(self): # 取出当前最高优先级目标 if not self.stack: return None self.stack = deque( sorted(self.stack, key=lambda x: -x['priority']) ) return self.stack[0]['vector'] def tick(self): # 每个决策周期调用一次，老化所有目标 for e in self.stack: e['age'] += 1 e['priority'] *= self.decay class ConflictMonitor: def __init__(self, threshold=0.35): self.threshold = threshold def check(self, hidden_state, goal_vector): # 归一化后的余弦相似度，范围 [-1, 1] h = hidden_state / (np.linalg.norm(hidden_state) + 1e-8) g = goal_vector / (np.linalg.norm(goal_vector) + 1e-8) sim = float(np.dot(h, g)) # 冲突分数：低相似度意味着高冲突 conflict = 1.0 - sim return { 'conflict': conflict, 'active': conflict > self.threshold } class SwitchController: def __init__(self, temperature=0.2, switch_cost=0.01): self.temperature = temperature # 控制切换激进程度 self.switch_cost = switch_cost # 每次切换给主网络加的惩罚 def decide(self, conflict, goal_vector): # 在“增强当前通道”和“切换任务”之间做软选择 stay_score = 1.0 / (1.0 + conflict) switch_score = conflict / (self.temperature + 1e-8) total = stay_score + switch_score stay_prob = stay_score / total switch_signal = 1.0 - stay_prob return { 'stay_prob': stay_prob, 'switch_signal': switch_signal, 'penalty': switch_signal * self.switch_cost } class ControlLoop: def __init__(self, base_model): self.base_model = base_model self.goals = GoalBuffer() self.monitor = ConflictMonitor() self.controller = SwitchController() def step(self, observation, hidden_state, external_goal): # 1. 更新目标缓冲 self.goals.tick() if external_goal is not None: self.goals.push(external_goal, priority=1.0) goal_vector = self.goals.top() if goal_vector is None: return self.base_model(observation) # 2. 冲突监控 result = self.monitor.check(hidden_state, goal_vector) if not result['active']: # 冲突不高，走正常通道 return self.base_model(observation) # 3. 切换控制 decision = self.controller.decide(result['conflict'], goal_vector) main_output = self.base_model( observation, context=goal_vector, adapt_weight=decision['stay_prob'] ) return main_output, decision['penalty']流程里的关键点在冲突分数的定义：它不直接用分类loss，而是衡量隐状态和目标向量的余弦相似度。这个思路背后的逻辑是，目标控制信号不需要精确知道主网络该输出什么token，只需要知道当前系统的内部表征是否还在目标的“引力范围”内。相似度低，就说明表征滑出目标了——不管具体滑到哪里，控制器都应该介入。
4.3 关键参数怎么调：我踩过的经验值
调度器里最让人头疼的是四个参数：目标衰减系数decay、冲突阈值threshold、温度temperature、切换惩罚switch_cost。我给出一个带经验的初始值区间和使用指南。
| 参数 | 建议初始值 | 调大后的现象 | 调小后的现象 | 我的建议 |
|---|---|---|---|---|
| 目标衰减系数decay | 0.9~0.99 | 目标保持很久，改任务困难；近似“固执” | 目标很快被遗忘，系统频繁变卦 | 先0.95起步，观察目标漂移率 |
| 冲突阈值threshold | 0.3~0.5 | 控制介入少，被惯性带跑风险高 | 控制频繁刷存在感，训练抖动大 | 用基线任务的冲突分布分位数反推 |
| 温度temperature | 0.1~0.3 | 切换更随机，探索强但不稳定 | 切换更保守，容易错过该切换的时机 | 与任务不确定性成正比，不确定高取大 |
| 切换惩罚switch_cost | 1e-3~1e-2 | 系统极不愿意切换，串任务严重 | 系统频繁切换，成本高，训练不稳 | 先设到1e-3，再按失败案例往下压 |
我特别想强调一个调参陷阱：不要把四个参数放在一起盲调。正确顺序是先定decay和threshold，因为它们决定“什么时候该控制”；再调temperature和switch_cost，因为这组参数决定“控制介入后切换多激进”。前一组参数错了，后一组怎么调都救不回来。
4.4 验证方法与一个典型失败案例
我用来验证调度器的是一个自己搭的合成环境，本质上是把同一份数据流在三种不同分布之间周期性切换，每个分布持续几百步。评测指标不用一个，而是四个：平均奖励（反映整体效果）、切换成本（反映控制代价）、目标保持率（反映目标是否漂移）、行为熵（反映系统是否过度犹豫）。单看平均奖励很容易被骗，因为偶尔的“稳赢”会掩盖系统在其他区间里的混乱。
调这组模块时我撞过一次很典型的墙。刚开始我为验证控制效果，把threshold设得很低（0.2），想让它多干预一些。结果系统每几十步就触发一次切换，主网络一直在适应新任务，损失曲线在三个分布之间震荡，平均奖励反而比不加控制时还差。后来我把threshold提高到0.4，并且给监控器加了一个分数滑动平均窗口，让冲突信号不因单次极端值而发动切换。改了这两个点之后，系统行为立刻稳下来：冲突监控只在旧任务惯性真正压迫到新任务学习时才发信号。这个教训也直接变成我后面的一项原则：执行功能调度器的价值，不在于“一直控制”，而在于“在冲突点上精准控制”。
5. 常见问题与排查技巧实录
这一节全部来自我在实际搭建和调试过程中的真实记录，不全是学术推导，但比推导更救急。
5.1 控制器本身成了噪声源
最先遇到的问题是加上调度模块后，训练损失抖动得更厉害。一开始我怀疑是切换控制器太激进，后来发现真正的噪声来自冲突监控器：它在每个step里输出的conflict分数高低起伏很大，偶尔一个高冲突值直接触发切换，导致整个主网络的参数更新被突然打乱。解决办法是给conflict分数加一层指数滑动平均（EWMA），平滑窗口设置在10到20步之间。这样保留了对持续偏离的敏感性，同时滤掉单步噪声。如果你看到加了控制反而损失抖动，先检查监控器的原始输出是不是高频翻转，不要急着动主网络的学习率。
5.2 任务切换后旧上下文泄漏
第二个典型问题是，切换信号已经触发，新任务的输入也到位了，但主网络的隐藏状态里还残留着上一个任务的激活模式。表现就是新任务的前几步输出里总带着旧任务的风格。要分两步处理：切换时对隐藏状态做一个和旧任务子空间正交的投影操作，把最相关的旧激活分量临时压低；再把新任务的单位向量注入到推理起点，相当于人工给系统一个“现在开始执行新任务”的初始化信号。这个方法不改变主网络参数，只改变控制信号的注入方式，代价很小但效果明显。
5.3 抑制过强，把有用信息也压掉了
还有一次，模型在处理完任务A后，切换到需要大量感知输入的任务B，前几个episode里B的感知准确率明显下降。我排查了半天，发现是抑制通道松得太晚。我的抑制信号设计成目标冲突解除后自动释放，但实际上旧目标的冲突分数降下来之后，抑制通道还需要额外几步才能把增益恢复到1.0。修这个问题的门道是给抑制模块加一个“解锁信号”：当新目标被GoalBuffer设为最高优先级的那一刻，立刻允许抑制增益快速回升，不用等冲突分数自己掉下来。这个解锁信号要跟切换控制器同步发送，否则就会出现一段“目标已换但抑制没松”的真空窗口。
5.4 评估指标被平均奖励骗了
单独看平均奖励容易产生假象。一次实验里，调度器在多数时间都不触发控制，只在几个关键点上拉回目标，平均奖励看起来和基线几乎持平。但打开日志才发现，如果没有这几个关键控制点，系统早就跑偏到完全不同的策略上了。我现在的经验是：调试日志里至少固定记录两个标量——target_conflict和switch_score。它们比平均奖励早几十步预示系统失控。如果target_conflict持续走高而switch_score一直很低，说明控制器太保守；反过来switch_score高频跳动，说明阈值太灵敏。这两个标量的组合拳，基本能解释九成以上的调度失控问题。
5.5 问题速查表
| 现象 | 检查点 | 优先排查方向 |
|---|---|---|
| 训练损失抖动加剧 | 冲突监控输出是否高频翻转 | 给conflict分数据滑动平均；提高阈值 |
| 新任务起步总带旧任务风格 | 切换信号与上下文清除是否同步 | 切换时正交投影旧激活；注入新目标向量 |
| 新任务感知能力短期下降 | 抑制通道是否释放过慢 | 切换时给抑制模块发同步解锁信号 |
| 目标经常悄悄换掉 | GoalBuffer的decay是否过低 | 提高decay到0.95以上；增加目标再激活周期 |
| 平均奖励平稳但行为偶尔失控 | target_conflict是否持续走高 | 提高监控敏感性，而不是改平均奖励优化目标 |
做执行功能调度器一段时间之后，我最大的一个体会是：控制模块并不是给系统增加知识的，它是给系统减少自由度的。它通过限制“不该做什么”，让“该做的事”更容易冒出来。如果你把它当成一个时刻都要刷存在感的模块，只会让系统在犹豫和震荡里浪费计算；真正称职的控制器，恰恰应该大部分时间都沉默，只在冲突进入危险区时果断说一句话。
最后分享一个小技巧：在把这类控制机制接入更大系统时，我习惯先在日志里同时打印每一步的conflict分数和控制器的stay_prob，再关联到主网络的最终输出质量上跑几天。只要能画出conflict分数和输出质量的负相关曲线，就说明控制模块抓到了有真实语义的信号；画不出相关性，那多半是目标向量选错了，而不是控制逻辑的问题。这时候最该做的不是调参，而是回头重新定义目标表征。
