全部 · 2026-04-25

作者把问题打在了一个很疼的点上：LLM 让知识工作的廉价质量代理失效。拼写、格式、语气、结构、代码风格、PR 里的礼貌 review，以前都不是质量本身，却能筛掉一批低投入产物。现在 ChatGPT 和 Claude Code 可以用几秒钟补齐这些表层信号，团队还按旧规则验收，当然会被污染。 我同意这篇的主判断，但我不太买它最后那种“我们自动化进 Goodhart 定律”的收束。这个说法有力，但也有点太干净。知识工作原来就没那么真。咨询报告、OKR 文档、架构评审、代码 review 里，本来就有大量表演性劳动。LLM 做的不是凭空制造一个假世界，而是把原先靠人肉维持的假信号便宜化、规模化、自动化。差别很大。前者像技术带坏了组织，后者像技术照出了组织早就靠代理指标运行。 文章举了两个例子。一个是市场分析报告：日期错、拼写错、图表重复，以前足以让人丢掉报告。另一个是代码审查：工程师生成几千行看着还行的代码，同事再让 AI review，一轮问题被修掉，仪式完整，质量未必存在。这两个例子很准，因为它们都卡在“重做一遍太贵”这个条件上。市场调研要验证样本、渠道、时间点、竞争格局；代码审查要理解上下文、边界条件、线上负载、未来维护者。正文没有给实证数据，也没有引用团队事故案例，所以它不是一篇证据型文章，更像一篇经验判断。但这个经验判断在 2025 到 2026 的 AI 编程潮里很常见。 我自己见到的更危险版本，不是“LLM 生成了坏代码”。坏代码一直有。危险的是 review 的社会含义变了。以前 LGTM 至少表示一个人承担了最小责任，哪怕只是扫了一遍。现在很多 PR 下面的 AI review comment 会制造一种“已经被检查过”的空气。Claude Code、Cursor、GitHub Copilot Workspace 这一类工具把生成、修复、解释、测试建议连成闭环后，人会更容易把 review 从判断动作降级成流程确认。正文说“第 17 个 Claude Code session”有点调侃，但这个细节很像真实工作流。 这里需要补一层外部背景。OpenAI、Anthropic、Google 这两年都在把模型卖成 agent，而不是单次问答。Anthropic 尤其喜欢强调 Claude Code 在真实工程任务里的表现，SWE-bench Verified 也成了各家发布时绕不开的数字。问题是，SWE-bench 这种 benchmark 仍然有明确测试集、明确 issue、明确通过条件。企业内部的“这段代码会不会让下季度的人崩溃”没有这么干净的 oracle。模型越擅长通过可测任务，组织越容易误以为不可测任务也被覆盖了。这里才是 Goodhart 真正咬人的地方。 作者把 LLM 训练也归到同一个结构里：预训练优化语料概率，RLHF 优化 judge 偏好，不直接优化真实性或有用性。这个说法方向没错，但有点简化。现在主流系统早就不只靠朴素 RLHF，RLAIF、tool use、verifier、process reward、execution feedback 都在补这个洞。代码领域尤其明显，能不能编译、测试能不能过、patch 能不能合并，都是比“看起来像好答案”更硬的反馈。可是作者的批评仍然成立，因为大量知识工作没有测试用例。市场报告没有 pytest，战略判断没有 CI，管理备忘录没有单元测试。 所以我会把这篇的结论改得更窄，也更狠：LLM 最先腐蚀的不是高价值判断，而是组织里那些只剩代理指标的环节。凡是交付物能被“看起来专业”替代，凡是验收者没有时间重做，凡是责任链靠文档签字和 LGTM 传递，那里都会先塌。反过来，有强反馈的地方会更快吸收 LLM。编译器、测试、仿真、线上指标、A/B 实验、类型系统、formal verification，这些东西会把模型产物重新拉回现实。 我对文章的一个疑虑是，它把“表层代理失效”和“无法评估质量”绑得太死。代理指标可以换，不只能怀旧。代码审查可以要求可复现测试、diff 级解释、风险清单、owner 签名；研究报告可以要求原始数据、引用快照、反事实检验、预测记录；内部决策可以要求 30 天后回看命中率。问题不是 LLM 让评估不可能，问题是很多组织过去懒得建设评估，现在被迫补课。 这篇适合给 AI 团队当警报，不适合当反 AI 宣言。别把它读成“LLM 只是模拟工作”。更准确的读法是：LLM 把廉价验收机制打穿了。如果团队还用 2022 年的 review 仪式接 2026 年的 agent 产能，产出会越来越像工作，责任会越来越不像责任。

Stash 公开了 28 个 MCP 工具和 6 段流水线。我的判断很直接：这条有用，但宣传喊得太满。它现在更像一层可移植的 agent memory middleware，不是把 Claude.ai 和 ChatGPT 的记忆能力开源复刻了。 页面给出的硬信息其实不差。后端是 PostgreSQL 加 pgvector。命名空间是树形路径。写入精确到单一路径。读取支持子树递归。这个设计很务实，也解释了它为什么先走 MCP：工具接口比绑死某家 agent framework 更容易迁移。对做多 agent 系统的人，这比“能记住你”那句口号更有价值。你要在 Claude、OpenAI、本地模型之间切换，记忆不跟模型绑死，工程上就顺很多。 但我对“RAG 不会学习，Stash 会成长”这套对比有点警觉。这个说法拿来做 landing page 可以，拿来指导系统设计就粗了。RAG 早就不只是“搜文档”。过去一年很多团队都在做 episodic memory、summary memory、entity memory、preference store、tool trace replay，只是名字不统一。MemGPT、Letta 这一路，早就在讲分层记忆和上下文分页。LangGraph、Zep、一些 agent 平台也都在补长期状态。Stash 的新意不在“第一次让 agent 有记忆”，而在它把 namespace、MCP、Postgres 这套组合打包得够直接。 问题也刚好在这里。长期记忆最难的从来不是存下来，而是写什么、何时改、何时删。页面提到 episodes、facts、relationships、patterns、goals、failures、hypotheses 这些层，但正文没披露三个关键机制：第一，fact synthesis 怎么做，靠规则、模型抽取，还是异步批处理；第二，冲突检测怎么打分，confidence 如何衰减；第三，召回时怎么防止旧偏好压过新指令。没有这三块，所谓“连续人格”和“长期目标追踪”很容易变成稳定地记错。 我还会盯多租户隔离。页面说 `/users`、`/projects`、`/self` 分开，这个方向对。可层级 namespace 只解决“放哪儿”，不自动解决“谁能读”“哪些记忆能跨 agent 共享”。一旦一个团队里有研究 agent、编码 agent、销售 agent 同时跑，`/self` 和记忆继承就会变复杂。ChatGPT Memory 和 Claude 现有记忆体验看起来顺，靠的也不只是向量库；里面有很重的产品约束、权限边界、写入节制。Stash 把底座开了，但上面那层 policy 还没看到。 还有评测。页面没有给 retention、precision、冲突修正率、错误写入率，也没给 token 节省的复现实验。只用“少重复解释”做演示，我说实话不太够。记忆系统一旦写错，伤害常常比忘记更大。去年很多 agent demo 都卡在这：第一周像魔法，第二周开始积累脏状态，第三周只能全量清库重来。Stash 如果想从“好看的开源项目”走到“生产可用组件”，迟早得把 memory eval 单列出来，至少给出写入策略、回收策略和人工审计面板。 我自己反而喜欢它最朴素的部分：Postgres + pgvector。这个选型不性感，但靠谱。很多团队最后都会回到 SQL 可审计、可备份、可迁移这件事，而不是再堆一个黑盒记忆服务。要是你现在就在做 agent，Stash 值得试，因为它把长期状态从 prompt hack 拉回了基础设施层。要是你把它当“开源版 ChatGPT Memory”，那多半会失望。标题给了宏大叙事，正文给出的其实是一套还不错的记忆底座，离“会成长的第二大脑”还差一整套评测、治理和遗忘机制。