一项研究任务进行到一半，Agent 正在比较几只基金的持仓和费用。它已经读过一些资料，尝试过计算，也开始整理答案。
这时，运行环境掌握着一些模型未必能自己准确判断的事实：可用请求正在减少，上下文越来越拥挤，一段已生成的正文接近修改次数上限。系统还发现，研究已经持续了较长时间，或许值得停下来检查证据缺口。
这些信息都值得告诉模型，但问题随之而来：哪些提醒应该出现在这一轮？它们有没有真的进入模型请求？提醒模型“考虑复核”，是否意味着系统已经批准再调用一个 Reviewer？
我们在 ETF Agent 中设计行动提醒协调时，核心判断是：提醒负责把运行事实翻译成适时的建议；事实、执行权限和最终交付，仍由各自的原有机制负责。
这听起来像是在 Prompt 里加几句话。真正需要处理的，却是提醒的来源、组合、容量、送达记录，以及它不能越过的职责边界。
一、长任务里，模型需要的不只是最初的指令
短任务往往可以在开始时给出足够的信息：问题是什么、可以调用哪些工具、答案需要什么格式。
长任务则不同。研究进行过程中，新的约束会不断出现：
- 已使用多少模型请求，还有多少资源需要留给最终交付；
- 实际执行时间是否接近原定限制；
- 组织好的上下文是否开始接近容量边界；
- 已发布的正文还能做多少次修改；
- 是否应该回看研究目标和尚未解决的问题。
这些事实并不都存在于模型自己的对话记忆里。例如，模型可以看到自己调用了工具，却未必知道一次失败的外部请求是否已经占用了预算；它能看到正文，却不一定知道某次修改已经显示给用户、后台保存却尚未完成。
因此，系统需要在后续请求中补充一些运行时信息，帮助模型调整工作方式。但把所有状态每一轮完整塞进去也不是好办法：信息会重复，提醒之间可能互相干扰，还会挤占任务材料本身的空间。
Anthropic 对上下文工程的讨论强调，每一轮都要选择适合当前任务的信息，既避免指令含糊，也避免把所有边缘情况都硬编码进 Prompt。行动提醒面对的是同一个问题的一个具体切面：从不断变化的执行事实中，挑出此刻值得模型注意的内容。
二、为什么把提醒从预算模块里拆出来
最初，提醒很自然地跟着资源预算走：请求用了多少、时间过去多少，都可以在预算管理附近计算，再告诉模型注意剩余空间。
这种安排在提醒主要围绕资源时是合理的。预算模块本来就知道原来的限制、已使用量和需要保留的交付资源，让它产生早期提示，路径也比较直接。
后来，提醒的来源逐渐增加。
例如，系统开始限制正文的重复修改次数。一段内容还能不能修改，取决于正文发布机制维护的限额和实际修改记录；它与模型请求次数不是同一种资源。研究进行到一定阶段，系统还可能建议检查当前工作，这又不是一笔新的预算。
如果所有提醒都继续放在预算模块里，预算模块就得理解越来越多不属于自己的事实：正文修改、研究复核，以及不同提醒如何排序和去重。反过来，如果每个模块都自行向模型追加提示，又容易出现重复提醒，或在同一轮给出彼此矛盾的建议。
于是，我们把提醒的协调单独收拢起来：原来的模块继续维护事实，协调模块负责决定哪些事实值得形成提醒、怎样表达，以及哪些提醒已经实际送达。
可以把分工理解为：
这里的“协调”不是新增一个万能控制器。它不重新记一份预算，不决定正文能否发布，也不因为生成了一条建议就获得派发模型的权力。
三、不同提醒可以同时存在，但不能互相抢话
下面用一个教学场景说明。
假设 Agent 正在完成一份基金比较。某一轮开始时，系统观察到：
- 研究请求已进入较高消耗阶段；
- 本轮上下文接近应用层的容量阈值；
- 当前答案中的一个正文块已使用一部分修改额度；
- 研究过程已达到一次工作复核时机。
一种简单实现是给每类提醒排优先级，然后每轮只选一条。但这样会丢失信息：上下文拥挤和修改额度紧张是两个不同的问题，模型既需要知道材料可能放不下，也需要知道对某段正文应谨慎修改。
因此，我们允许不同类型的提醒在同一轮并存。顺序主要用于稳定呈现和容量拟合，不意味着排在前面的类型在逻辑上取代其他类型。
同一类型内部则需要去重。假设某个计量项一次跨过了多个提醒节点，系统应表达它当前已经达到的最高阶段，而不是把沿途错过的每个阶段补发一遍。模型需要了解现在的处境，不需要收到一串过期警报。
不同单位也不能混在一起。请求次数、执行时间、上下文字节和正文修改次数有各自的分母与含义，不能把它们加成一个含糊的“总体剩余额度”。
四、状态和行动建议，最好分开处理
提醒并非都适合采用同一种去重策略。
有些信息是当前状态。例如，一段正文的修改额度已经使用过半，模型接下来几轮都可能继续处理这段内容。只提醒一次，然后彻底消失，模型在后续工作中就不一定还能看到这一约束。
另一些信息是行动建议。例如，系统建议模型复核一次研究目标。相同建议如果已经进入过请求，再一轮轮重复，价值可能越来越低。
因此，我们把两者分开：
- 对达到条件的相关额度状态，在后续请求中持续提供必要信息；
- 对行动建议，按类型和已有送达记录判断是否需要再次提出。
这也解释了为什么“提示去重”不能顺手把真实状态一并删掉。模型可能不需要每轮都收到“请检查修改次数”，但仍需要知道相关内容的修改空间已经有限。
正文修改额度还有一个关键边界：某个正文块不能继续修改，不等于整项研究必须结束。 已有正文、可以追加的内容以及结束流程，仍由正文发布和运行时各自判断。提醒只能表达局部约束，不能把局部问题升级为全局停工。
五、候选提醒不等于模型已经看到
这是行动提醒里最容易被忽略的一步。
模型请求有容量限制。系统可能先生成多条提醒，再把它们和任务、工具结果、必要状态一起装入请求。如果空间不足，一些可选提醒可能被舍弃。
继续前面的教学场景：系统生成了“请求资源紧张”和“上下文接近阈值”两条提醒，但最终请求只放得下前者。
此时，合理的记录应该是：
如果在生成候选时就把两条都标记为已送达，系统以后会认为模型已经看过上下文提醒，但模型实际上从未收到。这个错误不一定会让程序报错，却会让提醒机制在恢复和去重时悄悄失真。
所以，我们把流程拆开：
- 根据原始事实生成候选；
- 组合、去重并组织成简洁提示；
- 与其余上下文一起进行容量拟合；
- 只为最终实际提交的提醒记录对应事实；
- 后续轮次或恢复时，按类型及其原有依据判断是否重复。
“进入请求”也只说明系统提交了这条提示，不说明模型一定理解、采纳或正确执行了它。如果要判断提醒是否改善了模型行为，还需要观察模型的后续动作和结果，不能从一条提交记录直接推出效果。
同样，遇到提交结果不确定的情况，系统不能因为想补发提醒就猜测之前没有送达，更不能借此额外发起一次免费请求。提醒沿原执行与恢复机制处理，不另造一条绕过预算的通道。
六、压缩之后，提醒要看最终留下来的上下文
上下文提醒还有一个更细的时机问题。
假设系统发现请求太长，准备对旧历史做一次压缩。压缩候选看起来很有效：原本拥挤的材料变短了，系统据此判断上下文压力已经下降。
但候选并不一定最终被采用。提交前的检查可能发现，它节省的空间不够，或者已有状态发生变化，于是系统回退，继续使用较大的原始内容。
如果提醒仍然基于那个未被采用的压缩候选，模型收到的就可能是一条与实际请求不符的提示：它看到的是较大的上下文，系统却按照较小的候选估算压力。
我们的处理是在压缩是否采纳、是否回退确定之后，再基于最终请求中的必要状态测量上下文，并重新拟合可选提醒。这样，提醒依据的是将要发送的材料，而不是中途出现过的一份候选。
这里测量的是应用实际序列化后的字节，不把它假称为模型供应商返回的精确 token 数。两者可以相关，但并非同一口径；没有可靠的 token 用量时，就不编造一个。
这个细节的意义不只是“算得更准”。它要求提醒回答一个更基本的问题：我描述的是最终会发生的请求，还是一个后来被放弃的中间方案？
七、提醒、Reviewer 和用户通知是三件事
长任务中还会出现“是不是该找另一个模型复核”的问题。
行动提醒可以建议 Main 回看研究目标、检查证据缺口；协调逻辑也可以根据已有执行事实提出 Reviewer 候选。但从候选到实际派发，中间还有运行时的准入判断：是否允许自动复核、预算是否足够、是否已有复核在进行等。
因此：
- 提醒是给当前模型的建议；
- Reviewer 候选表示某些已知条件值得考虑复核；
- Reviewer 派发是一次需要经过原有准入的实际执行；
- 用户通知则属于面向用户的交付流程。
这些事情可能发生在同一项研究中，却不能互相替代。模型收到了“建议复核”，不代表另一个模型已经被调用；Reviewer 给出了建议，也不代表答案自动正确，更不代表用户已经收到通知。
把它们分开还有一个实际好处：某条提醒没有放进当前模型请求，不应因此自动取消独立的 Reviewer 候选；反过来，提醒已经送达，也不能被当成 Reviewer 派发的许可证。
八、这个机制适合解决什么问题
行动提醒适合那些执行事实在变化，而模型有必要据此调整工作方式的任务。
例如，长研究可以在资源逐渐减少时提醒模型关注交付，在上下文接近容量时提示它更有选择地使用材料，在正文修改空间有限时提醒它避免无谓重写。
但这套机制也有代价：系统需要维护可靠的事实来源、区分状态和建议，并在请求拟合与恢复时保留足够准确的记录。对于一次简单问答，如果任务在一两轮内就能完成，这些协调可能没有必要。
更重要的是，提醒只能改善模型获得信息的方式，不能代替确定性约束。真正的预算上限、工具权限、正文修改准入和执行状态，仍然需要由原有机制检查。模型即使忽略提醒，也不应因此获得额外权限。
在 ETF Agent 中，这些职责划分和提醒送达路径已有受控验证；提醒能否在真实研究中持续改善模型判断，仍需要结合实际模型运行观察。
回到开头那项基金比较：当资源趋紧、上下文变长、某段正文的修改空间减少时，系统可以把这些变化组织成简洁的行动线索，放进模型接下来真正看到的请求。模型据此决定如何继续研究，而系统仍沿原有规则管理资源、复核和交付。
一条好的行动提醒，应当让模型更了解当前处境；同时，它本身不冒充处境的裁决者。
延伸阅读
Run 预算与约束治理解释预算与收尾的职责；Main 上下文压缩讨论摘要采纳与原始事实的边界。欢迎到 ETF Agent 工程文章文集交流并 Star。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
A study mission is in progress, and Agent is comparing the holdings and costs of several funds. It has read some information, tried calculations, and started to collate answers.
At that time, the operating environment was informed by the fact that some models might not necessarily be accurate: the number of available requests was decreasing, context was becoming more crowded and a generation of text was close to the maximum number of changes. The system also found that the study had lasted a long time and that it might be worth stopping to examine the evidence gaps.
This information is worth telling the model, but the question follows: which reminders should be present in this round? Did they actually request access to the model? Reminding the model to “consider reviewing” does it mean that the system has approved the call for another Reviewer?
When we designed the coordination of action alerts in ETF Argentina, the core judgement was that it was responsible for translating operational facts into timely recommendations, and that fact, implementation of permission and eventual delivery remained the responsibility of their respective mechanisms.
That sounds like a few words in Prompt. What really needs to be addressed is the source, combination, capacity, service record of the reminder, and the line of duty that it cannot cross.
I. In a long mission, the model requires more than an initial instruction.
Short assignments can often begin with sufficient information: what the questions are, what tools can be called upon, and what format the answers need.
Long missions are different. In the course of the study, new constraints will arise:
- How many model requests have been used and how much resources need to be left for final delivery;
- Whether the actual time frame for implementation is close to the original limit;
- Whether organized context is beginning to approach the capacity boundary;
- How many changes can be made to the text of publish;
- Whether research objectives and outstanding issues should be looked back at.
These facts are not all in the model's own memory of dialogue. For example, the model can see itself moving the tool without necessarily knowing whether a failed external request has taken up the budget; it can see the text, but it may not know that a change has been shown to the user and that the back-office preservation has not yet been completed.
Therefore, the system needs to add some running-time information to the follow-up request to help the model adjust its working methods. However, it would not be a good way to insert a complete round of all states: information would be repeated, reminders might interfere with each other and the mission material itself would be crowded.
Anthropic ' s discussion of the context project emphasizes that each round selects information suitable for the current task, avoiding both vague instructions and hard-coding of all edges into Prompt. The action reminds us of a specific facet of the same problem: the selection of elements that deserve the attention of the model at this point in time from changing implementation facts.
II. WHY THE BREATHING FROM THE BUDGET module
Initially, the reminder followed the resource budget quite naturally: the amount of time requested and the amount of time spent could be calculated in the vicinity of budget management, and the model could then be advised of the remaining space.
Such an arrangement would be reasonable in reminding the focus on resources. The budget module was already aware of the original limitations, the amount of use and the delivery resources that needed to be retained, giving it early warning and a more direct path.
Subsequently, the sources of reminders have gradually increased.
For example, the system began to limit the number of repeated changes in the body. A paragraph could be modified depending on the limits and actual record of changes maintained by the publish mechanism in the body; it was not the same resource as the number of model requests. At some stage of the study, the system may also recommend that the current work be checked, which is not a new budget.
If all reminders continue to be placed in the budget module, the budget module will have to understand the fact that more and more are not in its own right: text changes, research reviews, and how different reminders are sequenced and weighed. Conversely, if each module adds its own tips to the model, it is prone to repeated reminders or conflicting recommendations in the same round.
Thus, we bring together the coordination of reminders: the original module continues to preserve the facts, and the coordination module is responsible for determining which facts are worthy of being reminded, how they are to be expressed and which are actually served.
The division of labour can be understood as:
Coordination here is not a new one. It does not re-record a budget, does not determine whether the text can be publish, nor does it have the power to issue the model because a proposal was generated.
III. Different reminders may exist at the same time, but cannot speak to each other
Here's a teaching scene.
Assuming that Agent is completing a fund comparison. At the beginning of a round, the system observed:
- The study request is at a higher consumption stage;
- The current round of context approaches the capacity threshold for the application layer;
- A body block of the current answer has been partially modified by quota;
- The research process has reached the point of a working review.
One simple achievement is to prioritize each type of alarm, and then select only one for each round. But the information is lost: context crowding and changing quota stress are two different issues, and models need to know both that the material may not be available and that a certain body should be carefully modified.
We therefore allow different types of reminders to coexist in the same cycle. The order is primarily used to stabilize presentation and to match capacity, and does not mean that the categories that rank ahead logically replace others.
The same type of internal need to be weighed. Assuming that a measurement passes through multiple alarm nodes at a time, the system should express the highest phase it has reached at present, rather than retransmitting each one that has been missed. The model needs to understand the current situation and does not need to receive a string of expired warnings.
The different units can't mix. The number of requests, the time of execution, the number of contextbyte and the number of changes to the text have their respective denominators and meanings and cannot be added to a vague “total remaining quota”.
Status and proposals for action, preferably dealt with separately
Not all reminders are suitable for the same type of heavy strategy.
Some information is currently available. For example, a change in the body of a paragraph quota has already been used, and the model may continue to address this element in the next few rounds. Just once, and then completely disappear, the model does not necessarily see this constraint in the follow-up.
Other messages are proposals for action. For example, the system recommends that the model review the objectives of the study. If the same recommendation has already entered the request and is repeated in another round, the value of the same recommendation may be decreasing.
We therefore separate the two:
- Provide the necessary information on an ongoing basis in follow-up requests regarding the status of the relevant quota which meets the conditions;
- Whether the proposals for action need to be resubmitted by type and service record.
This explains why the “notice to weigh” cannot be removed from the real state. The model may not need to receive "check the number of changes" per round, but there is still a need to know that there is already limited room for modification of the content.
The textual modification of quota also has a critical boundary: a body block cannot continue to be modified and does not mean that the entire study must be completed. The body, the content that can be added and the process completed are still judged by the body of publish and by the operation. Reminders can only express partial constraints and do not escalate local issues into global stoppages.
V. Candidature reminders are not equal to what the model has seen
This is the most easily overlooked step in the operational reminder.
Model requests are limited in capacity. The system may consist of several reminders, which are then loaded together with the tasks, tool results, state of necessity. If space is insufficient, some optional reminders may be discarded.
Continue with the previous teaching scene: the system generated two reminders of “resource stress” and “context approaches the threshold”, but ultimately only the former.
At this point, the reasonable record should be:
If both are marked as delivered at the time the candidate is generated, the system will later assume that the model has seen the context reminder, but the model has never received it. This error does not necessarily lead to a failure of the procedure, but rather to a quiet distortion of the alert mechanism when it comes to recovery and weight.
So we split the process:
- Generate candidates based on the original facts;
- Combining, weighting and organizing into concise tips;
- Capacity matching with the remaining context;
- A record of the facts of the reminder submitted only for the purpose of eventual actual submission;
- Repetition of subsequent rounds or resumptions by type and their original basis.
The “entry request” also indicates only that the system has submitted this hint, without indicating that the model must understand, adopt or correctly implement it. If the alarm is to be judged as having improved model behaviour, follow-up actions and results of the model also need to be observed and the effects cannot be directly rolled out from a submission record.
Similarly, in the case of uncertainty as to the outcome of the submission, the system should not be able to initiate an additional request free of charge because it did not arrive prior to the suspicion that it was intended to send a reminder. Reminds that there is no alternative route around the budget, following the original implementation and recovery mechanism.
After compression, a reminder of the final context.
context reminds me of a more detailed timing issue.
Assuming that the system finds the request too long, it is prepared to compress the old history. Compressed candidates appear to be working: previously congested materials have become shorter and the system has judged that the pressure on context has decreased.
But candidatures do not necessarily end up being used. The pre-submission inspection may have found that it saved insufficient space or that the state had changed, so the system rollback continued to use larger original content.
If the reminder is still based on the unused compressed candidate, the model may receive a reminder that does not correspond to the actual request: It sees a larger context, while the system estimates the pressure on smaller candidates.
Our treatment is to measure context on the basis of the state of necessity in the final request and to redraft the optional reminder after the compression has been adopted and rollback has been determined. In this way, the reminder is based on the material to be sent and not on a candidate who has been in transit.
The measure is the application of the actual sequenced Z113Z, which is not assumed to be the exact number of tokens returned by the model supplier. The two can be relevant but not of the same calibre; one is not made up when there is no reliable token usage.
This detail means more than “calculated better”. It asked for a more basic question to be answered: did I describe an eventual request or an intermediate solution that was later abandoned?
VII. Reminders, Reviewers and user notices are three things.
There is also the question of whether another model should be sought for review in a long mission.
Action alerts can recommend that Main look back at the research objectives and examine the evidence gaps; coordination logic can also present the Reviewer candidate based on the existing implementation facts. However, from candidate to actual dispatch, there are operational access judgements: whether automatic review is allowed, whether the budget is adequate, whether there is a review in progress, etc.
Therefore:
- Reminders are recommendations for current models;
- The Reviewer candidate indicated that certain known conditions merited consideration for review;
- Reviewer distribution is a practical implementation that requires prior access;
- User notification is a user-oriented delivery process.
These things may happen in the same study, but they cannot be replaced. The model received a “recommended review” that did not mean that another model had been called; Reviewer gave suggestions, nor did it automatically correct the answer, much less that the user had been notified.
There is also a practical benefit in separating them: a reminder that is not included in the current model request should not automatically cancel the independent Reviewer candidate; in turn, the reminder has been served and cannot be considered a licence issued by Reviewer.
VIII. What is the appropriate mechanism to address
The action reminds those tasks that are relevant to the fact that implementation is changing, and the model needs to adjust its working methods accordingly.
For example, a long-term study could alert the model to delivery when resources are gradually reduced, prompt it to use materials more selectively when context approaches capacity, and alert it to avoid unnecessary rewrite in the context of textual changes.
But there is also a cost to the mechanism: the system needs to maintain reliable factual sources, distinguish status and recommendations and maintain sufficiently accurate records when requests are formulated and restored. These may not be necessary for a simple question-and-answer session, if the task can be completed within one or two rounds.
More importantly, the reminder can only improve the way in which models receive information and cannot substitute for certainty constraints. The real budget ceiling, tool permission, text modification of access and implementation status still need to be checked by the existing mechanisms. The model, even if it ignores the reminder, should not result in additional permission.
In ETF Agent, these lines of responsibility and alarm service path have been validated; a reminder that continuous improvement of model judgement in real-life research still requires observation in conjunction with actual models.
Back to the initial fund comparison: when resources become scarce, context becomes longer, and there is less room for modification in a certain body, the system can organize these changes into a simple action thread, and put them in the requests that the model really sees next. The model then determines how to continue the study, while the system continues to manage resources, review and delivery in accordance with the original rules.
A good action cautions that models should be made more aware of the current situation; at the same time, they themselves do not act as adjudicators of the situation.
Extended reading
Run Budget and Constraint Governance Responsibilities to explain Budget and Closure; Main Z48Z compact discussion on the boundaries of summary adoption with original facts. Welcome to the ETF Engineering article collection and Star.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.