背景
这个模块原本想解决什么？用户为什么会撞到问题？
Open source · evidence first
不只交一个 patch，
也把为什么讲明白。
这是我参与开源项目时留下的工程笔记。每个案例都从小白能理解的背景开始，一路走到真实代码、根因、修复方案和验证证据。
02完整工程案例
02公开 Fork 分支
2×T4真实 GPU 复现环境
0没有把猜测写成结论
01 / How I work
我用同一条证据链处理每个问题。
不是看到报错就改一行，也不是测试通过就宣布成功。真正完整的修复，要能回答下面五个问题。
链路
请求从入口到失败点，经过了哪些层，每层负责什么？
根因
哪一个条件真正导致失败？哪些看似合理的解释被排除？
修复
改动放在哪一层最合适？怎样限制影响范围并保留兼容性？
验证
单测、回归、真实环境分别证明什么？还有哪些未知风险？
02 / Case files
两次修复，两种完全不同的问题。
一个是 Agent Runtime 的数据链路设计，一个是 GPU Kernel 的硬件资源约束。共同点是：都先还原事实，再动代码。
CASE 001 · FEATURE● Fork 已实现
让同一个 Agent Team 的队友使用不同模型
拆开“怎么启动子会话”和“由哪个模型执行”两种选择，让 Lead Agent 能安全地给不同队友分配不同模型，并在重启后保持原来的路由。
从原链路开始读→
CASE 002 · BUGFIX● 上游讨论中
修复 Tesla T4 上 Triton Attention 的 80 KiB 溢出
把一条“首请求就崩”的 GPU 报错拆成可计算的共享内存账单，再用真实 2×T4 完整模型复现，验证精确受限的 tile 策略。
查看 80 KiB 是怎么来的→
没有匹配的案例。试试 “T4”、“Agent” 或 “模型路由”。
03 / Engineering discipline
修复过程不仅可复现，也应该经得起审查。
对开源协作来说，真正重要的是清楚说明事实如何被确认、风险如何被限制，以及哪些部分仍然没有得到证明。
先建立证据，再给出判断
检索调用链、对齐数据结构、运行对照实验并保留失败路径，让每个结论都能回到代码、日志或真实环境。
明确完成了什么，也明确还差什么
确认问题真的复现、根因可以解释报错、改动没有越界，并且不把“Fork 中验证通过”包装成“上游已经接受”。