Agent 工程不无聊，难点已经挪到删记忆和别烦人

Harrison Chase 在 X 上写，很多 content engineering 的挑战已有标准解法，于是有人说 agent engineering 已经解决，甚至无聊。他承认这句话部分成立，但 agent 演化会带来新的、好玩的问题。原推和文章在这里：Harrison Chase 的推文，他提到的文章。

评论区把这句补全了，而且比主贴更具体。

子 agent 只拿到 what，父 agent 知道 why

有网友 dimash 说，多数 context engineering 只是在修自己弄坏的东西。父 agent 知道为什么，子 agent 只拿到要做什么，然后自信地解错问题。这个描述很刺。把任务切给子 agent 时，常把推理过程、失败记录、约束条件留在父层。子层看到一段任务描述，缺了上下文，却会用完整语气交付。它没觉得自己错，它只是不知道。

记忆的难题是删，不是存

有网友 ilmAI 说，他的 agent 读一个 markdown wiki，不接记忆插件。agent 擅长加页，很少回头修旧页，但会一直读那些旧页。也有网友 Don Santo 说，agent 怎么保存信息基本解决，怎么知道该扔什么还开放。他补了一句，好职员由什么没进档案定义。这句比很多架构图有用。保存是加法，删是判断。加法有标准件，判断没有。

长任务压缩没有标准答案

有网友 Rohan 说，长 agent run 里决定什么在 compaction 后存活，仍没标准答案，每个团队最后都写自己的规则。普通读者可以把 compaction 理解成长任务中途压缩历史，只留一部分给模型。留什么，丢什么，会直接改变 agent 后面犯的错。

协调和打扰，都是边界

有网友 Moriarty 描述了一个具体场景：一台 Mac 上跑两个 Claude 和两个 Codex 账号，让它们别进同一个文件，要靠共享日志加自愿锁。自愿锁这个词已经说明问题。还有 Nick Woodhead 说，做主动建议时，被忽略的建议应该过期，不要记成用户跳过。否则记忆层会学成用户讨厌他从没看见的东西。Brian Cheong 把问题收成一句：always-on agent 要决定记什么、忽略什么、升级什么。可靠性更多来自这些边界，不来自另一个更聪明的 loop。

Tom Daniel 提到另一个缺口：自动多 agent 团队组建。主流用户不会自己组队，团队要随交互自己形成。这个判断值得放在产品侧看。

Luis Junior 的回复更冷：agent engineering 变成食谱时，赢的是面包店老板，不是工程师。每个新模型会吞掉一批今天的难题。这话成立。标准解会越来越多。但烦人、过期、冲突、该升级给谁，这些定义长在产品里，不在模型参数里。

所以 agent engineering 不无聊。它只是从搭框架，变成管一个会自信犯错的同事。难题没消失，挪到了删记忆、分任务、抢文件和少打扰人这些地方。