2026-11-09 在本机实测：同一条 55 字节的 Agent 执行轨迹，每写一条强制落盘一次，

32.6 MB 对 16.3 MB。同一张表、同样的 20 万行、同样的正文字段，唯一改动是把换成 ，值改成 36 字符的 UUIDv4。文件翻了一倍，索引从 0.0 MB 变成 9.6 MB，每行摊到的字节从 85 B 变成 171 B。这不是估的：四个变体的脚本与原始输出都在下面的围栏里，可照着重跑。RAG 的文档元数据表、Agent 的会话与轨迹表，很多实现第一次建表就写着 ，理由是「以后要

客户端不是「没收到结果」。它收到了——只是第一行不是 JSON，于是它在读到第一行的那一刻，就把这条连接判死了。你自己跑一遍就能看到这个场面：服务端返回的那段响应，字节确实写在管道里，位置就在第二行，一个字符都不缺；客户端那边给出的却只有一句「解析失败」。两边都没有说谎，它们只是对「这一行是什么」的理解不在同一个层面上。如果你在本地把本文第二章的脚本跑一遍，会看到三种模式下 stdout 分别是

55.7 MB 和 1.55 MB 之间差的不是 36 倍内存，是 36 倍的统计口径。场景很常见：Agent 里缓存工具调用记录，一条三个字段——、、。20 万条塞进一个列表，进程 RSS 从 120 MB 涨到 176 MB，而报 1.55 MB。于是转头去查依赖、查连接池、查日志缓冲，查了一圈，涨上去的那 55 MB 找不到主人。原因不复杂： 只报列表这一层。列表里装的是指针，指针指向的 d

137 不是崩溃，是 SIGKILL 留下的签名。，9 是 SIGKILL。，15 是 SIGTERM。，2 是 SIGINT。三个数字是同一类事件的三个版本：进程没走完自己的收尾逻辑，被外部信号截断了。你在 Agent 的沙箱里跑一条命令，拿到 137 转头去翻业务代码找空指针，方向从一开始就错了——业务代码里没有任何一行会导致 137。137 和 143 同属「被信号终止」，差别是信号编号不同

30 万行 Agent 网关日志、6 个字段，四个低基数字段加起来只有 800 种组合，真正把存储撑起来的是。

跨境电商岗每天打交道的数字，几乎都是「有唯一正确答案」的那种：一笔订单要收多少、一个包裹按几公斤计费、这批货到目的国要缴多少税。这些数字手算错了，客户会来对账；如果是模型算错了，客户一样会来对账，只是错得更隐蔽、更难解释。大模型（指能理解自然语言、并生成文本的大规模语言模型）最擅长的是「猜」：猜你想问什么、猜这句话属于哪个类目、猜怎么措辞更清楚。它不擅长的是「算」。这里的「不擅长」不是指它偶尔会算

如果你做过一段时间的舆情监测，其实早就已经在做代价判断了：一条只是语气冲的普通用户抱怨，和一条正在被大量转发、已经有媒体跟进苗头的负面，你不会用同一个标准去处理。前者顶多算噪音，后者晚发现两个小时，后面要投入的力气完全不是一个量级。把这种判断搬到模型上，它就变成了两个不同的错误。漏报，指的是真的负面存在，系统却没能报出来；误报，指的是本来没事，系统却把它当成负面报了出来。在舆情这个场景里，这两种错

如果只能装一个，就Cursor；如果正在学技术、理方案，就ChatGPT；如果喜欢终端、常做大型项目重构，就如果开始尝试多Agent、复杂工程自动化，你就Codex。但效率最高的方式，从来不是在它们之间做单选题，作为一个成熟的程序员，而是要让ChatGPT帮你想，让Cursor陪你写，让Claude Code和Codex帮你干。未来前端程序员的竞争力，可能已经不只是"代码写得有多快多好"，而是你能

Agent 看起来越来越像小型操作系统，并不是因为谁一开始就规划了操作系统。每一层都是模型撞上边界以后，工程系统不得不补上的回答。记不住，就装配上下文；碰不到世界，就接入工具；一步做不完，就启动循环；历史装不下，就分出长期记忆；副作用变强，就长出会话、权限、沙箱、事件和子 Agent。模型还会继续变强，但 Harness 不会因此消失。未来的分水岭，未必只是谁的模型更聪明，而是谁能为同一个模型搭出