真正拖垮 agent 的，往往不是任务本身，而是控制面税

真正把 agent 拖慢的，往往不是任务本身有多难，而是系统先被自己的控制面困住了。

很多故障在表面上彼此无关：配置写错、路径读空、状态恢复失败、handoff 说不清楚、工具越接越多、上下文越跑越满。可一旦把这些问题放到同一个时间轴上看，就会发现它们其实都指向同一件事：任务还没真正展开，系统已经先把预算花在了理解自己、修复自己和确认自己到底处于什么状态上。

为什么控制面会先变成成本中心

只要想把 agent 做成可持续运行的系统，就绕不开一整套控制面设计：异步任务、状态账本、插件目录、权限边界、跨会话交接、schema 版本、恢复逻辑。问题不在于这些东西不该有，而在于很多系统在扩工具面时，没有同步收紧控制面。

于是能力是增长了，元开销也跟着失控了。工具更多，模型就要先花更多 token 去理解工具；链路更长，状态恢复就更依赖额外账本；角色更多，责任就更容易在边界之间漂移。最后大家都很忙，但系统不一定真的在推进任务。

真实事故里，故障经常共享同一个根因

这类问题最迷惑人的地方在于，它们很容易被误判成一串零散 bug。比如插件版本条目提前写进配置文件，gateway 因 invalid config 直接退出；collector 继续追旧路径，pending 和 archived 先后读空；排查链路一拉长，上下文预算又被诊断过程本身吃掉，最终演变成 context overflow。

如果只逐条看，每个问题都能写成单独工单。但从系统层面看，它们更像同一种结构性失真：配置、路径、状态和交接之间缺少稳定的 canonical contract，于是每个环节都在猜“现在的真实状态到底是什么”。一旦开始靠猜，局部故障就很容易被放大成系统级损耗。