最近这半个月，软件架构圈子里有两件事撞在了一起。
一件是今天微博上刷屏的：有人把 Claude Code 的 51 万多行 TypeScript 源码拆了个底朝天，Agent Loop 调度、三级上下文压缩、四层权限拦截、Hook 生命周期，全给剖了一遍，甚至直接出成了书。微博另一件是 8 月初知乎上一个 369 赞的热帖——《为什么我觉得 agent 开发这个工作怪怪的？》。评论区一句「ai 写，人 review，人担责」把我看笑了又看沉默了。知乎
两件事看似不挨着，其实在问同一个问题：当模型自己会写代码、会调工具、会跑长任务了，软件架构还剩什么可干的？
我把知乎、微博、36氪这几个平台最近的热门讨论翻了一遍，给你整理出答案。先说结论：架构没有消失，而是搬家了——有的层在快速折旧，有的层在肉眼可见地升值。
这是社区里流传的 Claude Code 架构全景：拆完 51 万行源码你会发现，里面 80% 的代码不是在搞什么黑科技让 AI 更聪明，而是在死磕两个字——可靠。这也是全文的题眼。
先说贬值的那层：给模型打补丁的"适配工程"
那个 369 赞的回答说得特别狠：过去两年，绝大多数 Agent 开发者做的其实是"模型缺陷适配工程"。知乎模型推理不行，你写一堆硬编码条件判断帮它分发任务；模型上下文短，你手写向量检索把内容拼进去；模型函数调用不稳，你写正则去修它的输出格式。这些活儿，模型每升级一次就消失一批。从 2024 到 2026，长上下文效率大幅提升、原生工具调用准确率逼近满分、多步推理模型自己就能做——于是那些写了几个月的编排代码，瞬间变成负债。
这层东西像快时尚：当季能穿，过季白送都没人要。如果你现在每天的工作还是给模型挂几个搜索接口、写几条格式化提示词、补一堆重试逻辑，那确实要警惕。
再看升值的那层：确定性系统与概率性模型的对接工程
同一个回答里，作者给了一个我认为是近期最有价值的判断：模型再强，它也是概率生成，输出带随机性；而真实业务系统要的是确定性。这两者之间的裂缝，不是把参数从几千亿加到几万亿就能抹平的。知乎他举的例子很具体：供应链里一批核心零部件被海关扣了，大模型可以分析出最优替代供应商、甚至草拟采购合同，但它能直接进 ERP 点确认付款吗？能绕过财务合规审核下发采购指令吗？能在网络故障时自己回滚分布式事务吗？都不能。
所以真正值钱的工作是：设计幂等接口，保证模型重复调用不会重复扣款；设计熔断降级，模型决策跑偏时能切回规则引擎或人工接管；设计状态恢复，让长任务宕机后能断点续传；设计分层权限闸门，把模型的每一次动作关在可控边界里。用他的原话说——模型只是系统里的一个计算单元，而你搭的是容纳这个计算单元运行的完整软件架构。知乎
Claude Code 自己的做法就是个样本：工具调用要穿过四层权限防御，哪个动作能落地、哪个要被拦下，全由外层的确定性系统说了算。知乎概率性输出想进业务系统，先过这道笼子。
这里有个反直觉的历史规律值得记住：硬件越强，操作系统没有消失，反而更复杂；数据库越快，后端没有失业，反而催生了分布式架构。模型越强，上层架构的空间只会更大，不会更小。
新出现的那层：Harness 工程，本身就是架构问题
Claude Code 的源码拆解为什么火？因为它证明了一件事：让 Agent 稳定干活，靠的不是 Prompt 技巧，而是工业级的运行时架构——现在圈子里管这叫 Harness 工程。有篇热帖总结得很到位：AI 圈的风向正在从"拼模型智商"变成"拼系统求稳"。知乎
我把微博的书讯、知乎几篇源码分析和最近的论文解读对照着看了一遍。其中一篇用高质量 Python 代码重写了 Claude Code 51 万行代码的核心功能，评论区有 223 条讨论。知乎大家提到的工业级设计高度收敛，基本就六个模块：
一是调度循环，Agent Loop 怎么管"思考—调工具—看结果"的循环，什么时候停；二是上下文管理，上下文窗口再长也是稀缺资源，三级压缩、记忆系统、子代理分流都是在解决这个；三是权限与安全边界，四层权限拦截、Hook 生命周期，本质是给概率性输出上笼子；四是工具生态，MCP 插件化让能力可插拔；五是多代理协作，Mailbox 式的代理间通信；六是反馈与自纠，验证机制、自动纠错。微博
有篇知乎源码分析里放了张对比表，我觉得是理解这件事的钥匙。传统分布式架构的控制流是确定的，代码逻辑决定下一步；Agent 架构的控制流是概率性的，模型决定下一步。知乎控制流一变，可观测性、容错、状态管理全都要重做一遍——这就是新架构层的含金量所在。
谁该关心，谁可以略过
如果你是正在搭 Agent 系统的后端或架构师：这篇文章的分层可以直接拿来盘点自己的代码——哪些是补丁，哪些是骨架，哪些是运行时。评论区有人补了一刀：很多人说 AI 写的代码无法上生产，因为复杂促销、交易模块可能存在资损风险，这里差的其实也是软件工程控制。知乎这些资损风险，模型兜不住，架构兜。
如果你是普通业务开发、暂时不碰 Agent：可以先收藏不动手。但有个信号值得留意——36氪最近有篇文章叫《大扁平化时代》，致"一人撑起整支工程团队的工程师"。36氪微博上也有人重提康威定律和《人月神话》里的外科手术团队：一个判断力强的人带一群 Agent，正在逼近当年要靠分工才能实现的产出。微博谷歌首席工程师则在说，二十年自然生长出来的软件工程生态，快被大模型 10 倍提速撑爆了。36氪AI 改变的不只是写代码的方式，还有团队结构，而组织结构变了，系统架构一定会跟着变。
如果你是技术负责人：知乎上有句话可以抄进你的评审标准里：AI 就是所有软件架构和规范的试金石，能让 AI 长期稳定高效输出的架构和规范，才是好架构、好规范。知乎你的代码库对 AI 友不友好，马上就会体现在研发效率账单上。
往前走一步：三个自检问题
最后给三个可以直接用的问题，下次评估自己的架构投入时问一遍：
第一，这层逻辑会不会因为模型下一次升级而消失？会，就是折旧层，够用就行，别精装修。第二，这是不是业务确定性的骨架——事务、状态机、权限、审计？是，就值得重仓，它跨模型时代保值。第三，你的 Harness 能不能换模型不换架构？工具协议（MCP）、权限、可观测性这些如果跟某个模型深度绑死，等于把自己锁死在一个供应商的版本节奏上。
值得继续盯的三个信号：Harness 的标准化动向、上下文工程从技巧变成学科的过程，以及"Agent 自我修改"之后运行时怎么保证安全进出。最近已经有论文提出，组件的退出逻辑不该再单独维护，而应由它曾经产生的副作用自然推导出来。知乎这个方向一旦成熟，今天讨论的很多问题都会被重写，到时候我再带你复盘。
一句话收尾：模型越来越像水电煤，架构越来越像房子本身。水电再便宜再强大，也不能替你决定房子怎么盖。
