AI Daily Study#

26.07.27#

Self-Harness#

S：LLM Agent 的表现不只由底层模型决定，也被系统提示词、工具使用规则、验证方式、失败恢复策略和执行流程影响。过去这些 harness 多由人类专家手动设计，但不同模型行为差异大，模型迭代又快，人工调参很难长期扩展。
T：论文提出的 Self-Harness 让目标模型基于自己的失败记录改进运行框架。
A：流程分为 Weakness Mining、Harness Proposal 和 Proposal Validation 三步：先收集执行轨迹和验证结果，挖掘反复失败模式；再让同一个模型提出小范围 harness 修改；最后重新跑任务验证，只有提升一个任务集合且不让另一个集合退步的修改才会被合并。
R：在 Terminal-Bench-2.0 上，MiniMax M2.5、Qwen3.5-35B-A3B 和 GLM-5 的 held-out 通过率均有提升，例如 MiniMax M2.5 从 40.5% 提升到 61.9%。

perspective：

核心思路是将agent的失败变成资产。一次 Agent 失败不只是任务没完成，还包含轨迹、工具选择、错误恢复、验证信号和最终失败原因。如果平台能持续沉淀这些失败记录，就可以形成一个新的库，进而指导 Agent 工作流优化。类似于仿生观念里的“失败是成功之母”）

在产品设计上可以将这种思路迁移为平台能力，原先Agent的高频失败类型可能只作为在后台展示的黑盒，但平台展示者可以提供候选策略变更+小幅度灰度测试的思路。比如task a在某个节点上出现报错故障，比起平常的断点续跑，也就是倒退回这个节点的开头开始重跑，可以选择原地暂停，提供策略变更选项+此节点小幅度微调，也许效率会更高。（但适合优先放在低风险、可自动验证的场景，如代码修复、命令行任务、数据处理脚本，更复杂的任务不太适合这种方案，还是以回滚为先）

首先技术方面需要将完整的轨迹记录下来？最好规范化采集轨迹+打上失败标签，方便进行一个失败原因的聚类，先缩小一步范围，之后微调步骤再缩小一步范围，规定一个变更范围，生成候选的策略。另外对版本管理的要求也会提高，必须要支持回滚，否则会更乱套

SkillWeaver#

原文链接：https://arxiv.org/html/2606.18051?_immersive_translate_auto_translate=1， ↗ 太难他妈看了。。

What：Compositional Skill Routing(大型技能库下的组合式技能路由)：给定复杂用户请求和大型技能库，系统要输出任务拆解、子任务到技能的映射，以及步骤之间依赖关系构成的执行 DAG。比传统“一个 query 匹配一个工具”的路由更接近真实 Agent 任务，因为真实请求常常包含多个步骤。（也就是针对复杂query进行多skill调用（和agent的区别也许是它是自组织的？）
How：SkillWeaver 的方法是 Decompose → Retrieve → Compose。先用 LLM 将复杂请求拆成原子子任务，每个子任务分配一个技能；再用 bi-encoder （计算相似度， RAG 等系统的粗召回阶段）和 FAISS （对大规模数值向量数据，如图片、文字等，进行快速最近邻检索）从技能库中检索候选技能；最后结合相关性、I/O 类型、类别重合和关键词共现，组织成技能序列与依赖图。论文还提出 SAD，即 Skill-Aware Decomposition：先粗拆并检索候选技能，再把候选技能名称和描述反馈给拆解器做第二轮拆解。
Result：技能路由的第一瓶颈不是检索器完全失效，而是第一步任务拆解粒度不准。

perspective：

核心点在于任务与skill的命中度。召回skills时可能会出现命名不稳定、能力边界重叠、描述粒度不一和路由误判。

产品上可以引入两类能力。第一类是运行时规划能力：对复杂请求先做粗拆，再根据候选技能做二次拆解，让计划更贴近实际技能库。第二类是技能治理能力：根据路由日志发现哪些技能经常被误召回、哪些请求被过度拆解、哪些技能描述导致词汇不匹配，从而将技能进一步规范化

这篇论文也能指导复杂任务的体验设计。在复杂度较高或涉及多技能时可触发 SAD，可以接受两轮拆解和重排带来的额外成本，以换取更高的计划质量。

主要是技术方面需要定义原子任务的粒度与复杂任务的范围，产品方面可能是拓展了对复杂任务的处理能力，相比于为它编排一个成熟的模板，这种拆解后自组织skill也许可以类比于自由度更高的agent？感觉agent的子任务也可以子agent，子子孙孙无穷尽也呀。