01
为什么关注运行时
智能体在单轮中给出好答案，并不意味着它能稳定处理长任务。恢复会话时可能带回旧状态，大型工具输出可能挤占上下文，中间消息也可能影响最终结果的传递。
我关注这些边界，因为它们会影响整个系统的可用性，也可以转化成明确的工程问题：哪些状态属于当前会话，什么信息必须保留，哪条消息应该交给用户？
02
会话隔离与消息传递
我提交过一项关于清理恢复会话历史、避免上下文泄漏的修复；另一项提案处理网关中间回复可能阻止最终工具结果交付的问题。
这类工作需要沿运行路径追踪故障，找到被跨越的状态边界，再提出适合现有项目结构、可供审阅的修改。
03
大型输出与上下文连续性
我还提交过可选的大型工具结果压缩方案，以及在跨界面重建会话连续性时纳入压缩历史关系的提案。
这些工作都围绕同一个问题：长会话被缩短或恢复之后，哪些信息仍然可用。具体实现和评审状态可以直接在公开 PR 中查看。
- 01工具输出与消息
- 02会话状态与压缩
- 03恢复后的上下文
04
在公开协作中做工程
开源工作让推理过程也接受检查。一项贡献需要讲清问题，给出符合周边代码的实现，并提供足够的信息让其他开发者审阅。
这些工作在这里被称为提交的修复与提案。提交、评审和上游采纳是不同阶段，下面的链接保留了这个过程。