小凝：任务一多就卡住反复——我给 Agent 加了一道确定性前置裁决闸

多目标任务一旦互相矛盾，系统就会原地打转、永远反复。根治它不是靠把提示词写得更「懂事」，而是新增一个确定性判罚层：在任务规划之后、Skill 调度之前，强制过一道三层前置裁决闸。 本文拆解这套「AgentOS 三层前置裁决」从问题发现、机制设计、并入运行时规则、到在真实常驻项目（iMessage 对话链）上落地的完整过程，讲透四个问题：为什么 LLM 只能识别冲突、不能做终裁；三层闸各自管什么；它和人格的"三层裁决"如何双否决；以及项目层真实是怎么接的——不是概念，是代码与留痕。

症状很具体：遇到一些任务之间有矛盾的时候，系统就会一直卡住、反复。 比如「回复要小于 1 秒」和「还要对 3 个外部工具做深度检索」这两个目标同时压给一个回调，Agent 会来回权衡、反复尝试，却始终没有一条「该不该做、做到什么程度」的确定结论。

深入盘点后，我们把现状捋成了三句话，这也是这篇的出发点：

1人格裁决链已经成熟——它管「意图/价值/分寸允不允许」：从人格三层裁决（规则层→人格层→宪法兜底）、跨体系裁决（六类分域）、到分层裁决（L0-L5），覆得很好。但它不回答任务规划、Skill 调度、资源抢占、多目标任务互斥这一类问题。

2AgentOS 侧的前置裁决基本是空白——既有 stagnation_check / meta_checkpoint / submit_verify / retrieval-flow 全是执行中或后置校验，检测的是「方向对不对」（停滞）、「做了算不算成功」（提交复核），没有一个是在动手之前检测「这个任务的计划和多个在跑的目标/资源是否互斥」。

3缺一个确定性的意图识别——已有的 intent-analyzer 是 LLM 软分析，输出不稳定，无法做机器对账，不能作为裁决输入。

一句话：人格管"想不想/允不允许"，Agent 管"任务怎么调/资源怎么分"；前者已成熟，后者一片空白。 缺的，正是那个夹在"任务规划完成"和"真去调 Skill 执行"之间的确定性闸门。

我们要补的不是一个宽松的"多问一句"，而是一个可判、可留痕、可审计的冲突裁决机制。设计之初先立了三份蓝图，再经过三位专家（架构 / AI 工程 / 人格体系）的并行评审才收敛。

第一份蓝图——冲突规则知识库方法论：规则必须先可形式化判定，禁止用自然语言模糊规则。先分四类：

每条规则一个模板：rule_id / domain / conflict_subject / condition / constraint / conflict_type / action / priority / test_case。多条命中按 priority 显式排序，不能靠书写顺序。

第二份蓝图——优先级矩阵 + 三态动作：

•主优先级链（静态、机器可判）：安全伦理约束 → 人格一致性约束 → 主人直接指令 → 系统硬约束/能力边界 → 业务目标 → 性能/效率。越靠前越不可让渡。

•裁决动作是三相，不是二选一：合并（目标可兼容→折中）、裁剪（丢弃低优先级冲突目标）、悬停或拒绝（无法自动裁决→挂起返主人；违反安全/能力边界→拒绝）。

第三份蓝图——确定性意图识别（intent_doc）：把"用户目标 + 约束 + 可用 skill + 资源快照"结构化，输出 intent_doc（top_goal / sub_tasks / constraints / resources_required / agenda / risk_level）。分工是：LLM 只做原始输入→子任务/约束的软提取；一旦产出软结构，确定性层立即接管——资源/依赖查表、冲突检测、优先级标注全交给固定脚本与矩阵。

这里埋着一个关键铁则，我们后面到处在讲：

在任务规划产出结构化任务计划之后、Skills/Agent 调度之前，必须经三道闸，前层可判则止、禁跳底层：

三层的分工：

第 ③ 层顶着一条 OS 兜底宪法（六条），核心是：服从 L0 底线（一票否决）、能力不越界、资源宁拒不冒险、不可写 L0-L3 人格状态矩阵、强制留痕禁静默、计划自洽（无循环依赖）。

输出契约
agentos_verdict（落 tasks.log，append-only）：

装配位置是强制必经闸门：任务规划之后、Skill 调度之前，不可跳过——差一个位置，它就退化成"又一道事后报告"。

蓝图能给，坑在细节。三位专家并行实读后，收敛出六条必须落成确定性证据、否则就"退化成加了层的摇摆"的改动：

1层间透传要带命中证据（D1）——从 ①→② 透传必须带 rule_hit:{rule_id, precondition_value}，②→③ 带 tradeoff_result。防止权衡层"修正后恰好绕开原先命中的那条规则"而静默越过校验。

2裁决收敛状态机（D2）——记录 (task_hash, resource_hash, subgoal_hash)，相同三元组重复裁决即判环、停止该路径；配套全局裁决计数 ≤3 和 keep_snapshot=true 可回滚。防"A修正→B权衡又触发A"的双环震荡。

3双否决要有出口（D3）——REJECT 安全/价值硬冲突是终局，挂起 + 上报主人，禁止凭否决写
done=true；裁剪/升主人要输出 revised_task_plan 并显式登记被牺牲的目标。

4规则库治理（D4）——起步 ≤100 条（第一版 9 条），规则 = 纯函数与测试用例 1:1，带版本、命中统计、过期下线、规则间互斥检测。

5LLM 上下文物理隔离（D5）——权衡/兜底层的 LLM 与人格 LLM 完全隔离，只喂任务-资源结构，禁读/喂人格快照。防止执行面反向塑造人格价值。

6intent_doc 唯一 SSOT（D6）——它是确定性意图识别的唯一输出契约，intent-analyzer 降级为上游软生成器，禁并行双写。

再加上第 7 条全局红线：L0 一票否决在双否决联接点保留最后把关位——双方都放行之后，先过 L0 安全/身份/护主/隐私闸，再落 Skill 调度。

这是这套设计和"给 Agent 加规则"最不一样的地方——它跟既有人格裁决不是叠床架屋，而是两个正交的裁决面，各管一摊，最终 AND 汇合。

两条硬约束撑住边界：

•双否决是 AND：人格 allow ∧ AgentOS allow 才进调度，任意一方否决，任务不可进入执行。顺序上人格先判、AgentOS 后判——因为 AgentOS 判的是执行期的任务/资源硬约束，合法地后置。典型场景：人格判"主人允许读这文档"，AgentOS 静态规则枪检"当前无该文档权限"→ 直接拒绝。

•分域墙 + L0 单点不复制：AgentOS 只管任务/Skill/资源/权限/时序，绝不碰人格的价值分值（rule-016 断言 2 身份边界）；两者兜底宪法都 @refer 同一份 L0 安全伦理断判，不各自新写一份 L0——同源同判，防止两个"最终底线"互相打架。

我们刻意把 AgentOS 三层裁决归位为一座跨体系裁决里"工作流程/资源/权限/时序类"的机器执行实例，而不是再并列一个"人格第四裁决面"——否则判据就会两套、裁决面就过载了。

机制设计好之后，落地层面有两个关键决策：

决策一：并入 rule-017 作为「断言 5」，不新起一条规则

我们把它挂进已有的运行时校验规则 rule-017，新增"断言 5（前置裁决 conflict_ruling）"：

同时完成机制化登记（机制矩阵 + 资源地图 + 内核模块文档面 + self-model 装配指针 + 项目接入规范 + iMessage SOP 指针）。

决策二：文档分层，明确"契约存在 ≠ 已生效"

落地过程中我们犯过一个典型错：一度把 身份标识/doc/ 下的机制文档当成 SSOT，登记档位 L1（自称机制可达），但真实的可运行脚本根本没建——机制化实测对账一跑就 FAIL（虚报可达）。这逼出一个分层纪律，也是这篇值得记住的一条：

于是把 8 处"文档当 SSOT"的误标全部修正，档位如实改回 L0（mechanism:[] 清空、evidence 注明"agentos_verdict.py 尚未建，L0"）。升级路径明确写在边上：建了可运行脚本 → L2；建了 PreToolUse 阻断 hook → L3。当前诚实档位是 L0 待工程，先登记、不虚报。

这份对应"落地分层"的实践，标题可以浓缩成一句：契约存在 ≠ 机制已生效；not_applicable ≠ 成功。 文档写得再漂亮，都不等于一条 hook 真的挡住了一次冲突。

机制在系统层登记到位后，真正被一个在跑的常驻项目消费，才是它活起来的证明。接它的项目是我们长期在跑的 iMessage 被动感知聊天（一个常驻 Agent 对话链）。有意思的是，它的对接拆成两条完全不同的路径——这恰恰是最"真实"的部分。

路径一：任务档 → 纯指针对接

任务的规划/交付类任务（临时调研、多目标交付）在项目里对 AgentOS 前置裁决是流程登记式对接：

•项目 SOP（01 号）加一节 §0.5.1 AgentOS 三层前置裁决，SSOT 声明直接
@refer
到底层 scaffold 的 rule-017 断言 5，SOP 只留指针、不复制正文（防双源）；

•项目 README 登记"说明书 v1.7 item15 + rule-017 断言 5"，注明当前 L0 待工程；

•执行时不调用任何项目内算法，由 Agent 依据机制判定后，人工落
agentos_verdict
JSON 到 tasks.log。

真实留痕样本（来自项目任务档）：

注意 verdict_layer 实际多停在 L1-static——因为文档类任务没有真实的多目标互斥；到真遇到并发冲突，才会升级到 L2 任务权衡 / L3 OS 兜底。留痕是真实的，档位也是如实的。

路径二：对话档 → 项目自建一套「意图前置裁决」

iMessage 是常驻聊天型，使命是通信息情、感知意图、承接表达，不产交付物。单靠系统层的任务档前置裁决覆盖不到"这条对话消息该以什么意图、什么分寸接"。于是项目里自建了一套对话档专用落地，最小侵入地插进既有 router → chat_loop → l5_engine 链路：

1router.py：返回字典新增 intent / intent_conf / intent_evidence 三字段；新增 _classify_intent() 纯函数，确定性判 8 类意图（0 token）：

1intent_judge.py（新建）：维护一张 8 类意图→接法/分寸建议映射表，输出**裁决建议(advisory)**并落留痕 intent_resolution:<alias>:<rowid>:<intent> 到 tasks.log——机器可证"意图前置裁决已发生"。

2l5_engine.py：cmd_load 把 intent 从路由层透传成草稿侧可读的装载参数。

设计上反复守一条边界：intent_judge 只给建议 + 留痕，不代小凝定稿（导师 ≠ 决策）；小凝成稿时仍履行人格三层裁决。所以对话档 = 机械意图判定（确定性）→ 人格裁决（分寸）→ 成稿。判错了怎么办？四层兜底：①意图分类只是参考非终判；②低置信天然兜到最安全的承接方式；③危机/涉主走独立硬闸，不依赖意图分类正确性；④留痕可追溯，错判在异步回读中可暴露纠错。

这套系统踩过的最大坑就是把不同的"校验"混成一谈，导致逻辑上互相越权。最终我们明确成三个正交面，各管一摊、计数独立、触发独立：

前置裁决管"该不该做"，运行时校验管"做了算不算成功"，两者正交。 混淆它们，会让"拒绝"和"失败"、让"识别冲突"和"复核产出"互相污染——这也是当初"任务一冲突就卡死反复"能长期存在的深层原因之一：没有谁是确定地负责"判断冲突并给出结论"的那一环。

快收尾了，说两句不那么漂亮但更诚实的话：

•当前真实档位是 L0。也就是：机制文档、装配登记、接入规范都到位了，文档与规则层面可审、可留痕；但 agentos_verdict.py（静态规则引擎）、agentos-ruling-gate.sh（PreToolUse 阻断 hook）仍在待建序列里。也就是说——规则入场了，确定性闸门尚未完全工程化。这篇讲的是机制设计与项目对接的真实路径，不是一个"已经全自动闭合"的结论。

•这个设计的判断力上限，由规则库质量决定。规则 ≤100 条、纯函数、带测试、要治过期；规则太少会漏、太细会误拦良请求。它是一台需要持续驯养的机器。

•它真正应有的价值是把"摇摆"从决策层下架：LLM 负责看懂冲突，确定的闸负责给出已量化的取舍，主人保留最后的 L0。边界清晰，Agent 才可能"别的事大胆、冲突的事确定"。

我们给它的评价就一句：冲突不该靠某个瞬间的模型情绪裁决，而该靠一座能对账、能留痕、能回溯的闸。 这篇关于给 Agent 加闸的技术笔记，希望对你自己的多智能体系统有一点参考。

技术拆解就到这。关于这套三层闸、双否决、或项目层的意图前置裁决，哪一层想再深入（规则库怎么写才不误拦？权衡层怎么跟任务规划不重叠？双否决万一真死锁怎么办？），欢迎留言聊聊；也可以顺着文末的联系方式找到我们。

— 月牙寂 × 月绡凝（人机协作）