Spur：安全领域的原子求解状态机

这一年，模型能力的进步让越来越多安全任务可以交给 Agent 执行。腾讯云第一届智能渗透挑战赛主要采用 XBOW 的 Web 靶场，第二届已经扩展到多层网络、内网横向和域渗透。Agent 需要持续分析新发现，维护已经取得的访问能力，并把前面的成果用于后续任务。这类工作对系统提出的要求，已经超出了单次工具调用或一段漏洞分析。Harness 怎样组织这些工作，会直接影响模型能力的发挥。

我分析过各队的方案和一些运行记录，最感兴趣的是大家怎样组织模型工作。有的维护共享笔记，有的加入旁路观察者，有的完善工具和执行环境，也有的尽量减少预设流程，让模型根据当前信息决定下一步。模型能力提高以后，原来必须由工程补足的部分可能不再必要，新的任务又会带来不同的问题。

安全 harness 应该提供哪些支持，才能让模型在长程任务中充分发挥已有能力？

我开发 Spur，主要是在尝试回答这个问题。它面向需要反复探索和验证的安全任务，借鉴 Cairn 的黑板架构，通过事实图保存进展，再用独立的执行、审查和核验过程组织后续工作。

具体实现中，我一直关注上下文怎样组织：哪些信息应该长期保留，哪些只对当前探索有用，什么时候需要重新检查已有判断，以及一次执行的结果怎样影响下一次决策。Spur 的状态机、报告、reviewer 和 verifier，都是围绕这些问题设计的。

一、从 Cairn 得到的启发

分析第二届挑战赛的方案时，Cairn 的设计深深吸引了我。它并非总排名第一，却是唯一完成全部赛题的系统。比成绩更让我认同的，是它对渗透过程的组织方式。我当时就很看好这条路线，后来也专门写过一篇源码分析。

1.1 在黑板上连接不同发现

在渗透任务中，后续行动经常取决于刚刚取得的信息。发现一个服务以后，需要进一步检查它的功能；获得账号信息以后，可能重新考虑之前无法访问的入口；一次测试失败，也可能说明某个前提需要修正。预先列好的流程可以覆盖常见步骤，却很难替模型决定这些新发现该怎样使用。

Cairn 将已确认的发现记为 Fact，将待探索的方向记为 Intent。模型根据已有 Fact 提出新的 Intent，执行后再把结果写入黑板。多个发现可以共同支持一次探索，操作者也能通过 Hint 提供线索。

例如，一轮探索确认内部服务可以访问，另一轮取得一份可能相关的账号信息。接下来可以验证账号是否适用于这个服务。这个关联只是待验证的假设，不能因为两条信息同时出现，就直接认定已经取得访问权限。

我看重的是，不同探索的成果可以组合，下一步任务由当前发现决定。 有些线索取得时暂时用不上，后面出现新的条件，才有继续验证的价值。模型可以据此调整行动，不必始终沿用最初的计划。

Worker 不固定对应某种安全专业。它执行 reason 时分析已有发现、提出方向，执行 explore 时沿指定 Intent 取得证据。至于读代码、分析服务还是调试程序，由当前任务决定。我没有必要先替一个具备多方面能力的模型划定固定岗位。

1.2 借助工具与社区的积累

Cairn 对成熟工具的复用同样影响了我的选择。执行层使用 Claude Code 等现成 Agent，安全工具来自 Kali 和其他开源项目，环境中也提供 PayloadsAllTheThings、HackTricks 等资料供模型查阅。

工具调用、上下文管理、异常恢复和模型接口适配，都需要长期维护；已有安全工具也积累了大量功能和使用经验。

Cairn的这种方式实则是“蒸馏”了全世界的技术红利。

Spur 同样复用了这些成果，把开发重点放在长程求解的组织上。模型、执行工具或社区项目继续改进时，Spur 也有机会直接受益。

二、长程任务中的上下文问题

Claude Code 已经能完成复杂的代码阅读、命令执行和调试。但在长程任务中，我仍然反复遇到几类问题。

2.1 三种反复出现的问题

偷懒：目标尚未完成，就提前结束。 任务还有值得验证的方向，模型却可能提交一份“无法解决”的分析，将它作为最终交付。已经做了大量分析，并不意味着 Goal 要求的结果已经得到。

遗忘：已有成果没有进入后续判断。 后续会话不知道前面检查过什么、确认过哪些条件，也找不到现成的样本和脚本，只能重新定位问题。前面的工作没有被后续研究有效利用。

陷入死胡同：反复沿用同一个未经验证的前提。 模型可能保留着大量历史，也不断提出新任务，但这些任务仍然集中在同一条路径上。操作看起来一直在推进，决定性的条件却始终没有被检查。

这些现象不能仅靠延长运行时间解决。继续执行之前，需要知道已有判断是否可靠，还有哪些问题值得验证，以及什么结果才算完成。

我倾向于从上下文组织来理解这些问题：每个阶段拿到了哪些信息，哪些历史被保留下来，执行结果怎样进入下一轮判断。这是我的设计视角，并不意味着上下文是所有失败的唯一原因。

2.2 分开局部执行与全局决策

一轮漏洞复现会留下大量代码阅读、样本调整和调试记录。这些内容对当前探索有用，但决定整个任务下一步做什么时，主要需要的是已经确认的发现，以及仍然缺少的证据。若将完整执行历史直接延续下去，下一轮还要从其中区分哪些是观察、哪些是猜测、哪些结论已经被后来的结果修正。

上下文压缩可以减少文本长度，但摘要保留哪些内容，本身又是一次判断。 某个暂时没有用途的细节，之后可能成为关键依据；一个没有保留适用条件的否定结论，也可能影响后续探索。因此，我更关心长期记录与当前输入怎样配合，而不只看上下文剩余多少空间。

Anthropic 的上下文工程文章讨论了压缩、结构化笔记和独立会话的不同用途。这些方法各有取舍，没有适用于所有任务的固定输入长度。

Spur 保留了 Cairn 的做法：Explore 深入处理一个问题，Reason 根据研究进展重新判断下一步。 Explore 结束时留下事实和报告，后续 reason 使用新的会话。原始记录仍然保存，遇到有疑问的结论时可以追查。

新会话提供了重新组织输入的机会，但判断是否可靠，仍取决于事实、条件和证据能否被准确传递。

三、Spur 的反馈回路

Spur 同样通过 origin 和 goal 定义任务。Origin 说明初始条件和操作约束，Goal 规定完成标准。例如，漏洞复现任务需要说明目标程序、已有材料、允许的修改范围，以及提交什么产物、怎样验证结果。

目标是后续判断的依据，但仅有目标并不足以组织长程研究。模型还需要知道当前已经确认什么、哪项假设尚未验证、上一轮失败发生在哪里。否则，即使不断要求它继续，也未必能产生新的有效工作。

3.1 执行结果怎样进入下一轮

我希望每轮反馈都能影响下一步行动。实验确认了某个条件，后续任务就可以使用它；假设被证伪，新的方向应当考虑这一结果；完成声明被驳回，就根据指出的缺口补充证据。

新项目首先执行 bootstrap，直接尝试完成目标。没有完成时，系统保存已经确认的发现，再进入 reason 与 explore 的循环。Reason 读取事实图及相关材料，判断目标是否满足，或提出新的 Intent；Explore 执行指定 Intent，并提交新的 Fact。

启用 reviewer 和 verifier 后，主要过程如下：

这些阶段的区别在于职责和输入重点。Reason 负责判断研究进展与后续方向，Explore 负责执行一个具体任务，Reviewer 复查已有思路，Verifier 核对完成声明。Explore 仍然可以读取事实图和相关报告，专注一个 Intent 不等于不了解整体目标。

我为每个阶段说明它的任务、能够参考的资料和结果提交方式，具体安全方法则交给模型选择。这样既保留了执行中的判断空间，也使下一轮能够明确识别上一轮交付了什么。

3.2 借鉴团队协作的经验

给 Spur 做长程任务设计的时候，我参考了一些现代人类组织的管理办法：

1、worker 只有一个核心目标：想尽一切办法完成 goal（OKR），至于实现路径自己拆解；

2、每个 worker 都要写进展和日报，进展是一句话总结，日报是详细报告，全员通晒，所有人都能看到其他人做了什么，整体的进展和发现，包括失败的尝试；

3、人人平等，每个 worker 解决时间只有 40min，能干了干，不能干写交接文档，换下一个 worker干；

4、每隔固定的一段时间，就会有 reviewer（主管），对 worker 当前的进度进行评估和审查，看有没有偏离主线，或者原地打转，有的话会给对应的建议和反馈；

5、如果有 worker 声称自己完成了 goal，则会触发审查机制，评估是否是真正完成了 OKR，还是有弄虚作假。如果有弄虚作假则驳回，且全员通晒；

6、不给 worker 设置放弃条件，默认下发的目标一定是有解的，没有解出来说明还没想清楚，再想想。

这段类比表达的是我对目标、交接、复查和验收的安排。其中的时间限制是示例，实际时长由任务配置决定；整个项目仍然受运行预算约束，操作者也可以停止任务。

管理经验最终需要落实为上下文和协议：报告中哪些内容可以作为事实使用，建议由谁判断，结果由谁核验，都要有对应的规则。角色名称本身不能保证这些工作被正确执行。

目前的测试已经让我看到，Spur 能让部分原本提前结束或长期停滞的任务继续推进，并最终交付结果。即使使用相对较弱的模型，也出现了持续研究十几个小时后完成高难度题目的案例。

四、记忆保存与会话交接

一次探索结束，前面的工作仍可能有用。模型或许已经定位关键函数，生成了一批测试样本，也确认了部分输入无法到达目标代码。这些材料都可以支持后续研究。

我不希望新的会话只得到一句“没有成功”。它需要知道已经检查了什么，失败发生在哪一步，现成样本和脚本保存在哪里，以及哪些假设尚未验证。只给出结果摘要，往往不足以接续工作；直接交付全部对话，又会把筛选信息的工作完整重复一次。

4.1 分层保存，按需读取

Spur 因此保留三个层次的记录：

• • 事实图保存已确认的观察和结论，供模型了解整体进展。

• • 报告记录证据、方法、尝试过程、产物位置和未完成的线索，供后续会话接续研究。

• • 原始会话保留完整对话及工具输出，在需要复核时提供更详细的依据。

模型先通过事实图找到与当前问题有关的报告，了解方法和尝试过程。依据不足时，再追查原始会话。记录可以随时查阅，不必全部进入每一次调用。

4.2 一次失败究竟排除了什么

报告的价值在于帮助下一轮继续工作，不能只复述本轮是否成功。

例如，一个输入触发了程序崩溃，但没有命中目标漏洞。报告应保留输入文件、崩溃位置、已检查的原因和待验证假设。后续模型才有条件决定：继续修改样本，尝试其他执行路径，还是暂时研究另一个问题。

失败记录尤其需要说明条件。“这组输入没有触发目标行为”与“目标行为无法触发”包含的判断不同。前者描述一次测试的覆盖范围，后者排除了更多可能。尝试次数很多，也不一定能支持更广的否定结论，因为这些测试可能始终没有覆盖同一个关键条件。

Spur 要求 Fact 的结论范围不应超过证据。 已经确认的部分可以提交，仍依赖未验证前提的部分留在报告中。新发现修正旧结论时，新增 Fact 说明修正及依据，旧记录也保留下来，便于追查判断的形成过程。

保留这些条件，Reason 才能判断一次失败排除了哪些可能，并据此安排后续验证。这样，失败尝试留下的材料仍然可以继续使用。

4.3 把研究交给下一轮

我参考的是交接工作的基本要求：材料能找到，结论能理解，未完成的部分能继续。文件和脚本必须实际保存，报告要写明位置；仍在运行的进程也要留下接手信息。

单次执行达到时限后，系统会尝试进入收尾阶段，在同一会话中要求 worker 停止新工作，保存现有材料，并提交能够确认的结果。下一次执行则重新组织上下文。收尾与新一轮研究的任务不同，不能要求一个已经耗尽预算的会话再完成一轮全面分析。

跨轮次交接也不排斥会话内的上下文压缩。Worker 在自己的执行过程中仍可能经历压缩。Spur 额外做的是明确不同轮次之间的交接内容，让全局决策主要依据经过整理的结果，同时保留追查细节的途径。

内部测试中，有任务持续了近二十个小时，后续会话仍能引用早期发现，并根据相关报告继续研究。

这让我看到，前面投入的计算能够留下可重复使用的成果。

五、Reviewer：用独立审查重新检查方向

已有记录保存得完整，也不代表下一步一定判断正确。模型可能连续提出不同任务，但这些任务仍然依赖同一个未经验证的前提。表面上每一轮都有新操作，整体研究却始终没有检查那个决定性的条件。

例如，模型尝试了多组输入，程序每次都在目标代码之前崩溃，于是逐渐接受“目标漏洞无法触发”的判断。问题在于，这些输入可能都采用了同一种处理路径。已有结果说明这条路径受阻，却不足以排除其他路径。

5.1 从已有判断中退一步

Reason 可以复查自己的判断，但它此前已经参与了任务安排。我希望另外提供一次独立审查，专门检查研究方式是否遗漏了重要问题，不必同时承担推进原方向的任务。这是 reviewer 的作用。

Reviewer 读取分配给本轮的事实图快照、相关报告和会话索引。它需要检查当前工作是否仍然服务于 Goal，关键结论依赖什么前提，以及哪些方向是在证据不足时被排除的。报告不能说明问题时，可以追查原始工具输出。

Reviewer 的建议不能直接当作事实使用。某条路径值得重开，不代表它已经可行。需要新实验才能回答的问题，交由后续 Explore 处理。

Reviewer 主要输出 Hint，不直接修改事实图，也不接管正在执行的任务。Reason 结合最新事实决定怎样使用建议。审查期间其他工作可能继续推进，建议依据的快照未必包含新结果，需要一并考虑。没有新的、有证据价值的建议时，reviewer 可以不输出 Hint。

在一次内部漏洞复现任务中，多个探索方向都没有取得目标结果。Reviewer 复查后指出，已有工作集中在处理一个较早发生的异常，对目标行为本身的触发条件检查不足。后续审查又要求重新检查部分否定结论的适用范围。这些建议被转成新的探索任务，促使执行者重新验证此前接受的前提。

审查应指出哪个判断缺少依据，以及下一轮可以验证什么。 如果只复述现有结论，增加一个“反思角色”未必能改善决策。

5.2 提供思考的武器

Spur 中只内置了唯一的一个 Skill：deep-think（深入思考）。我认为，以当前模型的能力，不必再为不同安全问题预先写好具体的解题步骤；更值得提供的是帮助它分析问题的思考方法。

deep-think 的核心是第一性原理、苏格拉底式追问、辩证法等通用思考方法。 它也鼓励模型调整观察问题的层次。研究受阻时，可以据此重新检查目标的必要条件、当前接受的前提，以及足以推翻已有解释的证据。

面对“这种方法已经不可能成功”的结论，模型需要检查实际排除了哪些条件；对于复杂过程，可以重新分解输入、处理和结果，定位失败发生在哪一步。列出方法名称还不够，需要据此提出能够通过实验回答的问题。

六、持续探索与 Verifier 验收

持续研究还需要一个明确的结束标准。在这类求解任务中，我按目标可达的前提安排工作，不希望模型仅仅因为当前尝试失败，就把“无法完成”当成最终交付。

Spur 要求 reason 在目标尚未满足、且没有未结束的 Intent 时提出新的探索方向。可以尝试其他方法，也可以复查先前的否定结论，但新的任务应当能够补充证据。仅仅换一种说法重复分配原任务，不能构成继续执行的理由。

项目仍然有运行预算。达到时限或操作者要求停止时，任务可以结束；这类结束也应与目标已经完成区分。不给模型自行放弃的正常业务出口，是为了减少过早结束，不能据此推导出每个提交目标都一定能够解决。

6.1 完成声明还需要证据

模型声称完成时，还需要另一次判断。以漏洞复现为例，一个样本造成程序崩溃，并不能单独证明它复现了指定漏洞。异常可能来自其他缺陷，也可能依赖修改后的程序或前一次运行残留的状态。结果表面上符合预期，实际验证的却可能是另一个问题。

测试中还遇到过更直接的 reward hacking：任务要求挖掘已有漏洞，模型自行构造出一个漏洞，然后将其作为完成依据。产物和报告都可以存在，但原来的任务并没有完成。

我将完成声明与验收分开。 Reason 或 bootstrap 提交 Completion，说明支持目标已满足的事实；启用并配置 verifier 后，再由 verifier 根据原始 Goal 核验。执行者的描述属于待检查材料。

核验以明确的 Goal 为前提。结果、证明方式和操作约束不应等到验收时再决定。Verifier 可以解释原始要求，不能为了接受某次提交而降低标准，也不应追加作者没有提出的条件。存在影响结论的歧义时，需要由操作者澄清。

6.2 复现提交的结果

Verifier 需要检查两件事：要求的结果是否实际发生，以及它是否通过任务允许的条件和过程产生。能够重跑的关键步骤，应独立复现；不能重跑的部分，必须追查证据，并在结论中说明哪些经过实际验证、哪些只做了记录审计。

核验对象是对方提交的结果，不能用核验者修补后的结果代替。

例如，Verifier 必须修改样本或补充关键步骤才能成功复现，就应记录这些缺口，要求继续完善原提交。如果依赖旧状态才出现预期输出，也需要确认这些状态是否符合 origin 规定的初始条件。

验收以原始要求为准。模型采用了设计者没有想到的方法，只要过程与结果符合要求，就应当接受。需要检查的是目标、标准和证据是否被改变，不能只因方法偏离预想就驳回结果。

前面提到的那次漏洞复现任务中，模型后来将“目标无法实现”的分析作为完成声明提交。Verifier 指出，这份分析没有交付 Goal 要求的产物。研究继续进行，先前排除的方向被重新检查，之后才产生了符合目标的结果，并通过独立复现。

这次驳回使研究回到 Goal 要求的交付上，但不能据此断言驳回一定带来突破。反馈的作用是指出具体缺口，让后续研究有依据继续。

6.3 核验状态与判断局限

实现中，我保留了核验状态与过程记录。未配置 verifier，或核验执行连续故障达到相应阈值时，完成声明可能未经核验被接受；这种结果会留下标记，供操作者复查。对完成结论有新的证据时，也可以重新打开任务。

Verifier 的会话虽然独立，仍可能受到提交材料影响。它需要追查原始依据、重跑关键步骤，并留下核验记录。报告写得可信，不能代替这些检查。

七、提示词与结果协议

提示词说明本轮的任务和交付标准，结果协议规定结果怎样提交和传递。我在这些描述上做了多轮修改，重点是减少歧义，并保留对不同安全任务的适用性。

7.1 提示词的约束范围

提示词规定职责、交付标准和操作范围，具体安全方法由模型选择。 例如，Fact 应当表达已确认的观察，并保留适用条件；Verifier 应当依据 Goal 作出判断，并说明对应证据。这些要求可以用于不同任务，不依赖某个漏洞的特定解法。

协议字段、提交次数和不能接受的完成方式，也需要明确规定。能够通过程序校验的约束，由程序处理；其余要求则需要在提示词中清楚说明。

遇到单个失败案例时，我会谨慎考虑是否增加特殊规则。它可能改善当前题目，却排除了其他任务中合理的方法。每次修改都需要分清通用标准与特定环境下的要求，避免把后者施加给所有任务。

7.2 通过工具提交结果，减少歧义

Cairn 的执行协议要求 worker 返回指定结构的 JSON，Spur 改为使用 MCP 工具接收各阶段的正式结果。系统可以直接识别提交的类型，不必再从自然语言回复中判断哪一部分应该被接受。

Explore 用 submit_fact，Reason 用 submit_intents 或 submit_completion，Reviewer 和 Verifier 分别提交建议与判定。每个阶段只提供当前合法的结果工具，完整推理过程和证据则留在报告中。

正式结果通过字段提交后，系统可以校验必填项、引用和结果类型。这解决的是结果表达和传递的歧义；格式校验通过，并不说明内容本身正确。

7.3 按独立要点组织 Fact

一轮探索可能同时确认几件事，后续任务往往只需要引用其中一项。我因此将 Fact 的内容组织为标题和独立要点。模型可以说明它使用的是哪条事实中的哪个结论；纠正旧判断时，也可以点名需要修正的部分。

拆分不能删掉必要条件。每个要点被单独阅读时，仍应说明对象、范围和结论。方法与大段证据由报告提供，Fact 则负责准确表达观察，并为后续查阅提供索引。

八、面向 Agent 的原子求解单元

我希望 Spur 尽可能小，职责尽可能明确。

实际安全工作的范围很大。资产整理、批量检查、代码审计和深入验证，有不同的执行方式，也往往已经由其他工具承担。如果为了引入一个求解器，就要求使用者重新采用整套工作流程，它反而很难被持续使用。

8.1 一个目标，一次求解

我选择让 Spur 接收一个目标明确的任务，负责组织持续研究。材料准备、任务优先级以及结果返回后的安排，由外层流程处理。一个流程可以多次调用 Spur，也可以只将需要反复探索的部分交给它。

“原子”描述的是调用边界，一次求解内部仍可以持续多轮。 对调用者而言，它始终围绕同一个目标运行，有明确的输入、过程记录和结果。

多个任务之间怎样并行、串联或按条件选择，由外层流程决定。

8.2 让其他 Agent 调用 Spur

我将其他 Agent 作为主要使用者。它们持有用户需求和项目上下文，可以定义目标、提交任务、观察进展并补充线索。管理接口以 CLI 为主，配套的 driving-spur skill 说明这些操作的用法。

driving-spur 中最重要的内容，是怎样把需求定义成一个可以验收的目标。调用者需要说明结果、证据和必要约束，不能只把“研究一下这个问题”交给系统，再期待它自行猜测完成标准。禁止采用的捷径也应事先说明，以便执行与核验使用同一组要求。

准备好环境和任务材料后，可以通过命令提交和观察。以下路径为示例，后续操作使用提交返回的项目 ID：

# 启动服务
spur serve
# 在另一个终端提交任务spur submit --title "漏洞复现" \
  --origin "目标程序与说明位于 /workspace/task，不修改目标程序" \
  --goal "提交能够复现指定漏洞的输入文件，并提供验证记录"
# 查看状态与进展spur status project_001
spur graph project_001 --format timeline
# 补充线索，或主动请求一次审查spur hint project_001 "请检查现有结论是否覆盖目标环境"
spur review project_001

调用后，外层 Agent 可以根据事实图和报告判断进展。发现遗漏线索时提交 Hint，需要复查方向时请求 Review，对完成结果有异议时依据证据提出重新研究。调用者不必参与每一次工具操作，但仍然保有对任务的观察和干预能力。

8.3 部署与执行环境

Spur 从最初就采用 Go 实现，以单个二进制交付。这样可以简化自身的部署与调用。实际执行仍复用 Claude Code、OpenCode 等 Agent 及其工具环境；Docker 模式为项目提供独立环境，host 模式则用于复用已经准备好的宿主环境。这些是运行方式的选择，不改变求解的主要过程。

项目内部的 worker 组、时间预算、并发数量和提示词，都可以按任务需要调整。

九、测试中的观察

Spur 在 CyberGym 上的得分为 91.8%。该测试没有针对榜单单独优化求解流程。渗透和二进制任务也使用同样的基本机制，根据目标、材料和运行配置开展研究。

在一道内部测试的高难度题目上，一个较强的模型配合 Claude Code 进行了长时间探索，最终判断题目有问题、无法完成；另一个相对较弱的模型配合 Spur 持续运行约十五个小时后，完成了解题。由于模型和运行条件不同，这个案例不能作为 harness 增益的严格对照。它让我继续追问：模型声称无法完成时，是否还有值得验证的方向？

这套方法的成本不低。多轮探索、报告读取和独立核验都消耗时间与 token，而且并不是每次投入都会得到新的发现。我希望研究的是，在既定模型下怎样更充分地利用它的能力。更强的模型如果能更早找到方向，同样可能大幅减少这些成本。

十、模型进步以后

我把这些设计理解为降低模型的思考摩擦力。 模型已有相关知识，仍需要合适的信息和工具才能用于当前问题。事实与猜测是否分清、依据能否找到、不同发现能否关联，都会影响后续研究。

这与合适的数学记法有些相似。勾股定理写成 a² + b² = c²，熟悉这些符号的人可以直接辨认变量之间的关系。记法并没有替人完成证明，却减少了理解和表达关系的负担。我希望事实图和报告也能起到类似作用：让模型可以使用已有发现，而不必每次从完整历史中重新整理。

10.1 架构设计也要经受实践检验

做 Spur 时，我也尝试过让 AI 设计 harness。得到的方案并不总是理想：一次运行失败就增加一条规则，遇到另一道题又加入特殊处理。局部问题有时解决了，但整个系统是否需要这些机制，仍要重新判断。在我的这些尝试中，模型还没有稳定给出 Cairn 那样让我认可的架构。

我猜，这与架构设计的反馈方式有关。具体错误通常能通过测试复现，修改是否有效也容易判断；harness 是否简洁、适用范围是否足够、换模型后是否仍有价值，需要更长时间和不同任务检验。一次分数提高，无法充分回答这些问题。

这个解释也只是我的判断，不能据此认定模型缺少某种永远无法获得的能力。今天需要我反复检查的设计，未来可能由模型完成得更好。

10.2 模型与 harness 拼成一个圆

模型和 harness 需要共同拼成一个尽可能完整的圆。 模型在当前任务中还不稳定的地方，harness 通过工具、上下文组织和反馈来补足。模型能力发生变化，harness 也要随之调整：已经能够由模型承担的工作，可以简化相应的工程；面对更复杂的任务，还需要重新检查哪些支持有所欠缺。

Anthropic 在 Managed Agents 的文章中举过一个例子：为解决旧模型过早结束任务的问题而加入的上下文重置机制，在换用另一个模型后不再需要。这类经验提醒我，针对当前能力设计的机制，应当允许被重新评估和替换。

我会问自己：模型或工具更新时，我是开心还是紧张？ 如果更简单的系统已能完成同样的任务，就不应仅因投入过开发成本而保留原来的复杂性。

Spur 的这些设计，都是我基于当前模型能力作出的判断。我期待有一天，今天还要靠工程反复提醒、检查的能力，已经被模型内化，许多复杂的安排也随之不再必要。 那时，我需要更新自己的认识，也有机会用更简单的工具去处理更难的问题。

10.3 让更多想法有机会实现

最近的 TCH 圆桌讨论中，一种观点强调传统技术训练积累的判断力，另一种提醒我们，新的学习者未必需要重复相同路径。我认为两者可以同时成立。AI 让人有机会更早开始制作、验证自己的想法，我们也需要根据实际成果，重新理解学习和能力。

Alexandr Wang 在与 David Senra 的访谈中谈到，人小时候往往有很多想法，进入成年生活后，却逐渐失去了追求它们的动力。他期待 AI 能帮助人把愿望付诸行动，完成一个目标之后，再去尝试更大的目标。我认同这种期待。

对我来说，模型带来的惊喜，也包括重新认识自己能够做什么。一项过去没有精力持续推进的安全研究，一个一直没有开始的项目，甚至小时候那些后来不再认真谈起的想法，都可能随着模型能力的进步而有新的机会。

我期待认知再次被刷新的那一天，也希望到那时，我们已经开始把其中的一些想法变成现实，成为一个不那么无聊的大人。