Grok Bot 团队提出 Agent 信任四层倒金字塔：精力优先投向代码库

• 前情提要：同一作者 Lauren（@poteto）此前公开过 pstack 的「工程原则」设计——把冗长操作步骤压缩为可命名的短原则，并要求 Agent 在决策时点名所引用的原则；该方案以 Cursor 官方插件形式发布。
• 最新框架：Lauren 提出一套四层「倒金字塔」，用于回答如何更信任 Agent 的工作成果。四层按精力投入从上到下递减排列：代码库改进（最多）→ 静态分析 → 文字性指导 → 人工审查（最少）。核心主张是与其花精力「管教」Agent，不如改造代码库本身。
• 第一层做法：更好的架构、更强的类型系统与不变量、清晰的模块边界。理由来自 Agent 的行为特征——倾向于复制已有代码、走最短路径，因此让最短路径本身就是正确路径，比事后纠偏更有效；作者称这本质上「就是好的软件工程」。
• 第二层做法：Lint 规则、测试、CI、形式化验证（如 TLA+）。定位是性价比最高的第二道防线，用极低的 token 成本在问题早期拦截，反馈是确定性的，不依赖 Agent 是否正确「理解」了什么。
• 第三层与第四层的定位：注释、AGENTS.md、Skills 描述等文字性指导的共同弱点是无法强制执行，需 Agent 自行判断是否遵守，只能作为补充，用于确实需要主观判断的场合。人工审查最难规模化——按当前 Agent 提交代码的速度，逐行检查每个 PR 已不现实，人的精力应投向更上游：设计出让 Agent 默认就做对的环境。
• 倒置的理由：越往上层，手段越确定（代码结构直接决定 Agent 能走什么捷径）且 token 越高效（不需要反复沟通纠偏）；越往下层，越依赖不可靠的理解与不可扩展的人力。作者将此与业界「从 prompt engineering 转向 context engineering」的方向对齐，但推得更远——连提示词本身也只是第三等手段。
• 落地路径：帖子给出可复制的操作，安装 cursor/plugins 中的 pstack 后新建 Project，让 Agent 依次做三件事——翻查 Slack 与代码评审中给过的反馈、用 /recall 复盘过去如何被纠偏、用 /poteto-mode 配合 /correct 与 /architect 找出 Agent 最常踩的坑并提出针对自有代码库的重构计划，要求以原型而非提问来回答未决问题。
• 信息边界：这是一条社交平台线程，未提供任何量化数据、对照实验或团队落地结果，属于方法论主张而非已验证结论；四层框架的实际收益取决于代码库类型与 Agent 工具链，尚未见第三方复现。
• 行业观察：把「信任」问题从提示词与审查环节前移到代码结构与静态约束，意味着 Agent 工程的成本重心可能不落在模型侧配置，而落在既有代码库的改造投入上；这也与近期「生成侧接近饱和、瓶颈转向审查与验证」的多条线索同向。

🔗 原帖转述 | Lauren 原帖 | pstack 插件仓库