EvoSOP — Iterative Tool Optimization for Self-Evolving LLM Agents
EvoSOP — Iterative Tool Optimization for Self-Evolving LLM Agents
一句话结论
EvoSOP 把 agent 自我改进定义为“从原子动作到可调用 SOP 的工具集优化”：从历史轨迹中构造多步例程，合并冗余，评估效果，剪枝低效或错误 SOP，让 agent 不必每次从零推理同一类 workflow。
为什么对用户重要
用户的 Hermes / llm-wiki 工作流已经出现很多重复模式：orient → search → read → raw archive → source/concept update → index/log → reindex → report。今天之前这些流程主要写在 skill prompt 里；EvoSOP 提醒我们，真正可扩展的 agentic workflow 应该把反复成功的多步动作晋升为可调用、可评估、可剪枝的 SOP，而不是靠每天重新推理。
机制 / 一阶原理
EvoSOP 的基本类比是：不更新模型权重，而在 symbolic tool layer 做“反向传播”。历史轨迹是训练数据；失败、重复和低效步骤是误差信号；CONSTRUCTOR 从轨迹中抽取功能抽象；MERGER 合并重叠 SOP；REVIEWER 根据执行反馈评估；PRUNER 删除低效或高错 SOP。这样做既压缩 reasoning rounds，也防止工具集膨胀。
与既有 wiki 的关系
- 对 External-Agent-Skills-Design-Patterns：补充 skill 生命周期的“合并/剪枝/版本评估”，不是只创建新 skill。
- 对 Harness-Engineering：SOP 是 harness 中的高阶工具，但必须受 gate、eval 和 rollback 约束。
- 对 AI-Self-Improvement-Lab：提供了一个不改模型权重的 self-improvement 路径：优化 workflow/tool layer。
- 对 Loop-Engineering：Loop 的稳定性取决于是否能把重复闭环抽象成 SOP，并持续去除噪音例程。
可执行启发
- llm-wiki radar 可沉淀一个
daily-ai-radar-sop：明确候选打分、深度入库、raw/frontmatter、写入记录、index/log、reindex、优化文章的固定顺序。 - 但 SOP 晋升必须有证据门槛：至少多次真实通过、明确失败模式、记录不适用边界。
- 对现有 Hermes skills，应定期做“merge/prune”：合并重复 reference，删除只会增加 token 的浅建议，保留可验证 workflow。
失败模式 / 边界
EvoSOP 最大风险是 toolset bloating 和 overfitting：从少数轨迹抽出的 SOP 可能只适配窄场景，反而误导 agent。对用户环境而言，任何 SOP 都应有触发边界、禁用条件、验证命令和回滚策略；否则“自我改进”会变成长期上下文污染。
写入记录
- 2026-07-09 09:00 CST：新增论文来源页，提炼 SOP 生命周期对 Hermes skill / llm-wiki radar 自动化的启发。