过去一年，很多人对 AI 编程的体感发生了变化。早期的“vibe coding”更像一种新鲜玩法：给模型一句话，看它能不能写点东西出来。好玩，但不稳定，也很难放进真实交付链路里。
现在情况有点不一样了。模型能力提升只是其中一部分，更关键的是工作流开始成型：计划文件、并行 agent、语音输入、长期记忆、工具权限、远程控制、可复用 Skills。这些东西拼在一起，才把“让 AI 写代码”推进到了“让智能体参与工程交付”。
这篇原文《Every Agentic Engineering Hack I Know》有点像一个重度用户的工具箱清单。里面有不少很激进的做法，比如跳过权限确认、终端默认进入 Claude Code、开六个 agent 并行干活。照抄未必适合大多数团队，但它透露出的工程信号很重要：智能体工程的核心，已经从模型问答转向工作流设计。
一、从玩具到工程系统
“vibe coding”这个词挺准确。它描述的是一种很松散的交互方式：人给一个大概方向，模型凭感觉生成代码，人再凭感觉修修补补。
这种模式在 demo 阶段很爽，但一进入真实项目就会暴露问题：
- 上下文容易断；
- 生成结果不可追踪；
- 模型容易偷懒；
- 多轮修改后方向漂移；
- 人很难判断它到底完成了什么；
- 切换会话后工作状态丢失。
所以，智能体工程真正要解决的，不是“模型会不会写代码”，而是“模型能不能被纳入一个可持续交付的系统”。
原文里反复出现的 plan.md，本质上就是这个系统里的状态载体。
它不是传统意义上的需求文档，也不是给人看的详细设计。更准确地说，它是智能体工作流里的中间表示层：把一个模糊想法转换成可执行计划，把上下文、约束、验收标准、代码库模式和任务拆解都固化下来。
这一步很朴素，但非常关键。
过去我们和 LLM 对话时，状态主要存在聊天窗口里。窗口一长，模型就开始遗忘；会话一断，状态就没了。plan.md 把状态从“对话流”里抽出来，变成一个可以被新会话、不同 agent、甚至不同工具继续消费的工程产物。
这也是为什么原作者会说：上下文爆了？开一个新会话，指向这个计划，从中断的地方继续。
这个判断很工程化。因为真正麻烦的不是一次生成代码，而是任务跨时间、跨窗口、跨工具还能保持一致性。
二、plan.md 是智能体的接口协议
原文里最重要的一条原则是：一有想法，立刻创建一个 CE plan.md。
这里的 CE 指 Compound Engineering。/ce-plan、/ce-work、/ce-brainstorm 都是它提供的斜杠命令，不是 shell 命令，也不是 Codex 内置能力。
从描述看，/ce-plan 做的事情大概包括：
- 读取当前代码库；
- 识别已有代码模式；
- 搜索历史解决方案；
- 必要时调研外部文档；
- 并行运行多个研究 agent；
- 汇总为结构化计划；
- 写清问题、方案、文件改动和验收标准。
这套机制背后有一个很重要的思想：先把智能体的自由度收窄，再让它执行。
很多人使用 LLM 写代码时，最大的问题是直接让它开干。模型会为了尽快给出答案而压缩思考过程，尤其在任务较复杂时，它常常会跳过调研、跳过约束分析、跳过测试设计，直接写一版“看起来差不多”的代码。
plan.md 的作用就是逼它先承诺。
承诺什么？
- 承诺它理解的问题是什么；
- 承诺它准备走哪条路径；
- 承诺它会修改哪些文件；
- 承诺完成标准是什么；
- 承诺哪些行为不应该做。
这个承诺未必总是正确，但它给了人和后续 agent 一个检查点。
用架构视角看，plan.md 很像智能体系统里的任务协议：
这个链路里，真正稳定的是 plan.md，不是某个会话，也不是某个模型。
很多团队以后做智能体平台，大概率也会遇到类似问题：agent 之间不能只靠自然语言聊天传递状态，必须有某种结构化、可审阅、可恢复的任务表示。可以是 markdown，可以是 JSON，可以是 issue，可以是内部工单。但一定要有。
三、不读计划反而合理
原文里有个看起来反直觉的观点：你自己不用读 plan.md。
这句话容易被误解成“人类不需要理解方案”。其实更准确的理解是：计划的主要读者从人变成了 agent，人只需要在关键点介入。
这和传统开发流程很不一样。
过去，文档主要是给人看的。写给架构师看，写给评审会看，写给后续接手的人看。所以文档要求简洁、准确、可读。
智能体工作流里的计划文件，很多时候是给模型看的。它可以很长，可以包含大量上下文，可以塞进代码模式、历史讨论、验收清单、边界条件。这些内容对人来说可能过载，但对 agent 来说刚好是执行燃料。
人的角色变成了抽样审查：
- 看标题和结构是否跑偏；
- 问一句“为什么用这个方案”；
- 要一段 TLDR；
- 对风险点做判断；
- 对产出做验收。
这不是偷懒，而是分工变化。
当然，这里面有明显的边界。个人项目、内部工具、小范围实验，计划可以主要给 agent 消费。但如果是生产系统、合规系统、核心链路改造，计划不能只交给 agent 自娱自乐。至少关键决策、数据迁移、权限变更、架构边界要有人审。
这就是第一个现实 trade-off：
| 做法 | 收益 | 风险 | 适用场景 |
|---|---|---|---|
| 人完整阅读计划 | 可控性强，便于评审 | 慢，容易打断节奏 | 核心系统、多人协作、风险变更 |
| 人只抽样审查 | 吞吐量高，适合并行 | 容易漏掉隐含风险 | 个人工具、非核心模块、探索任务 |
| 完全信任 agent | 速度最快 | 失控概率高 | 一次性脚本、低风险实验 |
原作者选择了非常激进的一端。他的上下文是个人高强度交付和开源贡献，不是大型企业里的受控变更流程。这个前提不能忽略。
四、并行工作流才是生产力来源
单个 agent 再强，也只是一个助手。多个 agent 并行起来，工作模式才会变化。
原文里提到的 cmux 多标签页，就是一个典型形态：
- 一个窗口跑
/ce-plan做研究； - 一个窗口跑
/ce-work执行已有计划； - 第三个窗口处理新 bug；
- 第四个窗口让 Codex 构建；
- 人在多个结果之间切换，做判断和反馈。
这和传统 IDE 里一个人线性写代码完全不同。更接近一个小型工程团队的调度台。
原文里“人类信号”这个说法很值得注意。
当 agent 数量变多以后，人不再是主要执行者，而是反馈系统：
- 这个方向不对；
- 第二个方案更接近；
- 先处理最大风险；
- 这段太长；
- 这个实现不符合项目风格；
- 验收标准缺了异常路径。
很多技术负责人其实对这个角色很熟悉。带团队时，你不可能亲手写每一行代码，更多是在判断方向、拆任务、看风险、做取舍。现在只是把一部分被管理对象换成了 agent。
但这里也有现实限制。
并行 agent 对人的上下文切换能力要求很高。六个会话同时跑，听起来很爽，但也很容易把人拖进一种“永远在处理反馈”的状态。吞吐量上去了，认知负债也会上去。
所以并行不是越多越好。比较稳妥的做法是按任务风险分层：
- 低风险任务可以多开并行，比如文档、脚本、测试补充；
- 中风险任务限制并行数，比如普通业务功能；
- 高风险任务尽量线性推进，比如数据库迁移、权限系统、支付链路。
智能体提高的是执行带宽，不会自动提高判断带宽。这个约束很硬。
五、语音输入改变了需求表达
原文多次提到语音输入。这个细节容易被低估。
对传统软件来说，语音输入一直比较尴尬。转录一错，后续文本就废了。尤其写代码、写需求、写命令，准确性要求很高。
但对 LLM 来说，语音转录不需要完美。因为模型能根据上下文修正错误，理解停顿、重复、半句话和临时改口。
这会改变需求输入的成本。
以前写一段完整 prompt，需要人在脑子里先组织结构，再打出来。语音则更像“把还没成型的思考倒给模型”，然后让模型帮你整理。
这对智能体工程很重要。因为很多任务的瓶颈不在写代码，而在把脑子里的意图外化出来。
语音输入降低的是意图外化成本。
不过，原作者也提到一个非常真实的限制：开放办公室里很难用语音。你不想打扰别人，也不想显得像在自言自语。这不是技术问题，是工作环境问题。
所以语音工作流适合这些场景：
- 独立办公室；
- 居家办公；
- 车里；
- 走路时记录想法；
- 长文档、产品规格、战略分析。
如果团队长期在开放工位办公，语音输入的实际采用率可能不会高。这类约束很细，但落地时往往就是这些东西卡住。
六、权限跳过是效率和安全的硬交换
原文里最有争议的一部分，是跳过 Claude Code 和 Codex 的权限确认。
比如 Claude Code 的配置：
{
"permissions": {
"allow": [
"WebSearch",
"WebFetch",
"Bash",
"Read",
"Write",
"Edit",
"Glob",
"Grep",
"Task",
"TodoWrite"
],
"deny": [],
"defaultMode": "bypassPermissions"
},
"skipDangerousModePermissionPrompt": true
}
Codex 侧则是：
approval_policy = "never"
sandbox_mode = "danger-full-access"
或者直接：
codex --yolo
这类配置会显著提升并行工作流的效率。否则每个 agent 做一点文件修改、跑一个命令，都要人确认。六个会话一开，人就被确认弹窗绑死了。
但这也是非常明确的风险点。
它可能带来的问题包括：
- 删除或覆盖本地文件；
- 执行危险 shell 命令；
- 泄露本地环境变量；
- 修改不该修改的配置；
- 访问敏感文件；
- 在错误目录里执行操作。
原作者的态度是“这是我的电脑，坏了还有 GitHub”。这个前提只适合个人机器、个人项目、可恢复工作区。
如果放到公司环境，尤其是有生产凭据、本地密钥、客户数据、内部仓库权限的机器上，直接 YOLO 是很危险的。很多安全事故不是模型“有恶意”，而是它在错误上下文里执行了一个看似合理的命令。
更工程化的做法是分层授权：
| 环境 | 权限策略 | 说明 |
|---|---|---|
| 一次性沙箱 | 可跳过确认 | 容器或临时目录，随时销毁 |
| 个人实验项目 | 可半自动 | 保留 Git、备份和最小凭据 |
| 公司开发机 | 谨慎放权 | 限制目录、命令、网络和密钥访问 |
| 生产环境 | 禁止 YOLO | 必须走审批、审计和变更流程 |
真正适合团队的智能体工程，应该把“权限”当成一等公民设计，而不是靠每个人自觉。
可以考虑的方向包括：
- agent 只在 devcontainer 里运行；
- 使用最小权限 token；
- 禁止读取特定路径；
- 对危险命令做拦截；
- 所有 agent 操作写审计日志；
- 生产变更只能生成计划和 PR，不能直接执行。
效率和安全不是口号问题，是成本曲线问题。个人开发追求吞吐量，组织开发必须控制失误半径。
七、Claude 做计划，Codex 做构建
原文里有一个很实用的分工：Claude 做计划和品味判断，Codex 做构建。
这其实反映出智能体工程里的“多模型协作”趋势。
不同模型和工具的优势不完全一样。有的更擅长长上下文规划，有的更擅长代码生成，有的更适合审查，有的工具链集成更顺手。把所有任务压给一个模型，短期省事，长期会限制上限。
一种常见分工可以是：
| 角色 | 适合任务 | 关键能力 |
|---|---|---|
| 规划 agent | 需求澄清、方案拆解、风险识别 | 长上下文、结构化推理 |
| 编码 agent | 实现功能、补测试、重构局部代码 | 代码生成、工具调用 |
| 审查 agent | 找 bug、看安全风险、检查风格 | 批判性分析 |
| 调研 agent | 查文档、社区反馈、竞品信息 | Web 检索、信息整合 |
| 文档 agent | 写规格、README、发布说明 | 表达和归纳 |
这套分工和人类工程团队很像。区别在于 agent 的切换成本更低，可以用文件、PR、计划、issue 串起来。
但要注意，多个模型协作也会带来一致性问题。不同模型对代码风格、架构边界、测试策略的理解可能不同。如果没有稳定的项目约定，它们会各写各的。
所以，智能体并行之前，最好先把这些东西固化下来：
- 代码风格；
- 目录结构；
- 测试策略；
- API 设计约定；
- 错误处理规范；
- 禁止修改的区域；
- PR 验收标准。
这些内容可以放进 AGENTS.md、CLAUDE.md、项目 README，或者团队自己的 agent rules 里。否则并行越多，风格漂移越快。
八、研究先于计划
原文提到一个很有价值的习惯：运行 /ce-plan 之前，先用 /last30days 做最近社区信息调研。
例子是选择 Vercel agent-browser 还是 Playwright。作者没有直接读官方文档，而是让 agent 拉取最近 30 天的 Reddit、X、YouTube、HN 讨论，再把结果喂给 /ce-plan。
这个做法解决的是 LLM 的时效性问题。
很多技术选型不能只看官方文档。尤其是新工具，官方文档通常只告诉你“能做什么”，社区讨论才会告诉你“哪里坑”“谁在用”“最近有没有大改”“生态是否活跃”。
智能体做计划时，如果输入只有代码库和旧知识，它可能会给出一个过时但看起来很完整的方案。加入近期社区信号以后，计划质量会明显不同。
这也说明了一个更通用的原则：计划质量取决于上下文质量。
比较稳的链路是：
对团队来说，这可以进一步产品化：
- 技术调研 agent 自动收集近期资料；
- 方案计划引用资料来源；
- 高风险选型要求列出替代方案；
- PR 描述里附带决策依据；
- 重要计划进入知识库，供后续复用。
这比“某个同学拍脑袋选型”可靠得多。
九、会议转录是未开发的上下文金矿
原文里还有一个很有代表性的场景：把 Granola 的原始会议转录直接丢给 Claude Code，让它生成产品提案。
关键点是“原始转录”，不是先人工总结。
这看起来有点反常。人类通常会嫌原始会议记录太脏，里面有闲聊、打断、重复、跑题。但对 LLM 来说，原始记录里反而保留了很多微妙信号：
- 某个需求被反复提到；
- 某个风险被轻描淡写带过；
- 某个人对某个方向明显更兴奋；
- 真实用词和正式文档里的表述不一样；
- 闲聊里可能藏着业务背景。
如果再结合代码库和过去的战略计划，模型就能把“会议噪音”转成结构化产出。
这类工作流对产品、咨询、售前、技术管理都很有价值。很多组织的知识其实散落在会议里，开完就没了。智能体让这部分信息重新进入生产系统。
但这里同样有合规边界。会议转录可能包含个人隐私、客户信息、商业机密。把原始转录喂给模型之前，需要搞清楚：
- 数据是否允许进入第三方模型；
- 是否需要脱敏；
- 是否有客户授权；
- 存储周期多久；
- 谁可以访问生成结果；
- 是否能被用于训练。
工具好用是一回事，数据治理是另一回事。企业落地时，这两个必须一起设计。
十、Skills 是智能体能力的复利
原文后半段最值得展开的是 Skills。
作者的做法很简单：任何做超过两次的事，都把它变成一个 skill。比如 last30days 起初只是他自己的调研 skill，后来开源成项目；Printing Press 则更像一组 agent-native CLI 的工厂。
这背后的逻辑很像传统工程里的自动化脚本，但更进一步。
过去我们写脚本，是为了自动化确定性任务。输入固定，流程固定，输出固定。
Skills 面向的是半结构化工作流。它不一定每次输入完全一样，但有稳定的处理套路。比如：
- 调研最近社区动态；
- 根据会议生成产品提案；
- 把计划转换成同事可读文档；
- 为某类仓库生成 PR；
- 拉取某个 SaaS 服务的数据；
- 根据固定风格制作发布视频。
当这些能力被沉淀成 skill，每个新会话都不必重新解释一遍。这就是原文说的“上下文复利”。
从工程角度看，Skills 的价值有三层：
- 节省提示词成本不需要每次手动描述流程。
- 稳定输出质量相同任务走相同结构，结果更可预期。
- 形成个人或团队知识资产 工作习惯可以被版本化、共享、迭代。
团队如果要做智能体工程，Skills 很可能比单纯买模型订阅更重要。模型是底座，Skills 才是组织自己的生产函数。
一个比较实用的沉淀标准是：
- 做一次：手动做；
- 做第二次：让 agent 帮你做；
- 做第三次：写成 skill；
- 多人都在做：沉淀成团队工具。
这比一开始就搞宏大的 AI 平台现实得多。
十一、智能体会走出终端
原文最后提到 Printing Press、Agent Cookie、Tesla、Instacart、ESPN、Alaska Airlines 这些东西。这个方向有点激进，但很能说明问题：智能体不只写代码，它开始通过 CLI 操作现实服务。
这里的关键是认证。
一个 agent “知道如何使用某个服务”，和它“已经登录并能代表你行动”，是两回事。Agent Cookie 这类工具试图把真实浏览器会话交给 CLI，让 agent 能以用户身份操作服务。
这会打开很大的想象空间，也会打开很大的安全黑洞。
一旦 agent 能代表你下单、订票、发邮件、改配置、操作云资源，它就不再是代码助手，而是数字代理人。此时最关键的问题变成：
- 它能做哪些事？
- 花钱上限是多少？
- 是否需要二次确认？
- 操作记录在哪里？
- 出错后谁负责？
- 如何撤销？
- 如何防止 prompt injection？
尤其是浏览器和邮箱场景，prompt injection 风险很高。网页内容、邮件正文、附件文本都可能包含恶意指令。如果 agent 同时拥有登录态和执行权限，它可能被外部内容诱导做出危险操作。
所以这类能力如果进入企业环境，必须有清晰的权限沙箱和审批边界。个人用户可以 YOLO，组织不能。
比较合理的产品形态可能是：
- 低风险动作自动执行，比如查询、整理、草拟；
- 中风险动作需要确认，比如发邮件、创建订单；
- 高风险动作只生成建议，比如付款、删除、权限变更；
- 所有动作可审计、可回放。
智能体工程往后发展，安全模型会越来越重要。谁能把“能干活”和“可控”同时做好，谁才可能真正进入生产环境。
十二、别把高强度构建误认为高价值
原文有一段很诚实：agent 本该替我们完成所有工作，结果大家反而以人生中最高强度工作。
这不是玩笑。
智能体把构建成本降下来以后，人很容易陷入一种新的成瘾循环：想到一个东西，马上让 agent 做；做完再想到下一个；发布很多项目，但没人用；继续构建，继续兴奋。
工程师很容易掉进这个坑。因为构建本身有即时反馈，比验证需求舒服得多。
但生产力提升不等于价值提升。智能体只是让“做东西”更便宜，并不会自动证明“这个东西值得做”。
所以，在智能体工程里，人类判断比以前更重要。尤其是这几个问题：
- 是否有人真的需要这个功能？
- 这个问题是否值得自动化？
- 做完之后谁维护？
- 它会不会增加系统复杂度？
- 它解决的是核心矛盾还是边缘爽点？
- 如果不做，会有什么实际损失？
很多团队引入 AI 工具后，短期会看到产出数量上升。但如果没有需求判断和技术治理，很快会变成更多半成品、更多脚本、更多无人维护的内部工具。
这也是技术负责人需要警惕的地方。智能体提高了局部速度，但系统整体效率仍然取决于方向、约束和取舍。
十三、适合照搬的不是工具清单
原文列了很多具体工具：Claude Code、Codex、cmux、Ghostty、Granola、Proof、Monologue、AgentMail、HyperFrames、Printing Press、Agent Cookie。
这些工具会变。半年后可能又换一批。真正值得带走的是几个工作流原则。
1. 先计划，再执行
不要直接让 agent 写复杂功能。先让它调研、拆解、写验收标准，再执行。
2. 把状态放进文件
不要让任务状态只存在聊天窗口里。用 plan.md、issue、PR 描述、任务文档承载状态。
3. 人做判断，agent 做吞吐
不要把自己困在执行细节里。多看方向、风险、边界、验收。
4. 并行要分风险
低风险任务可以多 agent 并行。核心链路别盲目 YOLO。
5. 把重复工作沉淀成 Skills
一次性的 prompt 不是资产。可复用的 skill、CLI、规则文件才是复利。
6. 权限必须设计
个人电脑可以冒险，公司系统必须有沙箱、审计和最小权限。
如果用一句工程化的话概括：智能体工程不是让模型更自由，而是给模型设计更好的轨道。
轨道设计好了，模型能力才会变成交付能力。轨道设计不好，模型越强，破坏半径也越大。
这篇文章真正有价值的地方，也正在这里。它不是在证明某个工具“多神”，而是在展示一个高强度智能体用户如何把想法、计划、执行、反馈、复用和外部服务串成一个系统。
对个人开发者来说，可以从 plan.md 和语音输入开始。对团队来说，更应该先做三件事：任务计划规范、agent 权限边界、可复用 Skills 沉淀。
别急着把所有东西都交给 agent。先让它在一个小而稳定的轨道里跑起来。跑顺了，再扩半径。工程里很多事都是这样，真正能长期工作的方案，通常不是最炫的那个，而是边界最清楚的那个。
