Ruiteng Huang · loopx 作者 · 阅读原文
发现渠道：X For You公开快照
Ruiteng Huang 在阅读 dsh-superagent 架构后，把它与自己开发的 loopx 作了比较。他认同“多做有用的事、少占用人的注意力”这个目标，也认为任务状态应当独立于会话存在。但他指出，loopx 还维护目标和 Agent 的长期状态，控制工作本身会越来越复杂：该做哪件事、哪些证据已接受、哪些约束仍有效，都需要处理。
他的设计主张是把这类控制工作放在单独的控制会话里，再用任务语言给执行者交代工作，让执行者专注于实际问题。原帖链接的 RFC 给出一个例子：修复已经产出有效文件，但打包检查失败时，控制者应保留有用修复，交接具体打包问题，不能把所有结果压成“完成”，也不能丢掉失败检查。
这份 RFC 虽已接受设计方向，成熟度仍标为提案，不表示双会话运行时已经交付。文档也承认，额外控制会话可能增加成本、遗漏约束或过度指挥。Huang 后续说相关基准仍在跑，只有不确定的积极信号。这仍是开发者的架构判断，性能收益尚待验证。
可信度 65 · 重要性 70 · 新颖度 65
技术与主题
Agent 系统 · AI 编程 · 基础模型 · 控制与执行分离 · 会话恢复 · 反馈采纳
飞身踢
回应原帖：Ruiteng Huang
在 Huang 原帖下回复自己的长任务经历；来源为固定程序取得的 For You 公开评论快照。
忠实转述（非原句）：他跑长任务时总要盯着，担心中途跑偏或卡住，最后救火花掉了省下来的时间。因此他认可状态与会话分离的方向，却更想知道子任务失败后怎样回滚。
编辑评读
“控制与执行分开”有用的前提，是执行者仍能拿到完整的必要条件。控制者若只传精炼结论，可能恰好删掉了反例、原始要求或未完成检查；模型读到的文字更少了，做错事的概率却可能更高。RFC 区分“收到反馈”和“后续行动实际采用反馈”，把这个风险落到了可追踪的结果上。
所以比较双会话与单会话时，不能只数执行者的输入 token。控制会话调用、恢复、补读、往返延迟都应计入，还要看约束是否保留。更直接的检查是：人在执行途中改了一项要求，最终产物有没有按新要求改变，旧的承诺是否仍被履行。这个问题连接了架构与真实体验，也解释了为什么评论区首先追问失败回滚，而不是上下文节省百分比。