Tony Bai - 一个程序员的心路历程

2026 软件开发新纪元：解读 Anthropic《Agentic Coding 趋势报告》

二月 11, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/02/11/2026-software-development-anthropic-agentic-coding-trends-report

大家好，我是Tony Bai。

时间来到 2026 年初。回顾过去的一年，软件工程领域发生的变化比过去十年加起来还要多。

如果说 2024-2025 年是 AI Coding（AI 编程） 的“试水期”，开发者们还在为 Cursor 的 Tab 补全感到兴奋，或者为 Claude 3.5 能够写出一个贪吃蛇游戏而惊叹；那么 2026 年，正如 Anthropic 最新发布的重磅报告《2026 Agentic Coding Trends Report》所言，我们正式进入了 Agentic Coding（智能体编程） 的深水区。

这份报告更像是一份“新时代软件工程的生存指南”。它揭示了一个核心事实：AI 已经从一个被动的“Copilot（副驾驶）”，进化为一个主动的“Collaborator（协作者）”，甚至是一个独立的“Team（团队）”。

在这个新时代，软件开发的瓶颈不再是“写代码”的速度，而是“定义问题”的精度和“编排智能体”的能力。作为开发者，我们必须清醒地认识到：SDLC（软件开发生命周期）正在被重写，而我们的角色也正在被重新定义。

今天，我们将深度解读这份报告中的 8 大趋势，剖析 3 大核心变革，并探讨在 2026 年，作为一名技术人，该如何拿到通往未来的船票。

地壳运动 —— 软件开发生命周期的彻底重构

Anthropic 报告的开篇就用“Tectonic Shift（地壳运动）”来形容正在发生的变化。这绝非夸张。

1. 抽象层级的再次跃迁

在计算机历史上，每一次抽象层级的提升，都带来了生产力的爆发：从机器码到汇编，从汇编到 C，从 C 到高级语言。

而在 2026 年，我们迎来了最新的抽象层：自然语言驱动的智能体编排。

报告指出，“写代码、调试、维护” 这些战术性的工作，正在全面转移给 AI。工程师的精力开始聚焦于架构设计、系统设计和战略决策。

这意味着，未来的“源码”，可能不再是 GitHub 仓库里那一堆 .ts 或 .go 文件，而是“Prompt + Spec（规规说明书） + Agent Configuration（智能体配置）”。

2. 入职（Onboarding）时间的坍塌

这是报告中一个极具冲击力的预测：“新员工入职一个复杂代码库的时间，将从数周缩短为数小时。”

还记得以前入职一家新公司，光是配置环境、阅读文档、理解那堆“屎山代码”的逻辑，就要花掉两周时间吗？

在 Agentic Coding 时代，像 Augment Code 这样的工具（报告案例），利用 Claude 对代码库的深度理解，可以让工程师在几分钟内获得对系统上下文的掌控。此外，一位 CTO 预估需要 4-8 个月完成的项目，在 Claude Code的加持下，两周内就完成了。这是人力资源配置的革命。企业可以实现“动态激增（Surge）”式的人员调配，工程师可以随时在不同项目间无缝切换，而无需支付高昂的认知切换成本。

3. 工程师的“全栈化”

报告揭示了一个有趣的现象：AI 并没有取代工程师，而是让工程师变得更“全栈”了。

前端工程师开始敢于修改后端数据库，后端工程师也能轻松搞定复杂的 CSS 动画。为什么？因为 AI 填补了那部分“知识鸿沟”。

只要你具备系统思维和验收能力，具体的实现细节（Implementation Details）不再是障碍。这标志着“领域专家（Domain Expert）”与“通用工程师（Generalist）”的边界开始模糊。

能力跃迁 —— 从单体智能到“智能体集群”

如果说第一部分是“软性”的流程变化，那么第二部分则是“硬核”的技术能力升级。Anthropic 报告明确指出，2026 年的 AI 编码将呈现出集群化和长时程的特征。

4. 单体 Agent 进化为 Coordinated Teams

2025 年，我们还在试图用一个超级 Agent 解决所有问题。2026 年，这种做法已经被淘汰。

报告预测：“多智能体系统（Multi-agent Systems）将取代单智能体工作流。”

分工与协作：就像人类团队一样，我们需要“产品经理 Agent”拆解需求，“架构师 Agent”设计接口，“编码 Agent”写代码，“测试 Agent”找 Bug。
并行推理：通过在不同的上下文窗口（Context Windows）中并行处理任务，效率实现了指数级增长。
案例：劳动力管理平台 Fountain 使用 Claude 构建了分层的多智能体编排系统，将筛选速度提升了 50%。

5. 从“分钟级”任务到“周级”长跑

早期的 Agent 只能处理“帮我写个函数”这种几分钟的短任务。

但报告指出，Long-running Agents（长时运行智能体） 正在成为主流。

时间跨度：Agent 可以连续工作数天甚至数周。
自我管理：它们能够制定计划、迭代代码、从失败中恢复（Self-healing），并维护一致的状态。
消除技术债：那些以前因为“太麻烦”而被搁置的重构任务、文档补全任务，现在可以丢给一个长时运行的 Agent，让它在后台慢慢跑，直到把 backlog 清空。

Rakuten 的案例令人印象深刻：工程师让 Claude Code 在一个拥有 1250 万行代码的开源库（vLLM）中实现一个复杂的数学算法。Claude 独自工作了 7 个小时，最终交付了准确率为 99.9% 的代码。

这就是“无人值守开发（Unattended Development）”的雏形。

6. 协作悖论：为什么我们还不能“完全放手”？

这部分是报告中最发人深省的洞察。

Anthropic 的社会影响研究团队发现了一个“协作悖论”：

尽管工程师在 60% 的工作中使用了 AI，但他们报告称，能够“完全委托（Fully Delegate）”给 AI 的任务只有 0-20%。

这意味着 Human-in-the-loop（人类在环）依然是核心。

AI 不是那种“交给他就不管了”的外包，而是一个需要你持续关注、持续反馈的“实习生”或“副驾驶”。

2026 的关键能力：智能体开始学会“求助（Ask for help）”。与其盲目猜测，不如在不确定时主动询问人类：“这里有两种设计方案，你倾向于哪一种？”
监督的规模化：人类不再逐行审查代码，而是审查关键决策点和高风险边界。

行业冲击 —— 经济学与组织架构的重塑

技术变革必然引发经济变革。报告的第三部分探讨了 Agentic Coding 对商业世界的深远影响。

7. 软件开发的经济学重塑

传统的软件开发成本高昂，导致很多“小需求”或“长尾需求”无法被满足（ROI 算不过来）。

但 AI Agent 的出现，极大地降低了软件生产的边际成本。

Papercuts：那些让用户难受但又不值得花工程师时间去修的小 Bug，现在可以被 Agent 批量修复。
产出量（Output Volume）：生产力的提升不仅仅是“做得快”，更是“做得多”。企业可以尝试更多的实验，开发更多的定制化工具。
案例：通信巨头 TELUS 的团队创建了 13,000 多个自定义 AI 解决方案，节省了 50 万小时的工作时间。

8. 编程能力的“民主化”与“下沉”

这是我认为最激动人心的趋势：Agentic Coding Expands to New Surfaces and Users.

语言障碍消失：COBOL、Fortran 这些“古董语言”的维护不再是难题。AI 是最好的翻译官。
非技术人员入场：销售、市场、法务团队，开始使用 Agent 构建自己的自动化工具。
案例：法律科技平台 Legora 让不懂代码的律师也能利用 Claude Code 构建复杂的自动化工作流；Zapier 内部实现了 89% 的 AI 采用率，设计团队直接用 Claude Artifacts 进行原型开发。

“人人都是程序员” 的口号喊了很多年，但在 2026 年，依靠 Agent，这终于变成了现实。

9. 安全的双刃剑

当然，硬币总有两面。报告特别提到了 Dual-use Risk（双重用途风险）。

防御侧：Agent 可以自动进行代码审计、漏洞扫描、安全加固。
攻击侧：攻击者也可以利用 Agent 批量生成攻击脚本、寻找零日漏洞。

这要求我们在设计 Agentic System 时，必须将安全性（Security-first Architecture） 植入到基因中。

2026 年的行动指南 —— 优先事项

面对这些汹涌而来的趋势，作为技术决策者或一线开发者，我们在 2026 年应该做什么？ Anthropic 给出了 4 个明确的优先事项：

掌握多智能体协作 (Master Multi-agent Coordination)：不要再沉迷于优化单个 Prompt。去学习如何使用 Gas Town 或 Claude Code 的 Agent Team 模式。学会如何让多个 Agent 像一支军队一样协同作战。这是解决复杂问题的唯一路径。
扩展人类的监督能力 (Scale Human Oversight)：构建自动化审查系统。当 AI 一天生成 1 万行代码时，靠人眼看是看不过来的。你需要构建基于 AI 的 Reviewer，以及基于严格测试（Test-Driven）的验收流水线。
赋能领域专家 (Empower Domain Experts)：不要把 AI 编程工具锁在技术部门。把它们分发给产品经理、法务、运营。让他们自己去构建解决问题的工具。
内嵌安全架构 (Embed Security Architecture)：从第一天起，就要考虑 Agent 的权限边界。不要给 Agent 无限制的 sudo 权限。构建沙箱（Sandbox）和鉴权机制。

小结：拥抱“不确定性”的艺术

读完这份报告，我最大的感受是：软件工程正在从一门“精确的科学”，变成一门“管理的艺术”。

在 Software 1.0 时代，我们追求的是确定性，每一行代码的执行逻辑都是可预测的。

在 Agentic Coding 时代，我们管理的是概率，是模糊性，是一群有一定自主权但偶尔会犯错的数字员工。

这并没有让软件工程变简单，反而变得更难、更深刻了。

我们不再是代码的作者（Author），我们是代码的编辑（Editor）、导演（Director）和架构师（Architect）。

2026 年，对于那些愿意拥抱变化、主动升级认知模型的开发者来说，将是最好的时代。限制你产出的，不再是手速，而是你的想象力和领导力。

资料链接：https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf

你感到的是“解放”还是“威胁”？

Anthropic 预测 2026 年新员工入职代码库的时间将坍塌为几小时。在你目前的团队中，是否已经感受到了 AI 带来的这种“入职加速”？如果有一天你主要的工作变成了“编排 Agent 集群”，你觉得最大的挑战是什么？

欢迎在评论区分享你的 2026 职业预判！

如何落地 Anthropic 的预测？

趋势看懂了，但怎么落地？

如何构建一个多智能体协作的代码重构流水线？
如何实现长时程 Agent 的状态管理和断点续传？
如何让非技术人员也能安全地使用 Coding Agent？

Anthropic 的报告指明了方向，而我的专栏负责提供地图和车辆。

在我的极客时间专栏《AI 原生开发工作流实战》中，我们将深度对齐这份报告中的前沿技术：

实战 Agent Team：复刻 Claude Code 的多智能体协作模式。
安全与治理：学习如何为 Agent 构建安全护栏。
构建自动化工厂的初步方案：打造基于 Spec 驱动的“无人值守”开发流。

不要做旧时代的守墓人，做新时代的领航者。扫描下方二维码，开启你的 Agentic Coding 之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

Go 1.26 发布在即，为何 json/v2 依然“难产”？七大技术路障全解析

二月 11, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/02/11/go-1-26-json-v2-delay-7-technical-roadblocks

大家好，我是Tony Bai。

Go 1.26 预计将于本月（2026 年 2 月）正式发布。然而，在即将到来的 release notes 的欢呼声中，有一个备受瞩目的名字依然带着“实验性”的标签躲在 GOEXPERIMENT 背后——那就是 encoding/json/v2。

作为 Go 生态中最核心的基础设施之一，JSON 库的每一次呼吸都牵动着数百万开发者的神经。从 v1 到 v2，不仅仅是性能的提升，更是一场关于API 设计哲学、向后兼容性与极致性能的艰难博弈。

很多人以为 v2 的延迟是因为“官方动作慢”或“设计理念之争”。但当我们深入 json/v2 工作组的看板，剥开表层的讨论，会发现横亘在稳定版之前的，是七个具体而微、却又关乎全局的技术“钉子”。这些问题并非宏大的路线图分歧，而是关乎浮点数精度、错误处理语义、API 封装性等实打实的工程细节。

本文将基于最新的 GitHub Issues 讨论（截至 2026 年 2 月），带你通过显微镜审视这七大阻塞问题，一窥 Go 标准库演进背后的严谨与妥协。

七大阻塞问题（Blockers）一览

深度解析：魔鬼藏在细节中

1. API 设计的“丑陋妥协”：jsontext.Internal (#73435)

在当前的 encoding/json/jsontext 包中，竟然存在一个导出的 Internal 类型。这在 Go 标准库的审美中，简直是“房间里的大象”。

jsontext 是 v2 引入的底层包，专注于 JSON 的语法解析（Tokenizing），而上层的 json 包负责语义绑定（Binding）。为了让上层包能够访问底层的缓冲区或状态机，当前的实现不得不导出一个 Internal 符号。

这违背了 Go 标准库的黄金法则之一：公共 API 必须是为用户设计的，而不是为实现者自己设计的。

Joe Tsai (dsnet) 提出了一种解决方案：将 jsontext 的核心逻辑移入 encoding/json/internal/jsontext，然后通过类型别名（Type Alias）在公共包中暴露 API。然而，这带来了一个新的难题：godoc 对类型别名的支持并不友好，生成的文档可能会让用户感到困惑，因为方法都挂载在内部类型上。

这个问题已经上升为工具链生态问题。如果这个问题不解决，v2 发布后将面临两个风险：要么用户依赖了这个“临时” API 导致未来无法修改，要么标准库留下了一个永久的“伤疤”。

2. 致命的递归：当 Unmarshaler 遇到指针 (#75361)

这是一个真实且诡异的 Bug。一位开发者在迁移旧代码时发现，以下模式在 v1 中正常工作，但在开启 GOEXPERIMENT=jsonv2 后会导致栈溢出（Stack Overflow）：

type MyType string

// 自定义 Unmarshal 方法
func (m *MyType) UnmarshalJSON(b []byte) error {
    // 试图通过定义一个新类型来“剥离”当前类型的方法，以回退到默认行为
    type MyTypeNoMethods *MyType
    var derived MyTypeNoMethods = MyTypeNoMethods(m)

    // v2 在这里会错误地再次识别出 derived 拥有 UnmarshalJSON 方法
    // 从而导致无限递归调用自己
    return json.Unmarshal(b, derived)
}

在 v1 中，开发者习惯通过类型转换来“剥离”自定义方法。但在 v2 中，为了修复 v1 中某些指针方法无法被调用的 Bug（如 #22967），引入了更激进的方法集查找逻辑。

v2 的逻辑是：只要这个值的地址（Addressable）能找到 UnmarshalJSON 方法，就调用它。在上面的例子中，derived 虽然是新类型，但它底层的指针指向的还是 MyType，v2 过于“聪明”地认为应该调用 (MyType).UnmarshalJSON，结果造成了死循环。

这是一个典型的“修复了一个 Bug，却引入了另一个 Bug”的案例。Go 团队目前倾向于保留 v2 的正确逻辑（即更一致的方法调用），但也必须为这种遗留代码提供一种检测机制。目前的计划是引入运行时检测或 go vet 检查，明确告知用户：请使用 type MyTypeNoMethods MyType（非指针别名）来剥离方法，而不是使用指针别名。

3. 浮点数的“薛定谔精度”：float32 (#76430)

下面是展示该问题的一段示例代码：

var f float32 = 3.1415927 // math.Pi 的 float32 近似值
json.Marshal(f)

输出应该是 3.1415927（保持 float32 精度），还是 3.1415927410125732（提升到 float64 精度以确保无损）？

Go v1 的 json 包为了兼容性，倾向于将所有浮点数视为 float64 处理。这导致 float32 在序列化时经常会出现“精度噪音”——那些用户并不想要的、只有在 float64 精度下才有意义的尾数。

然而，v2 的 jsontext 包默认使用 64 位精度。这导致了 json.Marshal（上层）和 jsontext.Encoder（底层）在行为上的不一致。

用户期望：float32 就该像 float32，短小精悍。
技术现实：JSON 标准（RFC 8259）并没有区分浮点精度。
性能视角：处理 32 位浮点数理论上更快，但需要专门的算法路径。

Go 团队正在考虑引入 Float32 构造器和访问器到 jsontext 包中，并修改底层的 AppendFloat 逻辑，以支持显式的 32 位浮点数格式化。这不仅是为了“好看”，更是为了数值正确性——避免“双重舍入”（Double Rounding）带来的微小误差。

4. 选项系统的“任督二脉”：透传难题 (#76440)

你调用 json.Marshal(v, json.WithIndent(” “)) 很爽，但如果你想控制底层的 jsontext 行为（比如“允许非法 UTF-8”或“允许重复键名”），你发现：顶层函数把路堵死了。目前的 MarshalEncode 只接受 json.Option，不接受 jsontext.Option。

v2 将 json（语义层）和 jsontext（语法层）拆分是架构的一大进步。但这也带来了配置穿透的问题。

如果为了保持 API 纯洁，强迫用户必须先创建一个 jsontext.Encoder 并在那里配置选项，再传给 json.MarshalEncode，那么 99% 的简单用例都会变得无比繁琐。

Go团队给出的提案是打破层级隔离，允许 json.Marshal 等顶层函数直接接受 jsontext.Option。这是一个实用主义战胜洁癖的胜利。

5. 功能做减法：unknown 标签的存废 (#77271)

v2 曾引入了一个 unknown 结构体标签，用于指示某个字段专门用来捕获所有未知的 JSON 字段。同时，还有一个 DiscardUnknownMembers 选项用于丢弃未知字段。

dsnet（Joe Tsai）发起提案，建议删除两个功能。理由如下：

功能重叠：v2 已经引入了 inline 标签，它与 unknown 的行为非常相似，仅仅是语义上的微小差别（是否包含“已知”字段）。这种微小的差别会让用户感到困惑。
API 极简主义：如果用户真的需要处理未知字段，可以通过自定义 Unmarshaler 来实现，或者利用 inline 标签配合后期处理。
向后兼容的智慧：添加功能永远比删除功能容易。现在删除，未来如果真有需求还可以加回来；但如果现在保留，未来想删就难了。

6. 控制流的缺失：SkipFunc (#74324)

json.SkipFunc 是 v2 引入的一个 Sentinel Error，用于告诉编码器“跳过当前字段/值”。目前它只能在 MarshalToFunc（用户自定义函数）中使用。但如果我在类型的方法 MarshalJSONTo 中想跳过自己怎么办？目前是不支持的。

这是一个典型的“二等公民”问题。用户自定义的函数拥有比类型方法更高的权限。这导致在迁移旧代码时，如果要实现“条件性跳过”，必须写出非常丑陋的 hack 代码（比如定义一个空结构体来占位）。

允许 MarshalJSONTo 返回 SkipFunc 看似简单，但它要求调用者必须处理这个错误。这意味着不能直接调用 v.MarshalJSONTo，而必须通过 json.Marshal 来调用，否则你会收到一个未处理的错误。这需要文档和工具链的配合。

7. 文档真空：新接口的最佳实践 (#76712)

v2 引入了 MarshalerTo 和 UnmarshalerFrom 两个高性能接口，它们直接操作 jsontext.Encoder/Decoder，避免了内存分配。但是，到底该什么时候用它们？

目前缺乏明确的文档指导。如果用户在任何时候都直接调用 v.MarshalJSONTo(enc)，可能会绕过 json.Marshal 中处理的许多全局选项（如大小写敏感、省略零值等）。

Go 团队计划在文档中明确：这属于“高级 API”，普通用户应始终使用 json.Marshal，除非你在编写极其底层的库。

路线图：我们何时能用上“真v2”？

根据最新的工作组纪要和 Issue 状态，我们可以画出一条清晰的时间线：

当前 (Go 1.26, 2026.02)：GOEXPERIMENT=jsonv2 继续存在。v2 代码库已进入主仓库，但 API 仍未冻结。此时适合库作者进行集成测试，但不建议在生产环境核心业务中大规模铺开。
决战期 (2026 H1)：必须彻底解决上述 7 个 Blocker。特别是 API 签名相关的修改（如 float32 支持和 SkipFunc），一旦定型就是 10 年承诺。
目标 (Go 1.27, 2026.08)：如果一切顺利，我们有望在今年 8 月发布的 Go 1.27 中，看到移除实验标签、正式可用的 encoding/json/v2。这意味着 Go 语言将迎来其历史上最大规模的标准库升级之一。

小结：给 Gopher 的建议

别急着重构：现有的 encoding/json (v1) 依然稳健。除非你有极端的性能需求（v2 性能提升显著）或需要 v2 独有的某些特性，否则请按兵不动。
关注 jsontext：即使不用 v2 的序列化，新独立的 jsontext 包也是一个处理 JSON Token 流的神器，非常适合写高性能的底层解析工具。它的 API 设计比 v1 的 Scanner 更加现代化和高效。
参与反馈：现在是影响 Go 未来 10 年 JSON 处理方式的最后窗口期。如果你对上述 Issue 有独到见解，去 GitHub 上发声吧！

Go 团队的“慢”，是对生态的“敬”。这七个拦路虎，每一个都是为了让未来的十年里，我们能写出更少 Bug、更快速度的 Go 代码。好事多磨，让我们静候佳音。

参考资料

json/v2 工作组的看板 – https://github.com/orgs/golang/projects/50
encoding/json/v2: working group meeting minutes – https://github.com/golang/go/issues/76406

你更在意什么？

Go 团队为了 API 的洁癖和严谨，宁愿让 json/v2 多飞一会儿。在你的开发实践中，你更倾向于“尽快用上新特性”，还是“哪怕慢一点也要保证接口设计的绝对完美”？你对 float32 的精度噪音有切肤之痛吗？

欢迎在评论区分享你的看法，我们一起坐等 Go 1.26 官宣！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：