线上系统的精细化调控，是大模型落地中极具挑战的一类场景：决策是序列性的，环境是非平稳的，每一次误判都有真实的线上代价。我们在消息触达系统的发送场景中完成了一次完整的工程实践，把调控的”收”与”放”交给了 LLM Agent——由大模型承担态势理解与方向性决策，由确定性代码承担数值计算与安全约束。本文记录这套系统从概念验证到线上稳定运行的三代架构演进，以及其中沉淀的工程方法论。
一、该触达是否值得执行？
消息触达系统的决策层，需要在每一次下发前完成一次准入判断：该触达是否值得执行。这本质上是一个资源约束下的价值最大化问题——曝光机会是有限资源，透支会损害通道的长期触达能力；系统需要在配额约束下，把曝光分配给期望价值最高的触达。
这一问题的难点在于其序列性与动态性。调控不是一次性的静态求解：每一次”收”与”放”都会改变后续的资源状态，当前的最优决策依赖对线上状态的实时感知与对长期收益的权衡；而环境本身在持续变化，离线定型的策略难以长期保持有效。
因此，这层调控真正需要的是在线的感知与自适应决策能力：实时观测环境状态，在安全边界内执行调整，并从执行反馈中持续修正。这一能力应当如何构建、决策应当由谁来承担，构成了本文讨论的主线。
二、AI 时代，触达决策层能做什么？
端外通知的决策，在工业界通常被拆成三个维度：Who（发给谁）、When（什么时候发）、What（发哪条）。但在这三者之上，还有一个更底层的决策——Whether（要不要发）。这就是发送门控：决定这一次触达是否值得执行。本质上，它和广告系统的 Pacing & Budget Control、推荐系统的 Exposure Allocation 是同一类问题——有限资源下的价值最大化。
工业界对这类问题的主流解法是”离线建模 + 在线规则执行”：离线训好点击率模型、算好门控曲线，线上用固定的反馈控制逻辑去执行。这套范式足够稳定，但有一个根本性的假设——环境是平稳的。现实中，流量分布在变、消息内容质量在漂移、用户活跃节奏随节假日和天气波动，任何一个因素变化，都可能让离线学到的控制参数失效。传统做法的应对是”人盯 + 人调”，本质上是把环境感知和自适应的能力留给了人。
过去一段时间，我们已经在用 AI 写代码、跑分析、训模型、写文档，这些工具在各自的环节都带来了显著提效。但它们是散装的能力——像是一堆好用的螺丝刀，却没有组装成一台自动化机床。一个自然的问题是：能不能把感知、分析、决策、执行串成一个闭环，让 Agent 直接接管发送门控？不是让 AI 辅助人调参数，而是让它成为调控主体——实时感知线上变化，判断该收还是该放，自主执行调整，并从结果中迭代学习。
这恰好是 Agent 最擅长的事情[1]：在动态环境中，基于观测做出决策，执行动作，再从反馈中修正。这正是我们接下来要做的事——用 Agent 驱动 Push 的发送门控。
三、大模型能给决策提供什么能力？
下图是我们期望的一条调控技术演进路线。但这里有个问题：决策本身是序列决策，大语言模型却是 next-token 的概率生成——这种模式真的能找到足够好的决策路线吗？
学界已经给出了肯定的理论回答。Decision Transformer[2]证明：当我们把 (状态, 动作, 回报) 三元组编码为 token 序列，用自回归方式建模条件概率 P(action | desired_return, state_history) 时，模型可以直接输出策略——不需要估值函数，也不需要 Bellman 方程收敛。本质上，序列决策的最优解和条件概率生成在数学上是相通的[3]。广告自动出价中的 AIGB[4]把这一思想落到”预算约束下选择最优出价序列”，做成条件轨迹生成，并已大规模商用。
但我们当前阶段并不是直接走自回归轨迹生成这条路。
原因很简单：轨迹生成需要大量高质量的 [state, action, reward] 离线数据做预训练，而发送门控的状态空间定义、奖励信号设计都还在早期。直接上 Decision Transformer 范式，数据和问题建模都还撑不住。
我们当前的定位，是演进路线的第一步：让 Agent 具备环境感知和简单调控能力——能看到线上流量的实时状态，能基于规则和简单推理做出”收/放”的动作，能从执行结果里拿到反馈。这一步要跨过的，是”从完全静态的离线门控，到具备在线自适应”——它是整条演进路线的地基。
四、工程落地：三代系统的演进
理论可行性和业务动机都明确了，但从”Agent 可以做决策”到”Agent 真的在线上做决策”之间，是一段充满工程踩坑的路。我们经历了三代系统（v1→v2→v3），每一代的复盘中催生了下一代的核心设计。回顾这段历程，本质上是一个对”大模型能力边界”认知不断修正的过程。
v1｜单 Agent 会话
设计思路
最初的想法极其朴素：既然 Agent 能理解数据、能写分析，那我直接开一个持久会话，用定时任务给它发消息，让它看数据、做判断、改门控，不就行了？
整套系统就是几个脚本：一个负责拉起会话，一个按小时触发，把监控系统里的指标贴进对话，让 Agent “聊天式”做决策。
它做对了什么
v1 验证了一件重要的事情：大模型确实能理解流量调控的语义。给它看实验组和对照组的发送量、点击量、点击率，它能正确判断”实验组好于对照，可以继续放开”，或”增量点击率跌破效益底线，应该收紧”。这不是一个需要专门训练的能力——它从预训练知识里，就已经具备了对”约束优化”问题的基本直觉。
它为什么失败了
v1 本质上是一个”人工交互界面”的自动化版本，几乎没有任何工程可靠性：
•无状态管理：上下文完全依赖会话记忆。进程一重启，前面所有的分析、判断、历史数据全部丢失
•无安全边界：Agent 可以输出任何数值——哪怕远超出安全工作区间，系统也会照单执行
•无容错机制：上一轮还没结束时定时任务再次触发，会并发写入导致混乱；网络超时也没有重试
•不可审计：所有决策过程散落在一个不断增长的聊天记录里，无法回溯某一小时为什么做了这个决策
v1 的价值是概念验证：证明了大模型能做流量调控的判断，但距离线上可用差了十万八千里。它像是在实验室里证明了”这个化学反应可以发生”，离工业化生产还差反应器、温控系统和安全阀。
v2｜多 Agent 协作
设计思路
v1 的经验让我们相信模型有决策能力，下一步要解决的是工程可靠性。我们的第一个直觉是：分工。
既然一个 Agent 同时做取数、分析、决策、执行容易出错，那就拆成多个专职角色：
这是一个典型的”研究负责人 + 助手”结构——主 Agent 做综合判断，子 Agent 像研究助手，各司其职。
同时 v2 引入了一套完整的状态管理：一块所有 Agent 共享的状态板，记录当前门控、实验日志和累积指标。我们还把踩过的坑写成一份决策规范，作为提示词注入进去。
它做对了什么
v2 相比 v1 有了质的飞跃：
•状态持久化：共享状态板 + 日志，每轮决策都有记录
•职责分离：取数、执行、分析各自独立，主 Agent 专注推理
•实验框架：建立起实验组 / 对照组的评估体系，有了可对比的效果口径
•自进化机制：日终由独立角色做收盘总结，策略评估器自动计算胜率
v2 跑了大约两周，期间确实产生了有价值的决策——在多个业务日里，Agent 成功识别到可放开的窗口，增量点击率持续高于效益底线。
它为什么失败了
但大约两周后，系统出现了严重的策略震荡，随后被停用。复盘下来，问题不在单次决策的质量，而在系统级的可靠性，集中在五个方面：
问题一：多 Agent 的错误放大效应。取数角色偶尔返回不完整数据（监控超时），主 Agent 不加质疑，基于残缺数据得出”增量点击率暴跌”的误判，执行角色再忠实地写入线上——链路上没有任何环节能纠错。Google DeepMind 的研究结论[5]与此一致：缺乏中心化机制的独立多 Agent 架构，可能把错误放大一个数量级以上。
问题二：会话死锁。v2 依赖持久会话，模型接口一旦超时，会话锁不释放，系统连续多轮停摆、只能人工重启。对按短周期决策的线上系统，这是不可接受的。
问题三：幻觉驱动的”自我说服”。主 Agent 会把样本噪声”发现”成稳定规律；面对”晚间限制放开”的规则，它很少硬闯，而是用冗长的推理链”论证”今天为何应当例外——用推理去”修正”规则。
问题四：通信成本挤占推理空间。在固定的上下文预算下，Agent 间的指令、回传与同步消耗了大量窗口。Google 的实验[5]同样证实：频繁的 Agent 间沟通会显著降低系统整体效果。
问题五：单 Agent 够用之后，再堆 Agent 反而更差。当单 Agent 的任务成功率超过中等水位，继续增加 Agent 数量收益边际递减，甚至为负[5]。本场景核心的”收 / 放”判断单 Agent 已经够用——真正的瓶颈不是推理不够强，而是推理结果没有被约束。
v2 复盘思考
1一份把踩坑写成约束的清单，后来直接成为 v3 约束模块的需求来源
2 实验组 / 对照组 + 增量点击率的评估口径被完整继承
3 两周的决策日志，为后续提炼”已验证规则”提供了样本
4一个关键认知：问题不在于模型的推理能力，而在于我们对它的信任方式
v3｜单 Agent 与约束工程（Harness Engineering）
核心转变
v3 的设计哲学用一句话概括：Agent 做指挥官（选策略），代码做计算器（算数值）。
从多 Agent 的”分而治之”回到单 Agent 的”聚而用之”，但不是退回 v1 的原始状态——而是用约束工程（Harness Engineering）彻底重画了模型和代码的边界。
架构设计
v3 的每轮决策是一个固定的五阶段流水线，其中只有推理阶段使用大模型：
调度器是常驻的普通进程，不依赖任何 Agent 框架。每到决策时刻，它发起一次全新的、无状态的模型请求——不复用会话，不累积上下文。这从根本上消灭了 v2 的会话死锁。
离散策略空间：从连续值到 6 选 1
Agent 不再输出具体的门控数值，而是从 6 个预定义动作里选一个：
| 策略 | 含义 | 门控如何变 | 适用条件 |
|---|---|---|---|
| HOLD | 维持不变 | 不变 | 增量点击率在效益底线附近，或数据不可靠 |
| TIGHTEN_SMALL | 小幅收紧 | 小步上调 | 增量点击率略低于效益底线，轻微止损 |
| TIGHTEN_LARGE | 大幅收紧 | 大步上调 | 增量点击率明显低于效益底线，快速止损 |
| LOOSEN_SMALL | 小幅放开 | 小步下调 | 增量点击率明显高于效益底线，可以多发 |
| LOOSEN_LARGE | 大幅放开 | 大步下调 | 增量点击率远高于效益底线，大胆放开 |
| EMERGENCY_RECOVER | 紧急恢复 | 重置为默认安全值 | 数据异常或效果严重恶化 |
为什么离散化？从算法角度看，这是动作空间的降维。v2 里 Agent 直接输出连续门控值，动作空间近乎无限，任何一个不合理的点都可能被幻觉生成出来；线上真正允许落地的，只有一条预先划定的安全工作区间。离散化之后只剩 6 个动作，数值由代码按固定步长去算，并再次钳位回同一条区间。约束检查也从”无穷点”变成”有限动作”。这和棋类程序的思路类似——盘面很大，但合法落子是有限的。
约束模块：9 项硬检查
这是 v3 和 v2 最根本的区别。约束是一组普通代码实现的检查，Agent 的任何输出都必须通过全部 9 项才能执行：
每一项检查都对应 v2 时期的一个真实案例。约束不是凭空设计的安全机制，而是从失败里长出来的免疫系统。更重要的是，它引入了渐进信任：
| 阶段 | 最大单步 |
|---|---|
| 试运行第一周 | 只允许小步 |
| 第二周 | 放开到大步 |
| 正式运行 | 维持大步上限 |
这和金融行业的”新交易员限额”异曲同工：先给小额度跑一周，没出事再放大。
状态管理：文件是记忆，不是会话
v3 彻底抛弃了”会话即记忆”。所有状态落在几类文件里：
| 文件 | 角色 | 读写模式 |
|---|---|---|
| 状态快照 | 当前运行状态 | 每轮覆盖写 |
| 决策日志 | 按日归档的决策记录 | 只追加 |
| 参数配置 | 运行参数 | Agent 只读，人工修改 |
| 共享状态板 | 状态中心 + 人机通信 | 双方可写 |
| 日终蒸馏报告 | 当日沉淀的规则 | 收束时生成，次日启动时读取 |
核心原则：进度持久化在文件系统上，而不是上下文窗口里。进程重启、接口超时、网络断连——任何故障之后，下一轮读文件即可完整恢复。
交易日制度：开盘、交易、收盘
v3 把 Agent 的运行节奏设计成类似交易所的模式：
开盘 ── 读昨日蒸馏报告 + 隔夜指令 → 初始化今日门控
│
第 1 轮 ─┐
第 2 轮 │
第 3 轮 │ 日间按固定时刻多轮
⋮ │ 每轮: Observe → Think → Guard → Apply → Log
… │
最后一轮─┘
│
收盘 ── 恢复默认门控 → 调用蒸馏 Agent → 生成报告
为什么要固定时刻？因为门控从决策到生效，存在一段分钟级延迟。如果决策时刻漂着走，就无法精确知道”我现在看到的数据，对应的是哪一次门控的效果”。v2 在这里吃过大亏——刚调完就看数，看到的仍是旧门控的效果，误以为”调整没用”，然后又调回去，形成震荡。
v3 的延迟保护（上述第 8 项）从代码层面卡住了这个问题：上轮刚调过，本轮强制 HOLD，至少等一个完整观察窗口再评估。
蒸馏闭环：从经验到知识的沉淀
每日收盘，一个独立的蒸馏 Agent 被触发（注意：不是主 Agent 自己做蒸馏——职责要分开）。它的输入是当天全部决策日志，输出是一份蒸馏报告：
蒸馏出的知识通过检索注入次日的推理模块——不是把整个知识库塞进提示词，而是根据当前状态取相关条目。这就是渐进式披露（Progressive Disclosure）：领域知识”说明书化”，模型按需阅读，比多 Agent 更轻，比全量检索更准。
知识库从空开始，逐步积累起一组有多日数据支撑的已验证规则，外加少量待验证假设。其中一条已经比较稳：
白天把门控放得过低，会把当日配额提前耗尽；晚间可用配额不足，增量点击率表观恶化——这往往说明配额已被充分利用，而不是策略突然失效。
4.4 三代系统的演化总结
演化的本质认知
这三代系统的演化，本质上是对一个问题的认知不断深化：大模型的能力边界在哪里？
•v1 的假设：模型什么都能做 → 结论：能做判断，但没有工程可靠性
•v2 的假设：多个模型协作能做得更好 → 结论：错误会被放大，通信会挤占推理空间
•v3 的结论：模型擅长理解复杂局势、做方向性判断，不擅长遵守规则和精确计算。让它做它擅长的，其他交给代码。
用一个公式表达：
系统可靠性 = 模型的推理能力 × 代码的约束能力
v2 试图通过加更多 Agent、更长提示词来抬升系统可靠性，结果发现模型端的上界是它的注意力极限——概率性的。v3 转而抬升代码端（约束、离散化、无状态调度），代码的上界是实现是否正确——确定性的。
五、核心工程洞察
5.1 约束工程 > 提示工程
对于线上决策系统，提示工程的可靠性上界是模型的注意力极限（概率性）；约束工程的可靠性上界是代码的正确性（确定性）。
Agent 的价值不在于它能”遵守规则”——这件事代码做得比它好一万倍。Agent 的价值在于它能理解复杂局势、权衡多维信号、做出有温度的方向性判断。v3 让 Agent 专注做它擅长的事，把它不擅长的事交给代码。
5.2 文件是记忆，会话是幻觉
Agent 工程的核心矛盾：状态应该活在”文件”里，而不是”会话”里。
会话会断、会溢出、会死锁；文件是持久的、可审计的、可恢复的。v3 的每一轮都是无状态的——调度器读快照恢复上下文，调用模型拿到决策，再写回文件。进程可以随时杀死、随时重启，不丢失任何状态。
5.3 渐进式能力披露
不要一次性把所有知识塞进提示词。Agent Skills 的理念是渐进式披露（Progressive Disclosure）——把领域知识封装成独立的技能文件，主 Agent 运行中缺什么读什么。先通过目录概览定位，缺少知识时再加载下一块。
这是从多 Agent 的”分而治之”到 Agent Skills 的”聚而用之”的核心转变：
| 维度 | 多 Agent | Agent Skills |
|---|---|---|
| 知识注入 | 拆到各子 Agent | 文件系统按需加载 |
| 上下文 | 割裂 / 有损传输 | 全局一致 |
| 维护成本 | 高（多节点协调） | 低（单 Agent + 技能文件） |
| 复用性 | 往往要重新构建 | 跨任务即插即用 |
5.4 信任要像贷款一样渐进释放
v3 的渐进信任不是可选功能，而是必需的工程纪律。任何新上线的 Agent 系统，初始权限都应该被严格限制，靠持续稳定运行来”赚取”更大的操作空间。这和强化学习里探索 / 利用的权衡本质相同：初期保守探索，积累信心后再逐步放开。
六、未来展望
当前这套 Agent 调控，解决的是”从完全静态，到具备在线自适应”的那一跃。它还不是终态，但往哪走已经清楚：
每一步都是下一步的数据基础和问题定义。眼下这套在线调控，除了直接产生业务价值，也在为未来的生成式决策积累最关键的资产——高质量、结构化、带有收益信号的决策轨迹。
参考文献
[1]Wang et al., “A Survey on Large Language Model Based Autonomous Agents”, Frontiers of Computer Science, 2024
[2]Chen et al., “Decision Transformer: Reinforcement Learning via Sequence Modeling”, NeurIPS 2021
[3]Lee et al., “Supervised Pretraining Can Learn In-Context Reinforcement Learning (Decision-Pretrained Transformer)”, NeurIPS 2023
[4]Guo et al., “AIGB: Generative Auto-bidding via Conditional Diffusion Modeling”, KDD 2024
[5]Google DeepMind, “Towards a Science of Scaling Agent Systems”, 2025
本文作者@高德技术。原文链接：https://mp.weixin.qq.com/s/CaI0Itskw4p–kKEjOtUDA