> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Agent 写完的代码没人读过：出事时你该潜多深 - URL: https://www.hubwiz.com/blog/agents-do-the-work-ownership-three-pillars/ - Published: 2026-10-30T15:15:03.000Z - Updated: 2026-10-30T15:17:29.000Z - Description: 一份 30 行的文件冒出复杂度告警，而他从没读过那行代码。Agent 时代的所有权，靠基础、广度与"按需下潜"撑起来。 - Author: admin - Tags: AI 编程, 软件工程, Agent, 职业发展, 系统设计 CI 挂了。这不该发生——作者 Adrian Quiroga 已经把 agent 工作流调到自己会惊讶的程度：他的 agent 提交的分支几乎不可能带着失败的测试。是 CI 抖动，还是环境问题？ 结果是 SonarQube 在对 `App.tsx` 报**圈复杂度**。这个检查项他很久没见过了。 那个文件大约 30 行，其中 15 行**每一行就是一个完整组件**——是 Codex 决定这样写的。这本身还好，跑一遍格式化就完了。但那解释不了复杂度告警：那些组件每一个都相当有内容，展示逻辑和业务逻辑都很多。换成以前的自己，会仔细重构成可读的形状；而 Codex 并不在意"整个组件挤在一行里"，更不在意复杂度——它已经在这个文件上愉快而稳定地迭代了好几个功能。 CI 工具报了个问题，可能对也可能错。但这是真实系统，所以他必须下水。格式化之后，他逐个检查组件和逻辑：Codex 在边界情况的覆盖上确实超出了普通开发者的水平，也确实有点过度设计——但都对，复杂度是被业务需求撑起来的。于是他让 Codex 去把 SonarQube 弄满意；Codex 重构、拆成 10 个文件，CI 过了，东西上线。 这次解决得很快。但他补了一句：**你可以想象它本来会糟得多——毕竟这是他从没读过的代码。** 而这正是行业正在走的方向：**拥有一个软件系统，将越来越少取决于你亲手写过它；真正重要的是"刚好够"——够到能判断哪里不对，以及愿意也有能力在需要的时候潜到需要那么深。** ## 一、潜水机器人，与金块 想象你在一条船上（船的类型由你决定），你的工作是从海底捞金块。 直到不久之前，你想要那袋金子，就得自己跳下去、游到底、四处看看、把包装满。在清澈的浅水里这很容易，但你可以想象它会多快变难。随着浅水的矿挖完，你和同行们造出各种机械和工具，去更深、更危险的水域开采。大部分时候这行得通：你和团队仔细装配、维护、轮换这些机器，并不断亲自下潜到海底的作业点维持它运转。你偶尔会听说某处矿难——有时是水压，有时是事故，有时是操作者的无能。 麻烦在于，这是个地质活动极其频繁的世界：海床一直在变，一些矿枯了，新的矿在别处长出来。 好消息是：最近几年出现了越来越精巧的**潜水机器人**（divebots）。你只要告诉它去哪儿建，它就潜下去，只在上来汇报进度、交金块时浮出水面。于是你可以躺在甲板上放松，唯一需要操心的是船能装多少金子。 **这是乐观派阵营。** 直到…… "等你的潜水机器人潜得太深、迷路了你就知道了。""哈哈，你的潜水机器人带回来的东西看着像金子，其实是发亮的章鱼屎。" 随着机器人越来越多，恐怖故事也越来越多：机器人迷路、忘了自己要建什么；机器人建出复杂到它自己都维护不了的怪物，然后被下一代机器人丢弃。所有海底作业从精心设计的大教堂，变成了到处是暗道和潜伏怪物的杂乱豪宅。**你离作业越远，失败就越壮观。** **这是怀疑派阵营。** ## 二、这里是怪物出没的地方 软件工程行业（他怀疑很快还有很多其他行业）正在经历上面这个剧本的某个版本。你可能已经知道自己更像怀疑派还是乐观派，即使还没决定要站哪边。 传统智慧是：要开发和维护一个不平凡的系统，你需要在脑子里有一个像样的工作模型。这点恐怕很少有人反对。而在软件工程里，你通过**直接和代码打交道**获得这个模型。多年、几十年的写和读，给了你理解自己所负责系统所需的知识和工具。每一次生产事故、每一次深夜调试、每一次成功发布，都给你"拥有"一个系统所需的视角。 在这篇文章的语境里，**拥有（ownership）的意思是：东西坏了，被叫起来的人是你。** 而 agent（潜水机器人）把这一切翻了过来。 机器人产出东西的速度远快于任何人吸收的速度。在过去复杂的系统里，你可以假定代码曾经经过某个人的手；**现在这个前提不再成立。** 有经验的从业者可以管理一支机器人舰队，以空前的规模造软件——这些操作者懂手艺，把可观的经验带进架构和管理，做出过去需要一整个团队才能建的系统。 但这暴露了行业最大的挑战：**我们怎么培养下一代工程师？** 在这件事上，乐观派和怀疑派在极端处的答案截然相反： - **一边**（同样有名望的声音）：要维持对这些系统的控制，只能**逐行读机器人写的代码**。你必须能手写出来，必须能解释每一段代码在做什么、在应用上下文里处在什么位置。 - **另一边**（同样有名望的声音）：**别费劲看代码了。** 把精力放在想清楚要建什么，别管怎么建——模型会处理。 他认为这两种都不对。 事实是：今天的高级工程师学东西的方式——手写代码、无止境的调试、生产事故——**对今天的初级工程师不是一条可行路径。** 说清楚点：**不是经济上可行**。公司几乎不可能愿意出钱养一个初级工程师好几年，就为了让他"学会手工做这件事"。那是一厢情愿。 另一种常被拿出来的建议是"确保你理解 agent 写下的每一行""和高级工程师结对""做仔细的代码评审"——同样是一厢情愿，除了少数几个团队以外。他半开玩笑：如果你认为整个行业会采用这些做法，我这有座桥想卖给你。 ## 三、下水之前，先问：你需要的是一张什么地图 要找到一条能让人达到某种熟练度的可行路径，得先看清"拥有一个不平凡的系统"到底意味着什么。 想想你常见的架构师/技术负责人/CTO 是怎么工作的：他们要在脑子里有一个系统的模型，一张**海图**。真正的问题是——**要多细的粒度？** 想象一个一百万行的遗留代码库，多年来被很多人写过、扩过，CTO 可能也写过其中一部分。现在出了生产事故，你是那个倒霉的 SRE，凌晨两点一边排查一边收着不同时区发来的愤怒消息。你需要一张什么样的图？ 你需要**一张高层的、拉远的全系统地图**，加上"刚好够"的知识：知道该往哪里潜、怪物住在哪里；并且能在任何陌生代码库里跳进去、搞清发生了什么、推一个热修、然后在事故报告里把经过讲清楚。 注意，这**不是**对全系统的细节知识。我们管理复杂系统的唯一方式就是不断堆抽象层。每一层让我们能再往上搭一点，但无论你手里是哪张图，都要记住：**一层套一层的抽象，而没有人真的理解所有层。** "I wrote module X and know it inside out"和"I have an appropriate model of the system abstractions and can dive into any module and fix it when it breaks"——这两者之间有巨大的差别。手写代码给你的是前者；而系统的所有者、那个被叫起来的人，需要的是后者。 所以这张图怎么建出来？一个从没亲手捞过金块的人，凭什么能跳进陌生的水域，去修机器人搞出的烂摊子？ ## 四、三根柱子：基础、广度、按需下潜 **第一根：基础（fundamentals）。** 复杂系统里最阴险的失败是**安静的失败**：东西大体还能用，但哪里不对劲。也许突然变慢了，也许错误率上去了，也许大多数时候完美但每第 19 次就失败。还没到凌晨两点把你叫起来的地步，但足够让你觉得不对。 作为系统的所有者，你必须理解这个系统的**失败模式**。作为行业，我们有教人识别和推理这类失败的工具：基础。好消息是，我们几十年来一直在教那些不太情愿的计算机专业学生这些东西——数据结构与算法、网络、并发、分布式系统等等。也不一定非要正规教育，这些主题你自己都能读、都能学。 举个最简单的例子（高级工程师请包涵）：你派潜水机器人下潜 2 米捞金块，它 4 秒回来，一切正常。下一次下潜 4 米，这次花了 16 秒。奇怪。再下一次 16 米，256 秒。你懂这个画面了——显然哪里不对。在计算机科学里这叫**平方复杂度**，而认出它最好的方式，是知道这套理论、知道"有这种东西存在"。 **第二根：广度（breadth）。** 他合作过的大多数成功的工程师和工程领导，都能就几乎任何话题聊上几句，技术或非技术都行。他们可能是某些方面的专家，但最让人印象深刻的是：能从不同学科里抽出看似不相关的概念、编织起来解决问题。 **这就是那张高层海图。** 是它告诉你某些海域比别处更危险，是它让你能说"我们从这儿下水"。注意：不是每个领域都要专家级，只是**刚好够知道出问题该去查什么**——那些给你的远航当浮标的点。 有人问过他："广度怎么教？开一门什么都讲的概览课？"他当时没有好答案。后来想了想，他觉得这玩意**教不了**。没有一门"万物 101"可以选。能做的只是鼓励人去读、去探、保持好奇，尽可能多地吸收；记住那些奇怪的故障、那些"我靠"的瞬间，并思考它们跟你的工作有什么关系。经验越多，越要有意识地把日常经历和工作连起来。他说自己都记不清有多少次，是多年前在某个不相干项目里学到的一点点知识，突然回来救了场。 **这份经验和广度会复利，但它必须被维护。** **第三根：按需下潜（just-in-time depth）。** 这是"愿意并且能够跳进任何一个问题、把它搞明白"的能力：哪怕是在没有海图的水域，哪怕得钻进笼子里跟鲨鱼一起游一会儿，哪怕得把团队叫上、开那艘正经的大潜艇、潜过巨型鱿鱼去看看系统到底哪里坏了。 这是"为了把事做完，愿意学任何需要学的东西"。也是那种谦逊：知道某次下潜超出你的能力，需要找人帮忙。**不是每次下潜都能一个人完成，也不是每次下潜都值得做。** 几个月前，他在做自己的 agent 编排器，遇到 agent 和子 agent 的稳定性与生命周期 bug。他知道他想让它们干什么，但造出这玩意的机器人当初干得比较随意，于是所有 bug 一起回家。他盯着屏幕看 agent 一小时内第 n 次崩溃，几次让机器人自己修自己的烂摊子都失败之后——**突然想起多年前读过的一本 Kubernetes 的书**（"是的我是个极客"），"level-triggered state machine"（电平触发的状态机）这几个字直接拍在他脸上。 于是他下去了，比他原本打算的更深，甚至一路潜到"level-triggered"在电子工程里的起源；他带着自己的机器人一起下去，把核心架构从地基重做。之后它就一直稳如磐石。 这次成功的重写，主要靠两件事：**他碰巧记得多年前读到的一点东西**，以及**他愿意跳下去、学任何需要学的东西**。 ## 五、不再是 T 型人才 所以：你从一张高层海图（系统）开始，并明白它一路到海底都是层层抽象。而因为**所有抽象都会漏**，你作为系统所有者的工作，就是知道该往哪儿潜、潜多深。 这已经不是"通才 vs 专才"，甚至不是那个神话般的 T 型人才了。 ![四种技能形状](https://www.hubwiz.com/blog/content/images/2026/10/img_d13dfbc382a0699a91fec18d57c9fb25-800-1.jpg) 图：原文的四类技能形状——专才（一根深柱）、通才（一条宽而浅的带）、T 型（宽带上加一根深柱）、所有者（宽带上有许多深浅不一的窄潜，最深那根标橙、末端是一艘小潜艇）。 新的建造方式需要一个**能向未知深处下潜的通才**，一个"压力下快速学习者"——不是简历上那种注水的说法。你是真的要在跟海怪搏斗的同时快速学会东西。 他面试过很多人。当候选人在简历里写"快速学习者"时，他喜欢问：**讲一次你必须快速学会一个复杂系统的经历，你是怎么做的？** 你的答案会是什么？ ## 六、未来的所有者 基础可以学，广度可以攒，而**按需下潜可以练**。这三根柱子，就是一个人扩大自己"所有权份额"的方式。 也许你从浅水开始，把机器人放下去；你有扎实的基础、还过得去的广度，那就去建点东西——只是要在东西坏掉时，准备好穿上潜水服跟怪物一起游泳。 未来那些庞大的海底采矿作业由谁负责？没人知道。但他愿意赌：会是那些能同时挥动上面三根柱子的人。会是那种**把一台旧收音机拆开又修好**的孩子——他对收音机一无所知，只是想听音乐，哪怕装回去之后多出几颗螺丝。 ## 七、我们的整理：把"该潜多深"变成可检查的五问 原文给的是心智模型，缺的是判据。我们把它的三根柱子落到日常可操作的位置，再回答几个它没有正面回答的问题。 **一、三根柱子怎么在日常里练** | 柱子 | 它解决什么 | 一周能做的具体动作 | 练成的信号 | | ---- | -------------------- | -------------------------------------------- | ------------------------------ | | 基础 | 安静失败（变慢、偶发、第 19 次才挂） | 每季度挑一个主题读完并写一页笔记：复杂度、并发模型、分布式共识、TCP/HTTP 语义 | 看到"4s → 16s → 256s"能立刻说出这大概是几阶 | | 广度 | 该不该在这里下水 | 每周读一篇强制领域外的材料（数据库、编译器、硬件、财务），并写一句"它跟我系统哪里像" | 事故复盘时你能提出别人没想到的那条假设 | | 按需下潜 | 真掉进去能不能出来 | 每季度做一次"陌生代码库演练"：给你一个没写过的仓库 + 一个 bug，限时定位（不修） | 你能在 30 分钟内画出关键调用链，并说出该从哪读起 | （表格为我们整理，非原文内容。） **二、ownership 自检五问（十分钟内答不出，就说明你还不是 owner）** 1. 这个系统**最可能**从哪里坏？说出三个具体的点，不要"都不好说"。 2. 坏了**先看什么**？指标、日志、还是某张表？ 3. **回滚路径**是什么？多快能回？回滚会不会丢数据？ 4. 这个系统**依赖谁的不变量**？谁在替我们守它？ 5. 最近的改动里，哪一处**没人真正读过**？（这一问最像原文。） 前四问是从"你是被叫起来的人"这个定义反推出来的；第五问是他这篇文章的核心——**你没读过的东西，会以最贵的方式教你读它。** **三、原文回避了的两个问题，我们给个答案** - **"广度教不了"怎么办？** 原文说只能鼓励好奇。工程上可以更硬一点：把复盘做成资产。每次事故写三段（现象、真正的原因、如果重来我会先查什么），按时间轴存成可检索的库；新人入职先读 20 篇。这样广度不靠个人运气，而靠组织记忆。 - **初级工程师没有"手写"这条路怎么办？** 评论区已经有人给出更好的方案：在沙箱里**故意埋故障**，让新人去修 agent 写的代码——这恰好是"按需下潜"的可控练习。再配一条硬约束：新人第一个季度必须独立完成一次"陌生代码定位"（只定位不修改），并由 owner 复核他的推理路径。 **四、评论区四个问题的摘要** - **Kartik**：level-triggered 很适合 agent 生命周期——只要每一轮都比较"应该在跑什么"和"实际在跑什么"，子 agent 崩了也不会因为退出事件丢失而被漏掉。他问：重构的时候，"期望状态"是放在 agent 能读的文件里，还是只在编排器内部？ - **另一位**：SonarQube 那个故事说明，有用的技能是**发现不对**，不是写出修复。他建议把"探测器"显式化并与 agent 解耦：复杂度预算、依赖 diff 告警、关键模块的变异测试、以及一份 agent 改边界时必须更新的架构决策文件。他还问：是不是该让新人在沙箱里 debug 带种子的故障？ - **Abhinav**：问一个具体的小练习——怎么让新人在**不是自己写的代码**里练"找到正确的模块"？ - **WIO**：最扎心的一条——你之所以下水，是因为 CI 报警了。**那么当没有任何报警、agent 的代码在悄悄腐烂时，触发点在哪？** 最后这条正是这套框架的最大缺口：三根柱子能让你在**被通知**之后兜住系统，但它不负责通知你。原文的"安静失败"那一节其实已经埋了答案的一半——安静失败要靠**主动的度量**去发现，而不是靠等一个报错。 **站内几条接得上的线** - [AI 时代职业护城河：三种模式、工作流与判断力](https://www.hubwiz.com/blog/ai-career-moat-three-modes-workflow-judgment/)——同一件事的另一种切法：什么该交给 AI、什么必须自己上手。 - [Claude Code 团队怎么做代码评审：7 层防线](https://www.hubwiz.com/blog/claude-code-team-code-review/)——当"逐行读"不成立时，用机制替代阅读。 - [50 个 Agent 建文明：GPT 像蜂群，Claude 像议会](https://www.hubwiz.com/blog/agents-in-games-minecraft-mindustry-swarms/)——多 agent 协作会自发长出层级与官僚制，和本文说的"机器人建出自己维护不了的东西"是同一个现象的两种观察。 **五条边界** - **这是第一人称经验文，不是研究。** 一个 SonarQube 告警、一次架构重写，样本是 1。原文也没有任何量化数据支撑"初级工程师不可行"这个判断。 - **"经济上不可行"是论点，不是测量。** 值得认真对待，但要说清它没有被验证：也许某些公司的培养成本结构会不同。 - **隐喻会被类比带着走。** 潜水、海怪、金块这套说法很有说服力，也因此容易让人忽略反例：很多系统的问题根本不是"深海"，而是"根本没人在看水位"。 - **"owner"在这里是窄定义。** 原文明确把它定义成"坏了被叫起来的人"。在分工细的组织里，这个角色可能叫 SRE、可能叫值班工程师，而不是技术负责人。 - **三根柱子不是招聘标准。** 原文结尾的"拆收音机的孩子"很动人，但它描述的是**动机**，不是能力证据。把它当筛人标准，会筛出很多只会拆东西的人。 **来源**：Adrian Quiroga,《Here Be Monsters: What Do You Still Need to Know When Agents Do the Work?》, blog.adrq.dev, 2026-10-27（页面显示 10-29 更新），约 15 分钟阅读。原文链接：[https://blog.adrq.dev/here-be-monsters-what-do-you-still-need-to-know-when-agents-do-the-work](https://blog.adrq.dev/here-be-monsters-what-do-you-still-need-to-know-when-agents-do-the-work?ref=hubwiz.com)。三根柱子、潜水机器人隐喻、Kubernetes 与 level-triggered 的案例、面试问题均为原文内容；四类技能形状图为原文配图（已转存站内）；三根柱子那张表、"自检五问"、"两个回避的问题"、评论区摘要与五条边界为我们整理。 本文由汇智网编译整理，转载请注明出处。 > **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)