当大家都在聊“AI 能帮你写代码”时，真正的从业者已经在偷偷解决另一个问题了。
Sebastian Raschka 最近写了篇长文，把 coding agent（编程代理）拆了个底朝天。六个核心组件，层层扒开。结果发现一个扎心的真相：
写代码这件事，反而是最简单的。
你以为它在写代码，其实它在“记笔记”
先说清楚，coding agent 到底干嘛的。
就是你丢一句“帮我修一下这个 bug”，它自己跑去翻代码、读文件、执行命令、改代码、跑测试——全程不用你动手。听起来就像个高级点的自动化脚本对吧？
但 Raschka 告诉你，这东西比想象中复杂得多。
他把一个编程代理拆成了六个组件：
- Live Repo Context —— 知道自己在哪个仓库、哪个分支、项目结构长啥样
- Prompt Shape And Cache —— 聪明地缓存重复信息，别每次都重新喂给模型
- Structured Tools —— 给模型一套“工具箱”，读写文件、执行命令、搜索代码
- Context Reduction —— 控制上下文别爆炸，模型可吃不下无限多的 token
- Memory And Resumption —— 记住之前聊过啥、做过啥
- Delegation —— 把大任务拆给子代理去干
前三个，看起来都是“基建”。知道自己在哪、知道怎么调用工具、知道怎么组织 prompt——这些确实重要，但行业内已经做得七七八八了。
真正拉开差距的，是后三个。
记忆才是最大的坑
评论区有个从业者说得特别直接：
“memory and delegation are exactly where things break in prod. tracked 70+ agents over 18 months - memory inconsistency caused most unexpected behaviors.”
翻译过来就是：他们跑了 70+ 个代理跟踪了 18 个月，发现大多数幺蛾子都是记忆出问题。
这就很微妙了。
你想，普通的 ChatGPT 对话，你关掉窗口，下次打开，它就忘了之前聊过啥。无所谓，反正是闲聊。
但编程代理不一样。
你让它改了一个文件，它下次还得知道：
- 改的是哪个文件
- 为什么改
- 改完之后有没有破坏其他东西
- 当前任务进展到哪了
Raschka 把记忆拆成两层：全量转录（Transcript） + 工作记忆（Working Memory）。
全量转录像录像带，完整记录每一次交互。工作记忆像便利贴，只记当前最关键的那几条。
最近的事件要记得详细，久的就压缩。
听起来很合理对吧？但问题来了：什么叫“重要”？
模型怎么判断哪些细节该保留、哪些该扔？这事目前没有标准答案。
还有个更头疼的：跨会话记忆。
你今天让 agent 修了个 bug，明天来了还想起来吗？大多数 agent 做不到。Raschka 提到的方案是把记忆存成 JSON 文件，但说实话，这只是“能记住”，离“记得聪明”还差得远。
delegation：让 AI 分身有多难？
再说 delegation（委托）。
一个代理同时做好几件事忙不过来怎么办？好办，拆成多个子任务，交给子代理去干。
但这里有个设计难题：
子代理继承太多上下文吧，重复计算、浪费资源；继承太少吧，它根本干不了活。
Raschka 举了个例子：主代理正在写一个功能，突然想知道某个符号在哪定义、配置文件里说了什么、为什么某个测试挂了。这些时候，甩给子代理是最优解。
但怎么甩、甩多少、甩完之后怎么把结果塞回来——全是坑。
Claude Code 和 Codex 都在做这件事，但实现思路完全不同。Claude Code 倾向于把子代理设为只读模式，Codex 则更宽松，继承主代理的沙盒和审批流程。
哪种更好？没有定论。
评论里有人总结了：
“Agents are good at isolated tasks but terrible at deciding what to work on next and when to stop.”
这才是大实话。单个任务它能搞定，但什么时候该自己干、什么时候该甩给别人——这套判断逻辑，目前没有哪个 agent 敢说自己完全解决了。
所以到底难在哪？
Raschka 这篇文章有意思的地方在于，他把一个看似“工程化”的问题，写出了层次感。
六个组件，看起来是并列的。但仔细看，前三个是“启动时的配置”，后三个是“运行时的动态决策”。
- Repo context、prompt cache、tools——这些是静态的，装载一次就能用
- Context reduction、memory、delegation——这些每时每刻都在变，需要实时处理
这就导致一个结果：
组件 1-3 决定了 agent 有没有能力干活，组件 4-6 决定了它能不能干得靠谱。
而目前行业的情况是：1-3 已经相对成熟，4-6 还在摸索。
这也是为什么评论区一堆人共鸣：
“Memory and delegation are the pieces most teams underestimate.”
“The memory piece is what separates toy demos from agents you can actually trust in production.”
说白了，很多 demo 看起来很炫，但一到生产环境就拉胯——因为记忆和委托没做好。
尾声
Raschka 最后提了一嘴他的新书《Build A Reasoning Model》，说是花了 1.5 年写的，关于推理模型的评估、推理时间缩放、自反思、蒸馏、强化学习。
有意思的是，他做书的方法论，其实就是这篇文章的思路：
把一个看似简单的东西，拆到足够细，才能看到真正的难点在哪。
现在行业都在追“模型能力”，但 Raschka 用这篇文章提醒了一个被忽视的事实：
模型再强，配套的工程基础设施没跟上，一样白搭。
【锐评】：Memory 和 delegation 这两个词看起来不性感，但它们才是区分“玩具”和“生产力工具”的分水岭。
参考链接：
https://x.com/rasbt/status/2040423398824698310