Peri Code: Agent 能力和用户判断力的不对称
Peri Code --- 用 Rust 写的开源 Coding Agent，兼容 Claude Code 生态。github.com/KonghaYao/p...
打开 Claude Code 或 Peri，给 agent 一个 goal（用户设定目标、agent 自动续跑到完成的执行模式）「重构消息管线」，按 enter，离开去做别的事。三个小时后回来，agent 已经跑完了。800 行代码、跨 12 个文件、改了 5 个 trait，测试通过。你坐下来读代码，读到一半发现，agent 抽象的那个 trait 形状，破坏了你原本打算保留的流式语义边界，整套抽象要推倒重来。
这一回合里 Agent 表现出 4 个维度的能力。它自主分解了消息管线重构的子任务（高自主），三小时持续执行不需要你介入（高自动），跨 12 个文件写了 800 行代码（强执行），从 trait 抽象到适配器实现再到测试的多个层面都被改动（广覆盖）。你那一端只有一句模糊的 goal。Agent 太强了，把这句模糊 goal 里所有缺位的判断放大成了 800 行偏离的代码。
Agent 能力进化与用户判断力滞后的对照
当前 AI Agent 的能力在四个维度上同时快速进化。决策权从用户转移到 agent，agent 自己分解任务、选实现路径、决定下一步。介入频率被压到最低，agent 在用户离开的情况下持续执行几小时。单次任务的执行规模显著放大，能跑完几百到几千行代码改动、跨多个文件。覆盖范围从架构延伸到实现、测试、文档多个层面。
用户端需要跟上的是判断力------什么方向是对的、什么实现是稳健的、什么改动会破坏现有架构、什么取舍是可以接受的。这种判断力需要用户对自己的项目有深度把控，对架构规则有清晰认知，并明确取舍边界。大部分用户没在这个层面做训练。
不对称的后果是 Agent 每变强一档，用户的判断弱势被放得越大一档。Agent 弱的时候，用户每个 commit 都在自然做微调，错误方向被持续纠正；Agent 强的时候，用户介入频率压到最低，单次介入的判断密度被推到最高，缺位的代价被工具的力量放大成不可逆的代码改动。
goal 和 dynamic workflow 是高自主 Agent 的极端形态
goal 和 dynamic workflow（agent 自行分解任务步骤的执行模式）是当前高自主 Agent 最极端的两种形态，把能力不对称暴露得最显眼。
goal 模式把用户介入频率压到两次，设定目标和接收结果。中间所有价值判断，做不做某个子任务、用哪种实现策略、是否打破现有架构、做到什么程度算完成，全部由 agent 完成。dynamic workflow 走得更远，用户连路径都不提供，只提供「我要做 X」这一句话，agent 自己决定怎么拆、怎么做。
这两种工具的设计假设是「用户已经想清楚自己要什么、agent 替用户执行」。在用户确实想清楚的情况下，这套机制是高效的杠杆。工具不能验证用户是否真的想清楚了------它接到任何目标都照常工作。用户给一个模糊的目标，agent 沿着模糊方向生成路径；用户给一个错误方向的目标，agent 沿着错误方向跑。
工具厂商不能解决这个问题。Peri 自己也复刻了 codex 的 /goal 系统，越实现越确认这个设计在它的工作范围内是对的------它确实能替用户高效执行。但工具的工作范围默认了用户侧的判断力到位。这个默认在高自主 Agent 时代是危险的，大部分用户没意识到自己被默认成了「判断力到位的人」。
用户判断力缺位的三种形态
认知缺位------用户被「自动化」话语诱导，根本不知道自己在关键节点需要做价值判断。「设定目标、自动续跑」这种营销话语暗示「人可以退出」，用户真的以为自己可以退出。用户只是从执行链路里退出，价值判断的责任一点没少，只是被默认成了「LLM 觉得合理」。
能力缺位------用户知道要做判断，但不知道怎么做。大部分用户没培养 plan（在脑子里跑一遍路径、阶段里程碑、每步取舍规则）的习惯，开口前不会先把目标拆解、把架构约束想清楚、把取舍边界定下来。这种能力需要训练，大部分人没训练过。
姿势错位------用户把 goal 当 plan 用。goal 是「我要去哪」，plan 是「分几步走、每步的取舍规则、不做什么」。用户跳过 plan 阶段，把一个 goal 直接喂给 agent，期望 agent 自己生成路径。路径里的每一个分叉点都是价值判断，agent 没有这个判断所需要的信息，比如产品方向、架构规则、稳健性标准。它只能用 LLM 训练数据里的「统计合理」替代用户的「具体判断」。统计合理在通用场景下成立，在你的项目里未必成立。
不对称累积的三层代价
能力不对称的代价分三层渐进累积。第一层是返工。Agent 沿着模糊或错误的初始目标跑偏方向，用户回来 review 发现路径不对，推倒部分代码重写。返工的成本是执行时间的几倍，你不仅要重写，还要先理解 agent 写的代码、定位跑偏点、判断哪些能保留。
第二层是架构失守。Agent 在某个关键节点做了破坏架构的决策，比如抽象错的 trait 形状、引入不对的依赖、选了不对的状态机划分，后续所有代码都建立在这个错误决策上。代码能编译、测试能通过，但项目的架构骨架已经偏了。等你发现的时候，往往整套建立在错误地基上的代码都要重新设计。
第三层是项目失控感。多次返工和架构失守累积后，用户不再信任自己对项目的把控力。用户面临两种走向，彻底放弃自动化回到手动，效率跟不上项目节奏；或者彻底放弃判断完全依赖 agent，项目方向脱离用户的实际意图。
plan 作为开口前的判断闸门
Agent 能力的进化不会停，用户判断力的训练只能靠用户自己。这个不对称会持续存在，会随着 Agent 变强继续扩大。
在开口前把 plan 在脑子里跑一遍------你要去哪、怎么走、哪些实现不能碰。这些判断只能由用户做。Agent 越强大，越要在开口前完成这个动作，否则工具的力量会替你把缺位的判断放大成不可逆的代价。
开头那个 800 行返工，问题在你那句模糊的 goal。下次开口前，先把 plan 想清楚------这是 Agent 越强大越不能省的动作。