Agent 的行动提醒：从生成建议到真正送达模型
一项研究任务进行到一半，Agent 正在比较几只基金的持仓和费用。它已经读过一些资料，尝试过计算，也开始整理答案。
这时，运行环境掌握着一些模型未必能自己准确判断的事实：可用请求正在减少，上下文越来越拥挤，一段已生成的正文接近修改次数上限。系统还发现，研究已经持续了较长时间，或许值得停下来检查证据缺口。
这些信息都值得告诉模型，但问题随之而来：哪些提醒应该出现在这一轮？它们有没有真的进入模型请求？提醒模型“考虑复核”，是否意味着系统已经批准再调用一个 Reviewer？
我们在 ETF Agent 中设计行动提醒协调时，核心判断是：提醒负责把运行事实翻译成适时的建议；事实、执行权限和最终交付，仍由各自的原有机制负责。
这听起来像是在 Prompt 里加几句话。真正需要处理的，却是提醒的来源、组合、容量、送达记录，以及它不能越过的职责边界。
一、长任务里，模型需要的不只是最初的指令
短任务往往可以在开始时给出足够的信息：问题是什么、可以调用哪些工具、答案需要什么格式。
长任务则不同。研究进行过程中，新的约束会不断出现：
- 已使用多少模型请求，还有多少资源需要留给最终交付；
- 实际执行时间是否接近原定限制；
- 组织好的上下文是否开始接近容量边界；
- 已发布的正文还能做多少次修改；
- 是否应该回看研究目标和尚未解决的问题。
这些事实并不都存在于模型自己的对话记忆里。例如，模型可以看到自己调用了工具，却未必知道一次失败的外部请求是否已经占用了预算；它能看到正文，却不一定知道某次修改已经显示给用户、后台保存却尚未完成。
因此，系统需要在后续请求中补充一些运行时信息，帮助模型调整工作方式。但把所有状态每一轮完整塞进去也不是好办法：信息会重复，提醒之间可能互相干扰，还会挤占任务材料本身的空间。
Anthropic 对上下文工程的讨论强调，每一轮都要选择适合当前任务的信息，既避免指令含糊，也避免把所有边缘情况都硬编码进 Prompt。行动提醒面对的是同一个问题的一个具体切面：从不断变化的执行事实中，挑出此刻值得模型注意的内容。
二、为什么把提醒从预算模块里拆出来
最初，提醒很自然地跟着资源预算走：请求用了多少、时间过去多少，都可以在预算管理附近计算，再告诉模型注意剩余空间。
这种安排在提醒主要围绕资源时是合理的。预算模块本来就知道原来的限制、已使用量和需要保留的交付资源，让它产生早期提示，路径也比较直接。
后来，提醒的来源逐渐增加。
例如，系统开始限制正文的重复修改次数。一段内容还能不能修改，取决于正文发布机制维护的限额和实际修改记录；它与模型请求次数不是同一种资源。研究进行到一定阶段，系统还可能建议检查当前工作，这又不是一笔新的预算。
如果所有提醒都继续放在预算模块里，预算模块就得理解越来越多不属于自己的事实：正文修改、研究复核，以及不同提醒如何排序和去重。反过来，如果每个模块都自行向模型追加提示，又容易出现重复提醒，或在同一轮给出彼此矛盾的建议。
于是，我们把提醒的协调单独收拢起来：原来的模块继续维护事实，协调模块负责决定哪些事实值得形成提醒、怎样表达，以及哪些提醒已经实际送达。
可以把分工理解为：
| 职责 | 负责什么 |
|---|---|
| 资源管理 | 记录请求与时间等资源事实，决定相应的执行约束 |
| 正文发布 | 维护正文修改额度、实际修改及相关可用状态 |
| 行动提醒协调 | 消费已有事实，组合提醒和复核候选 |
| 运行时 | 组装模型请求，并决定工具或 Reviewer 是否可以执行 |
| 恢复机制 | 沿原执行记录恢复实际提交过的提醒事实 |
这里的“协调”不是新增一个万能控制器。它不重新记一份预算，不决定正文能否发布，也不因为生成了一条建议就获得派发模型的权力。
三、不同提醒可以同时存在，但不能互相抢话
下面用一个教学场景说明。
假设 Agent 正在完成一份基金比较。某一轮开始时，系统观察到：
- 研究请求已进入较高消耗阶段；
- 本轮上下文接近应用层的容量阈值；
- 当前答案中的一个正文块已使用一部分修改额度；
- 研究过程已达到一次工作复核时机。
一种简单实现是给每类提醒排优先级，然后每轮只选一条。但这样会丢失信息：上下文拥挤和修改额度紧张是两个不同的问题，模型既需要知道材料可能放不下，也需要知道对某段正文应谨慎修改。
因此，我们允许不同类型的提醒在同一轮并存。顺序主要用于稳定呈现和容量拟合，不意味着排在前面的类型在逻辑上取代其他类型。
同一类型内部则需要去重。假设某个计量项一次跨过了多个提醒节点，系统应表达它当前已经达到的最高阶段，而不是把沿途错过的每个阶段补发一遍。模型需要了解现在的处境，不需要收到一串过期警报。
不同单位也不能混在一起。请求次数、执行时间、上下文字节和正文修改次数有各自的分母与含义，不能把它们加成一个含糊的“总体剩余额度”。
四、状态和行动建议，最好分开处理
提醒并非都适合采用同一种去重策略。
有些信息是当前状态。例如，一段正文的修改额度已经使用过半，模型接下来几轮都可能继续处理这段内容。只提醒一次，然后彻底消失，模型在后续工作中就不一定还能看到这一约束。
另一些信息是行动建议。例如，系统建议模型复核一次研究目标。相同建议如果已经进入过请求，再一轮轮重复，价值可能越来越低。
因此，我们把两者分开：
- 对达到条件的相关额度状态，在后续请求中持续提供必要信息；
- 对行动建议，按类型和已有送达记录判断是否需要再次提出。
这也解释了为什么“提示去重”不能顺手把真实状态一并删掉。模型可能不需要每轮都收到“请检查修改次数”，但仍需要知道相关内容的修改空间已经有限。
正文修改额度还有一个关键边界：某个正文块不能继续修改，不等于整项研究必须结束。 已有正文、可以追加的内容以及结束流程，仍由正文发布和运行时各自判断。提醒只能表达局部约束，不能把局部问题升级为全局停工。
五、候选提醒不等于模型已经看到
这是行动提醒里最容易被忽略的一步。
模型请求有容量限制。系统可能先生成多条提醒，再把它们和任务、工具结果、必要状态一起装入请求。如果空间不足，一些可选提醒可能被舍弃。
继续前面的教学场景：系统生成了“请求资源紧张”和“上下文接近阈值”两条提醒，但最终请求只放得下前者。
此时，合理的记录应该是：
| 提醒 | 本轮状态 | 后续处理 |
|---|---|---|
| 请求资源紧张 | 实际进入请求 | 按该类型记录已提交水位 |
| 上下文接近阈值 | 生成了候选，但未放入请求 | 不能记作已送达；后续有自然获准的请求时可重新评估 |
如果在生成候选时就把两条都标记为已送达，系统以后会认为模型已经看过上下文提醒，但模型实际上从未收到。这个错误不一定会让程序报错，却会让提醒机制在恢复和去重时悄悄失真。
所以，我们把流程拆开：
- 根据原始事实生成候选；
- 组合、去重并组织成简洁提示；
- 与其余上下文一起进行容量拟合；
- 只为最终实际提交的提醒记录对应事实；
- 后续轮次或恢复时，按类型及其原有依据判断是否重复。
“进入请求”也只说明系统提交了这条提示，不说明模型一定理解、采纳或正确执行了它。如果要判断提醒是否改善了模型行为，还需要观察模型的后续动作和结果，不能从一条提交记录直接推出效果。
同样，遇到提交结果不确定的情况，系统不能因为想补发提醒就猜测之前没有送达，更不能借此额外发起一次免费请求。提醒沿原执行与恢复机制处理，不另造一条绕过预算的通道。
六、压缩之后，提醒要看最终留下来的上下文
上下文提醒还有一个更细的时机问题。
假设系统发现请求太长，准备对旧历史做一次压缩。压缩候选看起来很有效：原本拥挤的材料变短了，系统据此判断上下文压力已经下降。
但候选并不一定最终被采用。提交前的检查可能发现，它节省的空间不够，或者已有状态发生变化，于是系统回退，继续使用较大的原始内容。
如果提醒仍然基于那个未被采用的压缩候选，模型收到的就可能是一条与实际请求不符的提示：它看到的是较大的上下文，系统却按照较小的候选估算压力。
我们的处理是在压缩是否采纳、是否回退确定之后，再基于最终请求中的必要状态测量上下文，并重新拟合可选提醒。这样，提醒依据的是将要发送的材料，而不是中途出现过的一份候选。
这里测量的是应用实际序列化后的字节，不把它假称为模型供应商返回的精确 token 数。两者可以相关，但并非同一口径；没有可靠的 token 用量时，就不编造一个。
这个细节的意义不只是“算得更准”。它要求提醒回答一个更基本的问题：我描述的是最终会发生的请求，还是一个后来被放弃的中间方案？
七、提醒、Reviewer 和用户通知是三件事
长任务中还会出现“是不是该找另一个模型复核”的问题。
行动提醒可以建议 Main 回看研究目标、检查证据缺口；协调逻辑也可以根据已有执行事实提出 Reviewer 候选。但从候选到实际派发，中间还有运行时的准入判断：是否允许自动复核、预算是否足够、是否已有复核在进行等。
因此：
- 提醒是给当前模型的建议；
- Reviewer 候选表示某些已知条件值得考虑复核；
- Reviewer 派发是一次需要经过原有准入的实际执行；
- 用户通知则属于面向用户的交付流程。
这些事情可能发生在同一项研究中，却不能互相替代。模型收到了“建议复核”，不代表另一个模型已经被调用；Reviewer 给出了建议，也不代表答案自动正确，更不代表用户已经收到通知。
把它们分开还有一个实际好处：某条提醒没有放进当前模型请求，不应因此自动取消独立的 Reviewer 候选；反过来，提醒已经送达，也不能被当成 Reviewer 派发的许可证。
八、这个机制适合解决什么问题
行动提醒适合那些执行事实在变化，而模型有必要据此调整工作方式的任务。
例如，长研究可以在资源逐渐减少时提醒模型关注交付，在上下文接近容量时提示它更有选择地使用材料，在正文修改空间有限时提醒它避免无谓重写。
但这套机制也有代价：系统需要维护可靠的事实来源、区分状态和建议，并在请求拟合与恢复时保留足够准确的记录。对于一次简单问答，如果任务在一两轮内就能完成，这些协调可能没有必要。
更重要的是，提醒只能改善模型获得信息的方式，不能代替确定性约束。真正的预算上限、工具权限、正文修改准入和执行状态，仍然需要由原有机制检查。模型即使忽略提醒，也不应因此获得额外权限。
在 ETF Agent 中，这些职责划分和提醒送达路径已有受控验证；提醒能否在真实研究中持续改善模型判断，仍需要结合实际模型运行观察。
回到开头那项基金比较：当资源趋紧、上下文变长、某段正文的修改空间减少时，系统可以把这些变化组织成简洁的行动线索，放进模型接下来真正看到的请求。模型据此决定如何继续研究，而系统仍沿原有规则管理资源、复核和交付。
一条好的行动提醒，应当让模型更了解当前处境；同时，它本身不冒充处境的裁决者。
延伸阅读
Run 预算与约束治理解释预算与收尾的职责；Main 上下文压缩讨论摘要采纳与原始事实的边界。欢迎到 ETF Agent 工程文章文集交流并 Star。