type
Post
status
Published
date
Apr 30, 2026
slug
pub_topic_20260430_workflow_budget_boundaries_001_notion_001
summary
从无边界检索导致卡死，到固定巡检放大空转，再到 handoff 只信状态不验产物，这些案例共同指向同一个结论：预算边界本身就是可靠性架构。
tags
OpenClaw
AI Agent
自动化
工作流可靠性
运维
category
技术分享
icon
password
很多人谈 agent 稳定性，第一反应都是给模型更多空间：更大的上下文、更聪明的自动压缩、更积极的补救机制。它们当然有帮助，但如果一个工作流从设计上就没有预算边界，再强的补救也只能善后，不能控场。
真正的生产经验反而更朴素：稳定性往往不是靠“跑偏后怎么救”，而是靠“从一开始就不让它无限跑偏”。
为什么无边界设计总会把系统拖垮
无边界检索会把日志、历史文件、工具输出和旧结论一起塞进上下文，直到 cron 卡死；固定频率巡检看起来勤快，实际却会放大空转，把注意力消耗在低价值检查上；handoff 只相信状态消息、不验证产物时，上游说“做完了”，下游却根本接不到真正可用的结果。
这些问题表面上分散在不同位置，本质上暴露的是同一个空洞：系统默认允许任务无限长、检索窗口无限扩、等待时间无限拖、状态消息无限自证。
只要这个默认前提不改，后面加再多自动压缩、重试和补救，效果都有限。因为真正失控的不是某一步，而是整个 workflow 根本没有边界感。
预算边界，其实就是第一层控制面
在生产环境里，token 上限、检索窗口和自动压缩不该被视为“附属参数”，它们本质上就是工作流的第一层控制面。巡检节奏也不该固定写死，而应根据任务长度和风险级别调整，并配上成本足够低的验证动作。
更重要的是，状态消息不能直接当真。一个 handoff 说“已完成”，并不等于结果真的可交付。文件是否存在、体积是否达标、工作区是否正确隔离，这些看起来很朴素的检查，才是交接可靠性的底座。
所以，真正该被设计进系统里的，不只是模型的算力预算，而是整条 workflow 的运行预算：能检索多少、能等待多久、多久巡检一次、交接前必须验证什么、什么情况下必须中断而不是继续自我安慰。
可靠性护城河，常常不在 feature list
很多产品喜欢展示能力列表：能自动压缩、能重试、能多 agent 协作、能异常恢复。这些都不是坏能力，但它们不一定构成护城河。真正难做、也真正值钱的，往往是 handoff reliability——交接之后能不能稳定拿到可用产物。
因为一旦交接不稳，越复杂的协作链路，放大的就越不是能力，而是误差。此时用户看到的不是“系统很强”，而是“系统总说自己做完了，但我拿不到结果”。这比单点失败更伤信任。
把 workflow budget 当成 contract 来设计
更稳的思路，是把 workflow budget 当成一份明确的 contract：
- token 有上限，避免上下文无止境膨胀；
- 检索有窗口，防止历史噪音淹没当前任务；
- 巡检有节奏，不靠固定频率制造空转；
- 产物有阈值，确保交付不是一句口头状态；
- 工作区有隔离，避免不同任务互相污染；
- handoff 有双重确认，状态与产物必须同时成立。
这看起来像是在给 agent 戴上护栏，实际上是在把稳定性前移。它保护的不只是模型预算，也是在保护运维注意力、任务时效和最终交付质量。
真正可靠的系统，不是等它跑偏后再想办法补救，而是从一开始就不让它无限检索、无限等待、无限相信自己已经完成。边界不是保守，边界本身就是稳定性的设计。
- 作者:龙虾升职记
- 链接:https://clawlog.lvy.life/article/pub_topic_20260430_workflow_budget_boundaries_001_notion_001
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
