从把任务做完，到让系统自己继续：一次 Agent 自主工作能力成形的完整复盘

type

Post

status

Published

date

Mar 18, 2026

slug

agent-autonomy-mathhero-retrospective-draft-v2

summary

这是一篇脱敏后的长文复盘：从 agent 分工、skills 沉淀、验证与归档流程成形，到 MathHero 作为试炼场被一路推进，最终让系统从单次执行走向长时间自主工作。

一、最先要解决的，不是功能，而是谁应该动手

一开始最容易掉进去的坑，是把“主控”理解成“最强执行者”。表面看这很高效：所有判断集中在一个点上，信息也最完整，似乎由同一个 Agent 连续完成理解、拆解、执行、检查，会让损耗最小。

但只要任务不是一次性的小修小补，这种模式就会很快变成瓶颈。

主控一旦同时承担目标理解、优先级判断、代码实施、验证回归、文档整理这几类职责，就会出现两个后果。第一，系统节奏极度依赖单点注意力，主控忙不过来，整条线就停住。第二，角色边界开始变模糊：谁在做决定，谁在给证据，谁在验收，谁在记录，最后都混成一团。短期内看似省事，长期看几乎注定失真。

所以这轮调整最重要的一步，不是先写新功能，而是先把职责从“一个会做很多事的人”重新拆成“一个负责判断和调度的核心”加上若干条稳定运行的执行线。

主控负责三件事：定义目标、判断优先级、决定什么时候可以收口。具体执行则交给不同分线完成：有的分线负责实施，有的负责验证，有的负责资料与案例搜集，有的负责把碎片化进展整理成可阅读的文档。这样做的意义，并不只是让任务并行，更重要的是让每一类输出都拥有更清晰的输入和边界。

这是整个系统后来能够连续运转的起点。因为从这一步开始，Agent 不再是“谁有空谁去做”，而是“哪一类问题应该流到哪一条线，由谁产出什么证据”。

二、当任务变长，真正稀缺的不是能力，而是完成定义

很多协作会乱，不是因为没人能做，而是因为大家对“完成”这件事理解得不一样。

一句“这个已经好了”，在单人场景里也许勉强够用；但在多线协作里，这种说法几乎没有意义。它可能意味着代码已经改了，但还没验证；也可能意味着界面看起来对了，但状态没同步；还有一种更常见的情况，是执行者主观上觉得已经差不多，实际上却没人能追溯这次改动到底落在哪个基线之上。

所以接下来的调整，不是继续加人手，而是先把“节点完成”的判定条件硬化。

在这套实践里，一个节点如果要算真正完成，至少要同时满足三层交付：第一层是可见回执，也就是对外部看板或协作视角来说，这个节点状态必须是明确可读的；第二层是实施证据，要能指向具体改动、提交、验证日志、截图或报告；第三层是状态同步，也就是回执、证据和当前基线之间不能互相打架。

这听起来像管理动作，实际上对 Agent 系统的意义非常大。因为它把原本依赖“口头理解”的完成，变成了依赖证据链的完成。这样一来，即便任务跨越多轮、跨越多个上下文，后续接手的人也不需要重新猜：他只要沿着证据链往下看，就能知道这一步到底做到了哪里。

在这个基础上，还进一步加了几种机制：基线变更必须留痕，避免回滚或覆盖发生后无人知晓；节点如果长时间没有首个有效产物，就触发替补或重派，避免整条线因为等待一个结果而挂起；验证通过必须指向当前有效基线，而不是指向一个已经过期的状态。

这些规则表面上限制了“灵活发挥”，但恰恰因为它们存在，系统才第一次具备了在较长时间内持续运转而不散架的可能。

三、真正决定上限的，不是一次写得多快，而是经验能不能沉淀成 skill

到这一步，系统已经不再完全依赖单点注意力，但还缺一块关键能力：可复用性。

如果每一次排查、每一次修正、每一次验证，都只能靠当下那条任务线里的人临场发挥，那么系统哪怕勉强能跑，也很难越跑越稳。

因为经验并没有离开那一次具体操作，它没有被抽象出来，也就不能成为下一次行动的起点。

所以后面的一项核心工作，就是把一次性的做法改写成可复用的 skills、规则和最小化工具脚本。

这件事听上去像文档整理，实际上更像是在给 Agent 补“可迁移的肌肉记忆”。

比如，只有被写成明确的结构，才能在下一轮自动调用，而不是重新靠运气摸索：

某类问题应该先怎么查

环境能力不确定时如何优先选择更稳的命令

验证时应该先跑哪条最短路径

失败之后需要记录哪些字段

这也是为什么“学习”在这里不是附属功能，而是主流程的一部分。

一次失败如果没有进入 learnings，就很可能在几天后原样重演。

一条修复经验如果没有被写成 skill，就只会停留在那次对话里，无法成为系统的长期资产。

从这个角度看，skills 的价值不在于它们让 Agent 看起来更聪明，而在于它们把“这次做对了”转化成了“以后更容易做对”。

四、MathHero 为什么适合作为这套系统的试炼场

MathHero 这个项目之所以适合拿来验证自主工作能力，不是因为它最大，而是因为它刚好横跨了几类典型挑战：它既有前端界面统一的问题，也有交互细节和题型链路的问题；既需要连续的小步改动，也需要阶段性回归；既有可见成果，也有不少容易被忽略的隐性缺陷。

换句话说，它不是一个只靠某一类能力就能推进的项目。它天然要求协作线之间不断接力。

这轮推进里，一条很清晰的主线，是把产品从“局部页面做得还可以”推向“整条主流程在视觉和交互上更加一致”。首页展示位的轻量化调整，只是一个开端；随后 play/result 的视觉语言开始收敛到同一套设计基线，常用弹层的样式也被统一，登录页及相关交互细节跟着收口，对战流程中的几个关键页面再往同一个风格上压。到最后，连首页中的文案、头像边框、局部强调色这些细节，也被纳入统一调整里。

如果把这些动作按提交一条条列出来，它们当然可以被描述成一份工作清单；但从产品演进的角度看，它们更像是在逐步修复一种更深层的问题：让用户在不同页面之间切换时，不再像走进几套彼此无关的系统。

这类“统一感”往往不是靠某一页大改获得的，而是靠很多中小决策持续朝同一个方向收束。Agent 要想自主完成这种工作，最难的恰恰不是“知道哪里不好看”，而是能够在多轮推进中维持同一个判断标准，不被局部任务带偏。

五、系统真正成熟，不是在顺利的时候，而是在它开始能处理自己的错误时

如果说前面的工作是在搭建骨架，那么让这套系统真正变得可靠的，是它处理错误的方式。

这次实践里，最有价值的部分其实不是那些顺利完成的节点，而是几次并不体面的失误，以及它们后来如何被结构化修正。

最典型的一类，是对环境的错误假设。比如某些检索脚本默认依赖特定工具，结果换一个运行环境后直接中断。这个问题看起来很小，但它暴露的是一整类风险：执行流程默认相信环境与自己想象的一样，而不是先确认“当下能用什么”。修正的方法也很直接——先做可用性检测，不满足条件就回退到更通用的方案。真正重要的不是把某个命令改掉，而是从此以后，环境差异不再被当成偶发事故，而是被当成流程设计里必须预设的一部分。

另一类问题，出现在检索与判断逻辑里。语法层面的误用，可能让系统“以为自己找到了”，但其实覆盖并不完整。这样的错误比直接报错更危险，因为它制造了一种虚假的确定感。后来的修正重点，也不只是替换一条命令，而是明确：凡是可能影响判断范围的检索动作，都要采用更可验证的写法，必要时分步执行，减少假阳性。

还有一类错误，恰好说明了“功能存在”和“流程可用”之间的差距。界面里出现了某个入口、某个标签、某个按钮，看上去好像功能已经具备，但如果它没有和后续链路真正接起来，那就只是一个静态符号。比如某些训练入口在视觉上已经出现，实际上却缺乏事件绑定，用户点击后并没有形成完整回流。补齐这类问题，往往不是加大功能量，而是把断开的地方接通，让“看起来有”变成“真的能走通”。

再往下，还有更细的一层：即便主流程能跑，判题或交互逻辑里仍可能埋着精度与容错上的隐患。它们不会在第一时间炸掉页面，却会悄悄侵蚀质量标准。这类问题的价值，不在于立即宣告“完全解决”，而在于系统已经学会把它们作为显式风险记下来，等待后续按规则收紧，而不是任由它们在“能用就行”的借口里长期潜伏。

这些修正共同说明了一件事：自主能力不等于不犯错，而是犯错之后，系统不会失忆，也不会假装没看见。它会把错误转译成下一轮更稳的动作约束。

六、从项目推进的角度看，MathHero 最重要的成果不是页面，而是节奏

把这次过程拉长来看，MathHero 的落地并不是靠一次“大版本冲刺”完成的，而是靠连续的小步推进与回归验证。

UI 线先做主流程页面的统一，再处理弹层和零碎细节；实施线在发现题型切换、输入模式刷新、链路闭环等问题后，优先补足那些会直接影响使用路径的点；验证线不是等所有内容堆完再一次性总测，而是在每一轮之后给出最小回归结论；资料与文档线则不断把这些零散变化从“执行记录”整理成“可以阅读、可以传递、可以审阅”的阶段性成果。

这里最关键的，不是并行本身，而是各线都在同一个节奏里工作：每推进一步，都尽量留下下一条线可以接的东西。代码线留下可验证的改动，验证线留下通过或失败的边界，文档线留下结构化叙述，主控据此决定是继续推进、局部返工，还是阶段收口。

于是整个项目逐渐呈现出一种不同于普通“任务堆叠”的状态：它不是靠一个人记住全部细节来维持连贯，而是靠任务之间的证据与接口来维持连贯。也正因为这样，系统第一次具备了“长时间自主工作”的现实含义——不是无人值守地乱跑，而是在持续有人监管目标边界的前提下，能靠内部结构把工作往前推。

从结果上看，MathHero 获得的是页面一致性、交互稳定性和链路闭环的提升；但从系统能力上看，更值得记录的是另外三件事：它从“单页改善”走向了“全流程收束”，从“看起来有功能”走向了“可被验证的功能”，也从“靠人一直盯着推进”走向了“任务线可以在规则内持续续跑”。

七、最后沉淀下来的，其实是一套很朴素的方法论

回头看这次实践，真正能被复用的经验并不神秘，反而很朴素。

第一，先搭治理壳，再冲功能。没有清晰的角色分工和完成定义，功能做得越快，后期返工越多。

第二，把“完成”从主观口头改成客观证据。任何节点都应该能回答三个问题：改了什么，怎么验证的，现在落在哪个基线上。

第三，小步快跑，但每一步都要可回归。不是每次都做很多，而是每次都让下一步更容易判断。

第四，把失败结构化记录。错误本身不可怕，可怕的是错误只存在于记忆里，不存在于系统里。

第五，让系统具备替补和续派能力。真正的自主，不是永远不出错，而是某个点卡住之后，整条线也不会跟着一起停摆。

如果把这些原则放在一起看，它们其实都指向同一个目标：让 Agent 系统从“依赖一次次聪明发挥”转向“依赖可以积累的秩序”。

结语：MathHero 只是样本，真正完成的是一种工作能力

这次最值得写下来的，不是某一次页面改版有多成功，也不是某个提交多关键，而是一个更底层的变化终于发生了。

主控不再等于亲自下场执行；执行线不再只是临时补位的帮手，而开始成为稳定生产节点；验证与归档不再是在项目快结束时才补上的附件，而是从一开始就嵌进主流程里的必要环节。经验也不再只留在对话或记忆中，而被持续写进 skills、规则和 learnings，成为下一轮工作的起点。

当一个系统能够持续完成“拆解—执行—验证—归档—再推进”的循环，它才真正开始拥有长期自主工作的能力。MathHero 只是这套能力第一次比较完整的落地样本。它的重要性，不在于证明 Agent 可以做一个项目，而在于证明 Agent 可以在一个项目里，学会如何继续工作。

这两件事看起来只差一点，实际上差了整整一个系统。