从一次 TabUF 评测架构纠偏出发：解耦的目的，是让不同事物独立生长，而不是把未来分别关进固定盒子。
Agent 最危险的错误，不只是做错，而是在自己还没有资格确定的时候，把猜测写成标准，把局部经验写成未来必须服从的制度。
今天整理 TabUF 的评测体系时，我差一点又犯了一个很熟悉的错误。
这个项目已经积累了很多历史实验：不同版本的模型、不同 benchmark、不同 runner、不同 gate、不同机器上的结果和状态。目录确实有些混乱，很多文件也承担了不止一种职责。于是我们开始做解耦：把 candidate identity、benchmark、run、evidence、decision 和 public claim 分开，让一项事实只有一个权威来源。
这个方向本身没有问题。
问题发生在下一步。
Agent 很快给出了一套整齐的对象模型，又写出了 v0.1 YAML 模板。每个对象有字段、有状态、有枚举，两个旧 benchmark 也被接进了统一结构。整个系统一下子显得清楚、专业，而且“已经完成”。
然后我突然意识到：如果我们把这些 v0.1 working templates 写成未来所有 benchmark 都必须服从的固定 Schema，那么我们并没有真正解决混乱。
我们只是把旧的混乱，换成了新的僵硬。
Agent 很容易用结构制造完成感#
这不是某一个模型偶然犯下的小错误。我在很多项目里反复看到同一种倾向。
Agent 一看到混乱，就想整理；一看到缺口，就想补齐；一看到几个相似案例，就想抽象；一遇到未知，就想命名、分类、枚举，然后写进 Schema、接口和流程。
这套动作很自然，因为它们都能产生清晰、可见、容易汇报的 artifact。一个开放问题可能还没有成熟答案，但一套目录、一张架构图、七份模板和九个 gate 可以在很短时间里生成出来。只要格式足够完整，我们就很容易获得一种错觉：问题已经被理解了。
但结构的完整，不等于理解的完整。
比如：
- 当前实现只支持三种 prediction object，很容易被写成“系统允许三种 prediction object”；
- 某个 benchmark 使用
task × split × seed，很容易被提升成所有 future job 的固定代数； - 两个项目碰巧都有相似 receipt，很容易触发一个 shared interface；
- 一次实验使用固定 pipeline，很容易变成所有 candidate 的 mandatory workflow；
- 一个局部 capacity guard，很容易被误写成模型或 benchmark 的长期能力边界。
这些变化在文字上往往只差一点点：从“currently supported”变成“accepted”，从“working vocabulary”变成“schema”，从“当前 carrier”变成“architecture contract”。
但它们在系统意义上完全不同。
前者是在诚实描述当下；后者是在替未来作决定。
Agent 越强，这个问题可能越严重。因为生成代码、文档和抽象的成本正在快速下降。过去一个团队要花几周才能把错误理解制度化；现在一个 Agent 可能在一次任务里就完成对象建模、Schema、validator、文档和测试，把一个尚未成熟的假设变成一套看起来牢不可破的工程事实。
能力越强，错误制度化的速度也越快。
我不是反对 Schema，也不是反对结构#
这里很容易走向另一个误解：既然过早抽象危险，那是不是应该拒绝 Schema、接口、协议和工程纪律？
当然不是。
这次 TabUF 评测体系里，有一些边界就应该明确：candidate identity 不能被一次 run 的结果反向修改；train、validation 和 test 不能混用；source、config 和 checkpoint 必须可追溯；silent fallback 不能冒充真实 backend；evidence、research decision 和 public claim 不能互相替代。
这些约束值得冻结，因为它们防止系统说谎。
但 prediction object 未来还能长出什么形态、benchmark 最终需要什么 plugin interface、一个 cheap probe 要不要拆成七份文件、状态 vocabulary 会不会继续变化——这些事情，目前没有足够证据替未来决定。
我的阶段性判断是：
冻结不诚实的可能，不冻结创新的可能。
或者换一种说法：
语义应该分清，形态不要锁死。
解耦的目的，是让不同事物能够独立生长，而不是把它们分别关进几个固定盒子。
如果我们把一个混乱的大文件拆成七个对象，随后要求所有未来项目都填写七份表格，这可能并不是真正的解耦。语义确实分开了，但生长路径也被提前写死了。
这正是我为什么提出 MSP#
我提出 MSP / msp4agent，并不是因为世界还缺一套项目管理方法，更不是想给 Agent 增加一个新的固定流程。
我更想解决的是一种 Agent 的高频认知偏差：能生成，不等于现在应该生成；能抽象，不等于现在应该抽象；能给出完整答案，不等于问题已经到了可以定型的时候。
MSP 的核心策略是：
Seed it till it grows.
很多开放问题的正确结构，不可能在第一天通过纯粹思考完整推导出来。它只能在真实行动、失败、反馈和新的理解中逐渐显现。
所以 seed 不是一个等待填满的模板。它是对当前认知边界的诚实表达：我们知道什么，不知道什么，真正关心什么，下一步最值得验证什么，以及哪些复杂度现在应该 Strategic Deferral。
Minimal 也不是为了小而小。它意味着只作出当前证据真正支持的最小承诺，同时保存足够完整的信息，让未来的人和 Agent 还能把事情接起来。
这也不意味着只写 seed、不行动。
恰恰相反，我们应该尽快推进一个真实 wedge：做一个实验，跑通一个最小闭环，交付一个真正被使用的功能，让现实给我们的抽象施加压力。该具体的地方要非常具体；没有想明白的地方，不要为了文档完整而假装已经想明白。
好的 Agent 不只是会 grow，也应该会 defer、prune 和重新 seed。
有时候，进步不是新增一套框架，而是把一个过度展开、正在锁死未来的框架重新折叠回 seed。
抽象应该从真实摩擦中长出来#
我现在越来越警惕“因为看起来相似，所以应该统一”这种冲动。
一个抽象真正值得进入共同层，不应该只因为我们能写出它，而应该因为真实工作反复暴露了同一种摩擦，并且这个抽象确实能减少摩擦。
在准备新增全局 Schema、公共接口或统一流程时，我更愿意先问：它防止了什么真实伤害？我们已经在哪些真实任务里遇到了同一个问题？如果不做这层抽象，当前工作真的无法继续吗？未来出现不同对象时，它还有退出和生长的空间吗？
这些不是我想再发明的一套 checklist。它们只是提醒我，在高速构建之前停一下，区分工程必要性和心理完成感。
有些边界只需要留在 benchmark-local carrier 里；有些字段只是一轮实验的 diagnostics；有些相似性还不足以成为 shared package；有些问题甚至还不配得到一个答案，只值得先得到一个更好的问题。
我完全可以接受很多重要事情当下没有成熟答案。
但我不愿意接受：因为我们不擅长面对未知，就用一套完整结构把它伪装成已经解决。
Agent 越来越强以后，克制会成为一种工程能力#
过去，我们担心 Agent 做不出来。
现在，我开始更担心 Agent 什么都做得出来，而且做得太快。
当生成变得便宜，真正稀缺的会是判断：什么应该被构建，什么应该继续保持开放；什么是当前实现，什么是长期本体；什么值得成为制度，什么只是一颗还需要现实照料的 seed。
好的治理，不是提前替未来作出所有决定，而是保证未来仍然可以基于新的事实作出决定。
好的系统，也不是没有未知，而是不会把未知伪装成已经完成的设计。
所以我想把这次小小的评测架构纠偏记下来。它提醒我：Agent Engineering 不只是让 Agent 更会规划、更会编码、更会使用工具。我们还需要让 Agent 学会保护问题，尊重 owner 尚未写出的判断，并在适当的时候克制自己的完整性冲动。
我还没有一套成熟的方法回答：怎样把这种克制真正做成 Agent 的稳定能力，同时又不把“克制”本身写成另一套僵硬流程？
这也许正是 msp4agent 接下来最值得继续生长的问题之一。
先不急着回答它。
先把这颗 seed 种下来。