本期看点
本期优先读 HALO 和 RCA 工具设计研究。前者把多 LoRA 服务中不同的时限要求转化为可调度余量，同时减少 GPU 上基础模型与适配器串行执行的开销；后者控制模型和诊断流程，检验工具抽象层次究竟怎样改变根因定位、故障类型识别和成本。两篇都提醒我们，组件能力更强或数量更多，并不自动带来更好的端到端结果。
其余三篇围绕可靠性的不同环节展开：HarnessTester 补足模型输出相关代码的测试，StateWise 在行动前修正失效记忆，UndoBench 把正常完成任务与故障后安全恢复分开测量。它们提供的是不同层面的机制和证据，不能合成一个通用可靠性分数；阅读时值得追问，改进发生在哪个边界，又由什么观测来确认。
重点解读
01 · HALO：把宽松时限变成可调度资源
From Overloaded to Guaranteed: High-Throughput Multi-SLO Enforcement for LoRA-Assisted On-Premise LLM Deployment
Zeshen Zhang、Han Zhao、Weihao Cui、Quan Chen 等；Minyi Guo 参与 · 2026-10-04 (UTC)
同一批请求，并不需要同样快
本地服务器用一个基础模型承载多个 LoRA 服务，能共享权重，却也把不同业务挤进同一批处理队列。若所有请求每轮一起解码，宽松业务会占住紧急请求所需的槽位；批次过大又可能让严格的 token 间隔目标失守。只按到达顺序或公平性排队，不能充分利用业务之间的时限差异。
HALO 同时处理计算和调度。计算侧把 GPU 的 SM 分给基础层与 LoRA 层，让两者在 decode 阶段并行。初始化时，搜索器按批大小、适配器插入位置及硬件测量性能，再通过反馈调整分区，而不是给所有层固定一个比例。它解决的是 decode 的适配器开销，不能把这一收益直接套到已经有较高利用率的 prefill 上。
读图：下方先为基础层与 LoRA 层寻找 SM 分区；上方按请求余量选择本轮执行的请求，生成的 token 再经队列按目标节奏输出。
先算出来，不必立即发出去
调度侧把 token 生成与输出分开：低负载时提前生成的 token 留在队列中，按业务约定的时限发出，形成应付后续突发流量的缓冲。系统计算请求还能暂停多久，让余量充足的 decode 请求暂时让出槽位，优先处理接近 TTFT 或 TBT 截止时间的请求，并统一安排 prefill 与 decode。
例如，一轮计算耗时 50 ms、某请求容忍 100 ms 的 token 间隔，就有隔轮执行的空间。这是说明调度逻辑的例子，不是任意负载下的保证。HALO 还按时限折算容量占用，并使用最早截止时间优先排列等待请求，避免把“可以暂停”误当作无限扩容。相较只调整队列顺序的做法，变化发生在请求进入运行批次之后。
结果和代价要一起看
作者在 SGLang v0.5.4 上评估：Llama3-8B 使用单张 80 GB A100，Yi1.5-34B 使用四张通过 NVLink 连接的同型 GPU。医院场景采用缩放后的 AzureConv、BurstGPT 到达轨迹，并结合对应数据集的输入输出长度；这是构造的服务实验，不是医院上线统计。
该场景中，作者报告 P99 TTFT 相对 SLoRA、VTC-T、VTC-R、QoServe 分别改善 2.1×、3.1×、5.0×、3.6×。另在四类请求等概率、泊松到达的负载扫描中，满足 P99 TTFT 条件的吞吐分别提高 29.2%、29.5%、24.8%、19.5%。这些倍率和百分比来自不同实验，不能相乘成为总体加速。
值得关注的是把时间预算纳入资源分配。 输出整形会主动延后本可更早送达的 token，作者也观察到 P99 TBT 更高；其目标是按约定稳定服务，而非每个 token 都最快。收益依赖业务确有可借用余量、分区适合目标硬件，以及负载未超出容量。建议先读调度设计，再对照消融和负载扫描，判断自身服务能否接受这种时延换吞吐的取舍。
02 · RCA 工具设计：更多工具为何可能降低定位准确率
Rethinking Tool Design for Agentic RCA: A Controlled Empirical Study
Yu Luo、Rongchen Gao、Zhenhui Zhou、Changchang Liu 等；Dan Pei 参与 · 2026-10-04 (UTC)
把工具本身变成实验变量
RCA Agent 既可以自己写代码分析指标，也可以调用已经封装好的异常检测和诊断算法。前者灵活，却让模型承担数据处理和分析实现；后者降低负担，也可能提前限定证据范围。若把工具、提示和工作流一起替换，很难知道成绩究竟来自哪里。这项研究固定共同的 ReAct 式 harness、任务目标与交互约束，单独比较工具层次及其组合。
作者实现 24 个结构化工具：L1 的六个接口负责指标访问和基本汇总，L2 的十二个接口负责异常、变化点及关联分析，L3 的六个接口返回诊断候选、传播路径或证据解释。另设 L0，只提供相同数据与通用 Python 环境，由 Agent 自行实现分析。L2、L3 可直接访问底层数据，不要求 Agent 先逐层调用；组合工具意味着增加入口，不是强制流水线。
读图：上方将同一故障的指标与拓扑送入 Agent，分别评价根因实体和故障类型；下方比较工具组合、四个 Qwen 模型和三个微服务环境。
定位准、类型对、成本低，是不同目标
实验使用 RCAEval RE1 的 375 个故障案例，Online Boutique、Sock Shop、Train Ticket 各 125 个，覆盖 CPU、内存、磁盘、网络延迟和丢包五类注入故障。Qwen3.7-Plus 比较全部八种工具配置；四模型比较只覆盖共同的四种配置，不能读成完整的八乘四实验。
| Qwen3.7-Plus 配置 | 根因首位准确率 | 故障类型准确率 | 平均耗时／案例 | 平均 token／案例 |
|---|---|---|---|---|
| L0：Python 自行分析 | 85.4% | 41.4% | 88.6 秒 | 50.4K |
| L3：诊断工具 | 82.8% | 45.6% | 35.8 秒 | 22.8K |
| L1+L2+L3：全部工具 | 78.0% | 49.0% | 48.8 秒 | 95.1K |
L3 的首位定位比 L0 低 2.6 个百分点，耗时却不到一半。全部工具把类型识别提高到 49.0%，定位反而下降。轨迹分析给出一个具体解释：工具返回的首个候选常常正确，Agent 看过更多异常证据后却改选其他实体；异常最明显的位置未必是故障源。因而“工具输出正确”和“最终诊断正确”应分别观测。
工具价值取决于模型怎样使用它
这一结果也不能简化为少给工具总是更好。在 L1+L2 上增加 L3 后，另外三个模型的诊断指标改善，Qwen3-8B 却退步；它仅在 0.8% 的轨迹中调用 L3。不同微服务环境中的配置排名也会变化，说明菜单中的能力不等于实际执行的能力。
这是一项值得精读的受控实证研究。 它为工具取舍提供证据，但尚未验证真实生产事故、日志与调用链联合诊断，也只覆盖 Qwen 系列和所实现的工具。工程上的启发是分别记录定位、类型识别、工具调用与候选被推翻的过程，再选择工具组合，而不是只看总成功率。优先读配置定义和轨迹分析，能更清楚地判断瓶颈在工具、委托行为还是最终决策。
可靠性研究动态
03 · HarnessTester：让测试先满足 Agent 运行契约
Complex Agents, Shallow Tests: Demystifying and Enhancing Test Adequacy of Agent Harness in the Wild
Yifan Xiong、Jingyi Ge、Zhenpeng Chen、Yiling Lou · 2026-10-04 (UTC)
模型相关 harness 代码常依赖特定响应类型、工具对象和异步调用约定。随手造一个 mock，测试可能还没到目标分支就失败。HarnessTester 从未覆盖代码出发，在生成循环中加入运行契约提示，并按需用 AST 检索构造器、协作组件和 mock 绑定点，让输入既符合运行上下文，又覆盖不同的模型输出与状态。
读图：左侧覆盖与测试结果反馈到中间生成器，右侧提供契约指导及代码检索，帮助测试抵达目标逻辑。
作者在十个项目上评估，并报告检出 122 个真实 harness 缺陷：34 个已知、88 个此前未知；未知缺陷中 69 个获开发者确认。它把 Agent 可靠性的一部分重新落到可执行的软件测试上。覆盖增长并不等于线上故障率降低，结论也受项目和生成模型范围限制。建议读契约检索机制与真实缺陷案例；摘要和实验正文中的覆盖增益口径存在差异，不宜只摘一个百分比作总体结论。
04 · StateWise：行动之前，修复已经失效的持久记录
StateWise: Diagnosing and Repairing Persistent Operational State Before Agent Actions
Yongyuan Peng、Zhou Feng、Tongying Wu、Jiahao Chen、Yuan Su、Chunyi Zhou、Tianyu Du、Shouling Ji · 2026-10-04 (UTC)
旧记录仍被当作行动前提时，只审核当前命令可能漏掉持续性的错误。StateWise 暂时改变单条记录并重新规划，找出影响决策的前提；随后对机器事实做只读核验，对开发者意图做定向澄清，将证据绑定到相同记录与作用域，修正持久存储后再规划，并独立检查行动。
读图：左侧定位影响行动的记录，中间按证据权限核验，右侧保留修复沿革并重新规划；未解决的前提进入安全停止。
在以 GPT-5.6-sol 为主要规划器的 150 个受控案例中，125 个要求操作、25 个要求安全停止。作者报告损坏记忆条件下总体正确率从 38.7% 提高到 93.3%，未观察到不安全行动。这个分数同时计入正确停止，不能当作纯任务执行成功率。实验采用单记录缺陷和模拟开发者回答，尚不足以证明长期部署安全；适合关注其证据绑定和跨任务复用机制。
05 · UndoBench：会完成任务，不等于会安全恢复
UndoBench: Separating Task Competence from Recovery Capability in Tool-Using AI Agents
Dolly Sah、Tanmay Sah、Harshul Jain、Tanya Sah · 2026-10-04 (UTC)
远端已经提交操作、确认包却丢失时，盲目重试可能重复扣款或发消息。UndoBench 以同种子正常运行和故障运行配对，同时检查最终状态与外部效果历史；条件恢复成功率只在对应正常运行成功的试验中计算，从而避免把不会做任务与不会恢复混在一起。
读图：上方固定 Agent 接口与恢复策略，下方在外部状态变更边界注入故障，再联合检查环境状态和效果历史。
冻结的确认丢失实验含 12 个测试工作流、两种开源权重模型、两种框架、三种恢复策略及 20 个种子，共 2,880 对、5,760 次执行。作者报告正常成功率 83.54%，条件恢复成功率 46.72%；朴素重试的重复效果率为该策略全部 960 对试验的 53.33%，分母不同。价值在于把恢复单独测量；多种子不等于更多独立任务，幂等保护还依赖服务端支持，不能把结果推广为所有工具 Agent 的故障率。
实践观察：把生产交互变成诊断反馈
Marc Klingen 的原帖（页面标注 2026-10-04）讨论一次与内部 AI SRE 团队的交流：自动触发事故调查，让工程师进入工作时已有报告；再观察追问、重新生成、来源链接打开等行为，并按用户组、事故类型和被分诊团队拆分分析。
这与本期 RCA 研究形成一个有用的衔接：离线定位成绩之外，还应知道工程师怎样使用诊断结果。不过，原帖是实践建议，没有可对照的性能实验；点击和未点击也不能直接等同于满意或不满意。原帖未提供适合解释机制的原图，本节保留文字观察。