当 Agent 开始
改写自己

过去一年，我们一直在沿着同一条线索往前推：先是把单个 Agent 当工具， 然后是 lark-cli 那样的「协作侧动作执行器」——让 Agent 在飞书上规范地留痕； 再到 Symphony 那种「把 issue tracker 当控制平面、人退到 PR review 末端」的团队级编排。 这些都在回答同一个问题：多个 Agent 如何分工、如何被调度、如何把工作而不是会话管起来。

但它们都默认了一个前提——Agent 本身是给定的。你写好 prompt、配好工具、定义好 SOP， Agent 就在这个能力边界内干活。它今天和三个月后是一样的，除非你亲自回去改它。

SIA（Self-Improving AI）戳的正是这个前提。它问的不是「怎么调度 Agent」， 而是「能不能让 Agent 自己变好」——而且是在一个明确的基准任务上、可度量地变好。

三个 Agent，一个进化循环

SIA 是 hexolabs 开源的自改进 AI 框架，对应论文 "SIA: Self Improving AI with Harness & Weight Updates"。 它的目标用一句话说：让任意一个 AI 系统（模型或 Agent）在某个基准任务上，自动地、一代比一代地变好。

实现方式不靠玄学，而是让三种角色的 Agent 组成一个闭环：

这三者跑完一轮叫一个「代次」（generation）。Feedback 改完，新的 Target 再上场、再被记录、再被复盘…… 一代一代滚下去。每一代的产物都被落盘保留：

# runs/run_1/gen_3/
target_agent.py        # 这一代的 Agent 代码
agent_execution.json   # 执行日志（Feedback 的输入）
improvement.md         # 这一代相对上一代改了什么、为什么（gen 2+）

注意标题里那个关键词：Harness & Weight Updates。SIA 改的不只是 prompt 或脚手架代码（harness）， 论文宣称它也能更新模型权重（weights）。换句话说，它把「调 Agent」这件事的两个层面—— 外层的框架和内层的能力——都纳入了同一个自动循环。

瓶颈又往上挪了一层

还记得 Symphony 的那个洞察吗——当 Codex 足够强，工程师的瓶颈就从「写代码」变成了「监工 Agent」， 所以 Symphony 把会话管理这层抽掉。SIA 是同一个故事的下一章： 当你有了一堆 Agent 在干活，新的瓶颈变成了「谁来持续优化这些 Agent」。

在 SIA 之前，这个答案是「你，手动地」。你看日志、改 prompt、调工具、再测一遍—— 这是一种永远做不完、又很难规模化的工作。SIA 把它形式化成一个循环，于是有了三个真正重要的转变：

① 优化从「人工劳动」变成「可挂后台的进程」

这是最直接的价值。你不再需要盯着每一代的表现手动迭代——把任务和基准定义清楚， 循环自己往前滚。人的角色从「优化者」退到「优化过程的设计者和验收者」， 和 Symphony 把人从 prompter 推到 reviewer 是完全同构的方向。

② 它把「改进」变成了可审计的资产

每一代的 improvement.md 都是一份白纸黑字的「这次为什么这么改」。 这件事被严重低估了——它意味着 Agent 的进化路径不是黑箱，而是一条可以回溯、 可以评审、可以被团队复用的决策链。这跟 Symphony 的 SPEC.md、 跟你 lark-cli 文档里强调的「结构化输出 + 可观测性」是一脉相承的设计品味： 把隐性的判断显性化成可传承的 artifact。

③ 它逼你先把「好」定义清楚

自改进循环要成立，前提是有一个可度量的基准任务——否则「改进」无从谈起。 这个约束看似是负担，实则是礼物：它强迫团队在放 Agent 上场之前，先回答 「这个任务到底怎么算做好了」。很多团队的真正问题不是 Agent 不够强，而是从没把成功标准写下来过。

不抢戏，补在最上面那一格

你已经有了一套相对完整的多 Agent 拼图。SIA 的好处是它不和其中任何一块抢位置—— 它补的是过去一直空着的那一格：「谁来让这些 Agent 持续变好」。

最值得玩味的一点：SIA 产出的「更好的 Target Agent」，恰恰可以成为上面三层的输入。 一个被 SIA 在「生成会议纪要」任务上磨过 5 代的 Agent，可以直接被包装成 Symphony 调度的一个 worker， 或者你 Claude Code Subagent 体系里的一个 report-bot——它通过 lark-cli 把结果写回飞书。 SIA 是这条流水线的「上游铸造车间」，不是替代品。

从内置任务开始，别上来就接生产

SIA 自带四个任务（gpqa / lawbench / longcot-chess / spaceship-titanic）， 装好就能跑——先用它们建立对「一代一代变好」的直觉，再谈接自己的任务。

安装（Claude 后端为例）

python3 -m venv .venv && source .venv/bin/activate
pip install 'sia-agent[claude]'
export ANTHROPIC_API_KEY="..."

# 想跑多供应商（Gemini / OpenAI / Anthropic）则用 openhands 后端：
# pip install 'sia-agent[openhands]'

跑第一个循环

sia --task gpqa --max_gen 5 --run_id 1
# 跑 5 代自改进，产物落在 runs/run_1/gen_{n}/

跑完之后，第一件该做的事不是看分数，是把每一代的 improvement.md 串起来读一遍。 这条「Feedback Agent 的决策链」比最终那个数字有价值得多——它告诉你这套循环是真在做有意义的归因， 还是在瞎调。这一步的判断，决定了你值不值得往下接自己的任务。

「自带任务」才是真正的入口

内置任务是 demo，真正的价值在于把它指向你团队真实的、重复发生的、且能判定好坏的任务。 SIA 要求一个固定的目录结构：

my-task/
├── data/
│   ├── public/
│   │   ├── task.md      # 任务描述——SIA 读这个
│   │   └── ...          # Agent 被允许看到的输入
│   └── private/         # 留出的评测数据，永不暴露给 Agent
└── reference/
    └── reference_target_agent.py   # Agent 模板

sia --task_dir ./my-task --max_gen 5 --run_id 1

这里藏着整个框架最重要的工程纪律，和我们之前聊 Symphony 时说的「harness engineering」是同一件事：

• public / private 的隔离就是你的「验收门」。private 数据永不给 Agent 看到—— 这是防止自改进循环「对着考题作弊」的唯一保障。如果这个隔离形同虚设，整套循环会愉快地优化出一个只会过拟合的废物。
• task.md 的质量 = 循环的上限。任务描述写得含糊，Meta-Agent 造出的初版就跑偏， 后面再改也是在错误的方向上精进。这跟 Symphony 要求「issue 干净到 Agent 能直接执行」是完全一样的前提。
• 「好」必须能被自动判定。如果评分还要人来打，自改进循环就退化成了人工迭代—— SIA 的全部价值就泄掉了。

另外，如果你的任务本质是个 ML 竞赛，SIA 能直接从任何 MLE-Bench 竞赛 bootstrap 出任务目录（自动拉数据、切 public/private、放模板），这是上手自定义任务最快的捷径。

把 SIA 嫁接到现有工作流的四步

延续你之前那几份 Playbook 的风格，给一条克制的、不推倒重来的铺设路径。 核心原则：SIA 是离线的「铸造车间」，不要让它直接碰生产流量—— 它产出 Agent，由你现有的编排层（Symphony / Subagent）去部署。

1. 第 1 周 · 选一个「窄而重复」的任务，建好评测集 别贪大。挑一个团队每天都在做、且明确能判对错的小任务（比如「把某类工单分类」「从纪要里抽行动项」）。 把它整理成 SIA 的目录结构，把私有评测集这件事做扎实——这一步花的时间，决定后面一切是否成立。
2. 第 2 周 · 离线跑循环，读 improvement.md 而不是只看分数 用 --max_gen 5 跑起来，重点审查 Feedback Agent 的归因链是否合理。 这一周的产出不是「一个更好的 Agent」，而是一个判断：这套循环对你这个任务到底有没有用。 没用就止损，这是最便宜的失败。
3. 第 3 周 · 把最佳代次的 Agent「出厂」，包进现有编排 把跑出来的 target_agent.py 当成一个产出物，包装成你体系里的一个 Subagent， 或一个 Symphony 调度的 worker，让它通过 lark-cli 把结果写回飞书留痕。 SIA 到此退场，回到离线。线上跑的是它的产物，不是它本身。
4. 第 4 周 · 把这条「铸造 → 部署」链路写成团队 SOP 固化下来：什么样的任务值得上 SIA、评测集怎么建、improvement.md 怎么评审、 出厂的 Agent 怎么纳管和回滚。这一步让 SIA 从「某个人跑通的实验」变成组织级的、可复用的能力—— 和你给 lark-cli 写的那套自定义 Skill、给 Symphony 想的「参考架构小节」是同一种沉淀。

这条线索的下一个坐标

如果说 lark-cli 回答了「Agent 怎么干活」、Symphony 回答了「Agent 怎么被调度」、 A2A 回答了「Agent 怎么互相找到」，那么 SIA 补上的是最后一个、也是最反直觉的问题： 「Agent 怎么自己变好」。

它未必成熟——仓库还很新，数字还需自证。但它代表的方向是确定的： 当 Agent 的调度和协作都逐渐标准化之后，团队的下一个竞争壁垒， 会落在「谁能更快、更可审计地让自己的 Agent 持续进化」上。 SIA 给了这件事一个可以动手的形状。先用内置任务跑一轮，读读那几份 improvement.md—— 你会很快知道，这个形状适不适合你手上的活。