


> 让 LLM 更聪明不是唯一的路。让它只做生成，把管理交给确定性规则——这条路可能更便宜，也更可预期。

---

## 一、LLM Agent 的两个根本矛盾

基于 LLM 的 Agent 系统在实践中面对两个结构性问题：

**矛盾一：上下文膨胀。**

Agent 每执行一步，对话历史增长一轮。下一次调用，历史重新输入。多 Agent 场景中，每个 Agent 的上下文窗口被其他 Agent 对话残留填充。输入 token 成本远高于输出 token 成本，且随调用轮次线性增长。

**矛盾二：行为漂移。**

LLM 是一个无状态的、注意力资源有限的概率计算工具。没有办法在计算前判断用户每次输入的真实需求。因为每次计算的注意力资源有限，如果输入有噪音，必然对计算结果产生负面影响，而且浪费算力。

---

## 二、认知局部性：态控的架构根基

态控的出发点是让模型每次计算的内容最大化跟用户的任务目标匹配。

一个人类专家在处理复杂任务时，工作台面上不会堆满所有文件。他会把当前任务需要的资料放在视线范围内，其他项目的东西收进抽屉，完成后换下一个任务的资料。这不叫"能力不足"，这叫高效认知策略。人类工作记忆的容量约 4 个独立组块（Cowan, 2001）——任何信息处理主体在任意时刻的最优输入，是当前目标下的最小充分条件集，不是全集。

LLM 推理阶段的注意力机制也在印证同一个规律：中部信息召回率显著低于头尾，上下文越长，幻觉率单调递增。喂全局跟注意力机制对着干。

态控做的事就是把这个认知规律从人类搬到 AI 系统设计里——不是在 prompt 里告诉模型"你注意看这一段"，上下文裁剪权在概率推理外部、在确定性规则里。决定的是模型针对当次输入所需要的最匹配的内容范围。

---

## 三、房间的来源：从场景的流程中来

房间来自智能体需要处理的场景。

一个记账智能体的工作流程是这样的：用户说"今天买了猫粮 35 块"→ 意图识别 → 提取字段 → 确认金额 → 落盘记录 → 完成。这个流程中的每一步都是一个独立的子任务——意图识别只需要知道有哪些已知 intent、提取字段只需要知道有哪些字段要采、确认金额只需要值域校验——没有任何一个步骤需要"整个记账系统的全部规则和历史"。

态控的做法是，场景设计者把流程中的每个环节封装成一个独立的房间。每个房间里，模型只遵守一套针对此环节定制的规则（环节宪法），只看到与此环节相关的上下文，只处理此环节的任务。处理完一个环节，调度器把结果落盘，用户和模型进入下一个房间。

态控里的"房间"是对真实工作流程的映射。现实中的工作是一步一步做的，每步只需要当前步骤的信息。态控的做法就是不让 LLM 在巨大的上下文里自己判断"什么跟当前任务有关"，而是按流程事先切好，调度器根据用户的输入按路由表的规则选择房间。

房间的数量和内容由场景的复杂度决定，不是由态控架构规定。一个简单的记账场景可能有 5 个房间（识别→采集→确认→执行→完成），一个复杂的全屋定制设计可能有 16 个。态控提供的是房间的定义规范（宪法 + 契约 + 路由 + 存储四要素）和房间之间的切换纪律——场景设计者决定有多少房间、每个房间做什么。

---

## 四、三体分工：管理的事不交给做事的人

态控把 Agent 系统拆成三个独立组件，各自有不可互相替代的职责。

**态控调度器（DET）**：管理路由和全量记录。用户切任务时，调度器查路由表决定进哪个房间，不调 LLM。状态转移是离散决策，不需要概率推理。同时负责把所有对话、进度快照、规则变更记录写入 contractStore——崩溃恢复依赖的不是模型记忆，是落到物理存储的结构化数据。

**上下文管理器**：管理 prompt 的组装。它不"理解"对话内容——只做三件事：按当前任务的规则路径匹配相关约束、按优先级排序决定注入哪些、拼成 prompt 并做 token 预算分配。

**LLM 模型**：管理环节内的对话交互。追问、采集、意图识别、内容生成——这些是真正需要概率推理的部分。模型在给定的上下文和规则下自由交互，但输出的结构必须符合契约 schema，不符合的被下一道 DET 复验拦截。

这套分工的核心纪律只有一句：**确定性的事交给确定性程序，概率的事交给概率模型。**

---

## 五、房间隔离：上下文隔离不是 prompt 裁剪

所有主流框架的"上下文隔离"都是在 prompt 层面裁剪消息——决定不给 LLM 看哪些历史。这不叫隔离，叫选择性遗忘。被"遗忘"的内容仍然在应用内存里、在 Python 进程变量里、在序列化的对话历史里。LLM 不是"不可能看到"，只是"这次没传"。

态控的回应是把每个任务中的细分环节定义为独立的**房间**。切换房间时：

1. 当前房间的推理会话被终止回收
2. 房间状态被归档进 contractStore（进度快照 + 对话日志 + 规则变更）
3. 进入其他房间就继续此房间上次用户退出前的状态，或者创建全新的推理会话

换一个房间 = 前一个房间在推理引擎里不存在了。不是"藏起来"，是"已经回收"。新房间的 LLM 会话从最后一次对话结束开始或者从零初始化，旧房间的 key-value 对没有任何残留。

但回收不是目的——可恢复才是。态控用四个支柱支撑完整的自由切换：

- **全量记录**：每个房间每轮对话按规则存储，切换不丢内容
- **对话快照**：每个环节收敛时的结构化字段快照，回到房间时秒级恢复
- **规则隔离**：每个房间只从自己的变更历史里提炼规则，记账不会污染写诗
- **产出物索引**：跨房间可发现其他房间的产出物，但不注入对话原文——元数据层共享，数据层隔离

---

## 六、taskType 双模式：所有任务只有两种收敛空间

态控做出的一个关键设计决策是把所有 Agent 任务环节按"收敛空间的性质"分成两类。

**field_based（基于字段）**：收敛空间是离散的、可枚举的参数集合。目标是从有限候选中定位唯一正确值。存在客观正确答案，可被 DET 值域校验验证。典型场景：记账、改参数、表单填写。

**topic_based（基于主题）**：收敛空间是连续的、不可枚举的语义空间。目标是在受约束的主题空间内采样一个满足条件的样本。不存在唯一正确答案，用格式约束 + 主题边界检查。典型场景：写诗、写专利、角色扮演。

这个二分法不是学术分类。它是态控所有后续设计决策的逻辑起点——跨节点记忆用 sessionCheckpoint 还是 topicEvolution、规则匹配用 stepName 精确匹配还是 topicPath 语义匹配、校验方式是值域硬规则还是格式 + 边界软约束、追问策略是按预定义字段顺序还是按主题探索路径——全部收敛到这一个二分法上。

混合型任务（如"写一首七言绝句"——诗歌创作是 topic_based，格式约束是 field_based）用"主 taskType 决定记忆载体，子约束附加在末端校验"的策略处理。

---

## 七、降级链：不用 LLM 判 LLM

态控通过校验"合规性"来间接保证智能体处理结果的确定性底线。

四项降级链全部由 DET 执行：

- **L1 结构校验**：JSON parse + Schema 校验，拦截格式错误
- **DET 值域复验**：时间格式、必填字段，拦截值域越界
- **logprobs 检查**：从 API 获取真实概率分布做阈值裁决，拦截低置信度输出
- **硬编码兜底**：前三道都失败时熔断，硬回复不调 LLM

四个检查全部是确定性计算。不是"让模型判断自己输出的质量"——是"让 DET 检查模型输出是否符合预设约束"。评价体系从"对不对"降级为"合不合规"，合规是确定性问题。

偏离检测同样是双层确定性设计：第一层，根宪法强制注入 prompt 头部，定义"当前房间的本职任务"作为优先约束；第二层，偏离标记后由 ANALYZING 从零重新做意图识别——不是"检查 IN_SESSION 判断对不对"，是两个独立节点之间的自然信息流。

---

## 八、工具分层发现：认知局部性在工具层的落地

智能体工具分三层：

- **必用工具**：完整定义，常驻上下文
- **工具清单**：轻量级目录，所有工具的名字 + 一句话描述，每次注入
- **选用工具**：系统级工具库，按需加载，模型从清单选中后调度器加载完整定义

三层 + Two-Phase Selection（Search → Load → Execute），就是信息筛选的分层策略：只把最相关的信息以最小必要量推到上下文的最前端。

态控的六个参考工具（大耳朵语音入口、校对哨兵输入质检、白板过程隔离、对照镜修改裁决、小山精准编辑、屏幕官沉浸阅读）是这个分层体系的具体实例。它们不是六个独立产品，是认知局部性原则在不同环节上的落地变体。

---

## 定位与已知局限

态控是一份智能体设计方案。它定义的是一个 Agent 系统在上下文管理、状态路由、记忆治理这三个维度上的设计原则和组件合约。实现层可变——语言、框架、数据库、模型选型——架构层固定的是三体分工的边界、房间切换的纪律、降级链必须为确定性计算的核心约束。

已知局限：

1. **零生产验证**：两份参考实现（富贵小安记账、杂碎本片段管理）在个人使用层面验证了设计思路，但无多用户生产环境数据
2. **logprobs 依赖**：降级链的置信度检查依赖 API 暴露真实概率分布，部分国产模型 API 不支持
3. **无评估体系**：路由准确率、任务完成率、单任务 token 成本均无自动化度量方案。P 反馈控制的稳态目标值依赖人工标注管线
4. **复杂度门槛**：全量规格定义约 70 页，面向场景设计者而非终端开发者

---

让 LLM 更聪明不是唯一的路。让它只做生成，把管理交给确定性规则——这条路可能更便宜，也更可预期。

# 态控架构：一种确定性调度智能体方案

架构设计

人工智能

后端

LLM智能体系统面临上下文膨胀和行为漂移两大结构性问题。态控架构通过房间隔离、三体分工等设计，将确定性规则与概率推理分离，实现高效任务处理。采用认知局部性原则，按流程切分任务环节，每个房间仅处理当前步骤信息，降低算力消耗。系统通过确定性校验保证输出合规性，实现稳定可控的智能体行为。

结构化数据

数据库

智能体

路由

Python

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

# 态控架构：一种确定性调度智能体方案-腾讯云开发者社区-腾讯云

# 态控架构：一种确定性调度智能体方案

# 态控架构：一种确定性调度智能体方案

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐