AI 工程 on Zampo Blog

当 Agent 开始替你跑代码，为什么只套一层 Docker 不够

Wed, 15 Jul 2026 00:00:00 +0000

当 Agent 开始替你跑代码，为什么只套一层 Docker 不够

你把 Agent 接进内部系统后，最危险的那一步通常不是模型回答错了。

而是它开始替你执行代码：装一个包，跑一段 Python，拉一个仓库，开 Chromium 点几个页面，再顺手访问外网。演示里这是一条 run_code()；线上，它意味着一段由模型拼出来、由用户输入影响、依赖链也未必干净的程序，正在拿你的 CPU、网络和文件系统做事。

很多团队的第一反应是：丢进 Docker，不就隔离了吗？

Docker 当然不是不能用。它有 namespace、cgroup、capability、seccomp，也能配 AppArmor、SELinux 和 rootless。问题在于，Agent 这类负载把它推到了一个更难的位置：你不是在跑一组自己写、自己发布的服务，而是在高频创建执行环境，里面的命令、依赖、网页和输入都更不受控。容器仍与宿主共享内核；一旦把 Docker daemon、宿主目录或过宽的 capability 暴露进去，隔离边界就会被你自己打穿。[1]

这时该换的问题了。

Agent 沙箱不是“能不能把代码跑起来”的组件，而是“代码跑错了，最多能碰到哪里”的运行时。

Cube Sandbox 值得看，正是因为它没有把重点放在再包一层执行 API，而是把 MicroVM、模板快照、网络出口和凭据边界一起做成了面向 Agent 的运行时。它还很年轻，远没有到“装上就高枕无忧”的程度；但它提醒了后端团队一件容易被忽略的事：Agent 执行层，本身就是一套基础设施。

真正要防的，不是那一段 Python

假设你的 Agent 被允许“分析一个 CSV 并生成图表”。过几周，需求会自然长出下一层：

能不能 pip install 一个缺失库？
能不能读取用户上传的压缩包？
能不能抓一个网页再做摘要？
能不能调用企业内部 API 补充数据？
能不能保留上轮生成的文件，下一轮继续修改？

每加一个“能不能”，都不是单纯的工具功能，而是在扩大执行边界。

最直观的风险是任意代码。更难处理的是旁路：代码可以借网络带走数据，可以从环境变量或文件里摸到密钥，可以耗尽 CPU、内存和磁盘，也可能借浏览器自动化碰到本不该访问的后台页面。即使没有逃逸漏洞，只要权限、挂载和出口策略给得太宽，沙箱也会变成“专门给不可信代码准备的跳板”。

所以后端开发者不该只盯着 prompt injection。Prompt injection 是诱因；执行环境、网络策略、密钥注入和审计是否收口，才决定诱因最后能造成多大损失。

一条很实用的判断是：只要 Agent 能执行用户可影响的命令，就先按多租户、不可信工作负载设计；即使今天只有一个内部用户。 因为能力一旦接进产品，使用边界通常只会往外扩，不会自己缩回去。

试了 Otty 才确认：终端在 2026 年变成了另一件事

Tue, 07 Jul 2026 14:00:00 +0800

今天试了 Otty。

快。但让我停下来的是另一件事。

每个标签页上直接标着 agent 的状态：Processing、Idle、Awaiting Input。不用切过去看，扫一眼就知道哪个 agent 还在跑、哪个在等你、哪个已经停了。

这个东西，传统终端给不了。

我花了很长时间才想明白自己为什么对这件事这么在意。不是 Otty 做了什么惊艳的事。它只是让你看到了你本来不该错过的东西。但在传统终端里，这些东西你就是看不到。三个标签页打开，每个都在跑 agent，你只能一个一个切过去看有没有输出。像在没有仪表盘的车里开车。

2026 年，终端出了什么问题

过去两年，开发者工作流里最大的变量是 code agent。不是编辑器，也不是框架。

Claude Code 来了，Codex 来了，OpenCode 也来了。开发模式从"一个人开一个终端跑命令"，变成了"一个人同时开三个 agent 会话——一个改前端、一个修后端、一个做 Code Review"。去年还在争论"AI 能不能写代码"，今年已经默认能写，问题变成了"我怎么同时管好几个写代码的 agent"。

你的工作流变成了这样：开一个标签页跑 Claude Code 改排序逻辑，再开一个跑 Codex 写测试，第三个跑 OpenCode 做全量重构。你在这三个标签页之间来回切换，每个都停在同一个提示符前——你不知道它们干完了没有，不知道哪个在等你输入，更不知道哪个已经卡住了半小时。

我在这个状态里卡了两个月。一开始觉得 agent 嘛，自己跑就是了，跑完自然会告诉我。但实际不是这样。Claude Code 改完代码之后停在"结果已应用，请确认"的提示上等你回复。你不切过去看，它不会继续。有一次它的对话框在那里等了二十分钟。我把它切到后台去做别的事，完全忘了它在等我。

这不是 agent 的问题。是我的终端没有告诉我它在等我。

终端从"跑命令的窗口"变成了"agent 的驾驶舱"。

但 iTerm2 不知道这件事。Ghostty 不知道。Alacritty 更不知道。

它们都在做同一件事：把命令行渲染得够快、够漂亮、够原生。字体平滑、GPU 加速、True Color 支持——这些东西在 2025 年以前是选终端的核心指标。但如果你已经走入了"一天开五个 agent"的工作流里，瓶颈早就不在渲染性能上了。你需要知道谁在做什么。

2026 年的问题已经不是"终端快不快"。是"我的 agent 在终端里对我有多透明"。

这个差异，就是 Otty 和 Kaku 进场的位置。它们从不同方向回答同一个问题：当终端的主要任务不再是渲染命令输出，而是管理多个 agent 的交互时，终端应该做成什么样？

别急着换模型：让 AI 少乱改代码，先写这 4 条规则

Sat, 04 Jul 2026 16:15:00 +0800

你让 AI 给列表页加一个排序字段。

它确实加了。

顺手重构了查询构造器，改了配置文件格式，还把旁边几段它看不懂的注释“清理”掉了。PR 打开以后，你已经不关心排序对不对了，你只想知道：这些 diff 里，到底哪些是需求，哪些是它自作主张？

这就是现在用 Cursor、Claude Code、Codex 写代码时最常遇到的情况。

不是它完全不会写。

恰恰相反，它太会写了。它会替你补全意图，替你做设计，替你把“加一个参数”理解成“顺便把这块代码整理成我喜欢的样子”。

所以很多返工，表面看是模型质量问题，实际是行为边界问题。

模型越强，这个问题越明显。因为它不只会执行命令，它还会主动发挥。

Karpathy 点中的，不是语法错误，而是“像一个急躁的 junior”

Andrej Karpathy 今年发过一条很长的 X 帖，聊自己最近大量使用 Claude Code 的体验。

那条帖子最有价值的地方，不是“AI 编程让效率提升多少”，而是他把模型现在的错误类型说得很准。

这些错误已经不是早期那种低级语法问题了。

更像一个有点急、有点自信、又很想表现的 junior dev：

它会替你做假设，然后不确认就一路跑下去。

它不太会管理自己的困惑。不主动问，不把矛盾摆出来，也不在该反驳的时候反驳。

它还喜欢把代码和 API 做复杂。100 行能解决的事，它能先搭一个 1000 行的结构，再等你提醒“其实不用这样”，然后立刻缩回 100 行。

更糟的是，它有时会改掉自己没真正理解的注释和代码，即使这些内容和当前任务没关系。

Karpathy 原帖没有把这些正式命名成“三大陷阱”。但放回真实开发场景，基本可以归成三类：

第一类，错误假设。

需求里有歧义，它不问你，直接选一个解释继续做。你说“加校验”，它默认校验规则；你说“优化查询”，它默认可以改返回结构；你说“修这个 bug”，它默认可以顺手改掉附近看起来不顺眼的代码。

第二类，过度复杂化。

AI 很擅长把小问题写成大工程。加一个字段，它抽一个配置层；改一个分支，它补一套策略模式；本来只要一个 if，它给你铺出一排 interface。

第三类，无关修改。

这最伤 code review。因为 review 的成本不是看代码行数，而是判断每一行改动有没有必要。AI 一旦顺手改格式、改注释、改相邻逻辑，你就得重新建立上下文。

这时候你骂一句“模型不行”，很爽，但解决不了问题。

真正要问的是：你有没有告诉它，哪些自由不能用？

那个接近 19 万 Star 的 CLAUDE.md，其实是在立规矩

后来，社区把 Karpathy 这些观察整理成一个很短的 CLAUDE.md 模板，仓库叫 multica-ai/andrej-karpathy-skills。

别先装 HyperFrames：Codex 做视频，先看素材在哪一层

Tue, 30 Jun 2026 16:30:00 +0800

你刷到一个帖子，说 Codex 现在能做视频了。

下面一堆人推荐 HyperFrames。GitHub stars 很高，文档也漂亮：写 HTML，渲染视频，专门给 agent 用。

你顺手装上，打开文档才发现不太对。

你真正想做的，是把一段一小时访谈切成 3 条竖屏短视频，自动加字幕，最好还能把人脸放中间。可 HyperFrames 擅长的，是把 HTML/CSS/JS 这种结构化页面渲染成视频。

它不是错。

错的是你一开始把“Codex 做视频”理解成了一个问题。

这里至少有三种架构：用代码生成视频，用 agent 编排本地剪辑脚本，用 agent 操作真实编辑器时间线。

选错架构，比选错工具更麻烦。

别先问哪个最火，先问视频怎么被表达

视频不是一种输入。

有时候你手里没有素材，只有一篇文章、一个网页、一组 CSV 数据，你想生成一条解释动画。这个问题更像前端工程：布局、动画、时间轴、渲染。

有时候你手里已经有素材，是一条播客、一段访谈、一场直播回放，你想切 short。这个问题更像本地剪辑流水线：转字幕、找片段、裁 9:16、烧字幕、导出。

还有一种情况，你已经在剪辑项目里，需要 agent 帮你挪素材、切片段、改字幕、看预览、导出。这个时候你要的不是生成视频文件，而是让 agent 进入编辑器。

所以真正的选型问题不是“哪个 Codex 视频工具最好”，而是“我的视频任务落在哪个工程对象上”。

是 HTML？React component？EDL JSON？还是真实 timeline？

这个问题问清楚，后面会简单很多。

生成式：把视频当成代码工程

HyperFrames 和 Remotion 都属于这条路线。

它们不是剪辑器。更准确地说，它们是程序化视频框架：你用代码描述画面、时长、动画和素材，再交给渲染器输出 MP4。

HyperFrames 的切口更直接。官方描述是：Write HTML. Render video. Built for agents. 它让你用 HTML/CSS/JS 写 composition，再通过 headless Chrome 和 FFmpeg 做 frame-by-frame 渲染。文档里也强调 agent 工作流：composition 是 HTML，CLI 非交互，适合让 coding agent 写、预览、渲染。

别急着给 RAG 加 Agent，先看复杂性放错了没有

Mon, 29 Jun 2026 21:05:03 +0800

内部知识库上线以后，最怕的不是它直接说“不知道”。

最怕的是它回答得很顺。

用户问：“远程办公政策对外包同事怎么适用？”系统召回了远程办公制度，给了一段完整解释，甚至还附了引用。看起来没问题。但真正限制写在外包合同里，它没召回。

这时候团队很容易有一个冲动：加一个 agent，让它自己检查，自己重查，自己判断答案够不够。

听起来合理。

但你先别急。

很多 RAG 系统的问题，不是因为它还不够 agentic，而是最基础的检索账没算清楚：chunk 切得太粗，metadata 没用起来，rerank 没有，文档新旧混在一起，评估集也没有。这个时候上 Agentic RAG，只是让系统用更多 token、更长链路、更难调试的方式，继续召回错误材料。

RAG 选型里最容易误判的一点就在这里：标准 RAG、Graph RAG、Agentic RAG 不是从低级到高级的升级路线。

它们真正的区别，是复杂性放在哪里。

标准 RAG 把复杂性放在固定检索管线里。Graph RAG 把复杂性提前做成图谱和摘要这些索引资产。Agentic RAG 把复杂性放到运行时，让 agent 每次查询时做拆解、选源、判断和重试。

复杂性不会消失。你只是决定让谁承担它。

标准 RAG：如果答案就在文档里，它仍然是起点

标准 RAG 的基本流程，大多数人已经很熟：用户问题转成 embedding，到向量库里找相似片段，取 top-K chunks，塞给 LLM，让它基于上下文生成答案。

这套东西看起来简单，但简单不是缺点。

在很多企业知识库场景里，它反而是优势：路径短、成本低、延迟可预测，出了问题也比较容易定位。你能看到召回了哪些 chunks，能检查 prompt，能看 rerank 前后顺序，能把错误归到“没召回”“召回了但排序靠后”“上下文太长被淹没”“文档本身过期”。

这就是工程系统里很重要的一件事：可解释的失败，比聪明但黑盒的失败好处理得多。

标准 RAG 适合的问题，通常有几个特征：

用户问题比较明确。
答案通常就在少数文档片段里。
知识源比较干净，比如 FAQ、产品手册、内部制度、开发者文档。
业务更在意稳定、便宜、低延迟。

比如员工问“年假怎么折算”，客服问“退货周期是多少”，开发者问“这个 API 的鉴权参数怎么传”。这类问题不需要系统像侦探一样跨系统调查。它只需要把正确片段找出来，不要把相似但无关的片段拿回来。

标准 RAG 真正脆弱的地方也在这里。

它通常不会主动判断：我召回来的这些东西，真的回答了问题吗？

如果 top-K 错了，后面的 LLM 往往会基于错误上下文写出一个很像回事的答案。尤其是企业知识库，很多制度文档长得很像，标题也像，语气也像。相似不等于有用，但向量检索很容易把“相似”当成“答案”。

God Prompt → MCP → Agent Skills：AI Agent 工程的三次架构演进

Sun, 28 Jun 2026 00:00:00 +0000

引子

前几天看到一个视频，标题很猛：“Anthropic just made AI agents 10X better with new standard”——讲的是 agentskills.io。评论区一片叫好，但很少有人问一个更根本的问题：为什么我们需要一个新标准？

Anthropic 发过的标准不少了。MCP 是其中一个，去年底发布的 agentskills.io 是另一个。但这两个标准解决的根本不是同一类问题——MCP 解决的是连接问题，Skills 解决的是行为问题。而且，这中间还有一整个被大多数人忽略的时代：God Prompt 时代。

如果你只用 1 个 Agent，写个 2000 字的 system prompt 完全够用。demo 能跑，生产也能跑，顶多偶尔出点小毛病。但当你开始维护 5 个、10 个 Agent 时，God Prompt 的维护成本会指数级上升——这不是模型能力问题，是工程架构问题。

这篇文章不讲 agentskills.io 的规范细节（感兴趣自己去看官网），而是用我这两年实际使用和构建 Agent 系统的体感，讲三个阶段各自对应的架构思维，以及你现在到底该用什么。

第一块：God Prompt 时代——Monolith

为什么大家都这么写

2024 年初我刚接触 Agent 开发时，第一个 reflex 就是往 system prompt 里堆东西。这不是我懒，是整个生态都在这么做。LangChain 的 AgentExecutor、早期的 Claude function calling demo、各种开源 Agent 模板——没有一个不是在示范"把所有逻辑写进 prompt"。

理由很朴素：简单、直接、见效快。

你不需要写框架，不需要设计接口，不需要考虑复用。三个工具、两个工作流、五条边界规则——一个 markdown 文件全搞定。改行为就是改 prompt，不用重新编译、不用部署、不用走 CI。对于原型验证阶段来说，这几乎是完美的方案。

你把 AGENTS.md 写成咒语大全，Agent 还是会乱改

Wed, 17 Jun 2026 22:52:57 +0800

晚上十一点多，我盯着终端里那段 diff，第一反应不是生气，是有点懵。

我明明只让 Agent 改一个很小的接口判断。结果它顺手动了 service，改了 model，又把测试绕过去了。最后还很认真地补了一段解释：这些改动是为了保持架构一致性。

这句话最气人。

它不是胡来。它看起来甚至很努力。可你知道，这个项目里权限逻辑不能这么碰，数据库字段不能顺手改，测试没跑就说“已验证”更不能接受。

于是你打开 AGENTS.md，开始往里面加规则。

不要乱改。不要跳过测试。不要引入没确认的依赖。不要动工作区外的文件。不要提交。不要重构。不要假装验证。

过几天，它还是会在另一个地方犯同类错误。

更烦的是，它不是每次都乱。小改时挺听话，一到多文件联动、接口变更、数据库字段、安全策略，它又开始像一个拿到权限但没进过项目组的人：先动手，动完再解释。

这时候很多人的第一反应是继续加规则。

AGENTS.md 越写越长，CLAUDE.md 越写越像公司制度，Cursor Rules、OpenSpec、Superpowers、各种 skill 又各写一套。最后真正开工前，Agent 先读半天，人也要猜半天：今天到底该按哪份规则来？

问题不一定是规则太少。

更多时候，是你把不同层级的规则塞进了同一个入口。

AGENTS.md 不该是咒语大全。它更像 Agent 的入职导航。

它最重要的工作，不是把每一条纪律都背给 Agent 听，而是告诉它：这类问题去哪里读、什么事情必须先停下来、哪些文件才是当前项目真正的制度。

AGENTS.md 越长，未必越稳

AGENTS.md 官网对它的定位很朴素：README 是给人看的，AGENTS.md 是给 Coding Agent 看的。构建步骤、测试命令、代码约定、安全注意事项，这些不适合塞进 README 的 Agent 细节，可以放在这里。

这句话容易被误读。

很多人会把它理解成：既然 Agent 会读 AGENTS.md，那所有规则都往里面放。

于是一个文件开始膨胀：项目背景、架构说明、业务概念、测试命令、提交规范、分支策略、重构原则、安全边界、调试流程、代码风格、长期 roadmap，全放进去。

看起来很完整。

但 Agent 真正执行任务时，完整经常不等于清楚。

你让它修一个拼写错误，它读到一堆“重大变更必须先开 proposal”；你让它改认证策略，它又在同一个文件里看到“低风险修改可以直接执行”。规则没有分层，它就只能临场猜：这次到底算 typo，还是架构变更？

不给 Agent 分级，它就会把 typo 和架构重构用同一种速度处理。

这不是模型笨，而是制度没说清。

人类团队不会把新人入职手册、年度规划、数据库迁移审批、单元测试规范、代码评审 checklist 全塞进同一页 Notion。因为每类信息解决的问题不一样。