智能体能力与用户判断力不对称：最新深度对比分析完整报告

Peri Code: Agent 能力与用户判断力的非对称博弈

你打开Claude Code或Peri，丢下一句“重构消息管线”，转身离开。三小时后回来，Agent已经跑完。800行代码，横跨12个文件，改了5个trait，测试全部通过。你坐下读代码，读到一半就意识到问题——Agent抽象的那个trait形状，恰好破坏了你原本打算保留的流式语义边界。整套抽象，必须推倒重来。

这一回合里，Agent展现了四个维度的能力。它自主拆解了消息管线重构的子任务，高度自主；三小时持续执行无需你介入，高度自动；跨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越强大越不能省的动作。