Agentic Work 的经济学

Coding Agent 可以在几分钟内生成过去开发者需要数小时才能完成的代码。如今，这已经不是什么特别罕见的体验。根据任务不同，差距甚至可能相当惊人：过去需要半个工作日的实现，几分钟之后就可能以一个完整的首版 Diff 出现在面前。

于是，一个看似顺理成章的计算很容易出现：

代码生成快 10×
=
软件开发快 10×
=
成本降低 10×

这个计算的第一行可能成立。后面的两个等号不成立。

并不是因为代码生成没有价值。恰恰相反：我现在非常密集地使用 Coding Agents，也切实感受到了明显的生产力提升。对我自己的工作而言，我目前会把这个效果粗略估计在 20% 左右——而且已经把对生成改动进行认真 Review 的时间计算在内。这个数字不是科学研究中的 Effect Size，只是我在当前工作环境里的个人经验值。

问题出在另一个地方：我们把一个生产步骤的加速，误认为整个生产系统的加速。

Software Engineering 从来不只是写代码。在改动之前，需要理解问题、澄清 Requirements、做架构判断和方案决策。改动之后还有测试、集成、Debugging、Verification、Review、Security、运行与业务 Acceptance。有些步骤同样可以被 AI 加速；有些基本仍然存在；还有一些在机器生成的改动越来越多之后，反而变得更重要。

因此，真正有意思的经济问题并不是：

一个模型能以多低的价格生成 Tokens？

而是：

为了让一个期望中的改动最终成为技术上和业务上都经过足够验证、可以接受的改动，我们究竟付出了多少成本？

下面我把这个运营层面的单位称为 Cost per Accepted Change。

它并不等同于 ROI。一个改动可能只花几欧元就完成生成、测试和 Acceptance，却依然没有任何商业价值。反过来，一个昂贵的改动也可能创造巨大的业务价值。Cost per Accepted Change 首先衡量的是 Engineering 流程的效率。经济价值还在更高一层。

所以，这篇文章的主线会从 Token 出发，经过 Agent Run 和 Accepted Change，再走到整个组织——最终抵达一个很容易在短期生产力计算中被忽略的问题：完成这些改动之后，组织还拥有哪些能力？又为未来积累了哪些能力？

错误的乘数

Software Engineering 不等于 Coding。

这听起来很普通，但在很多关于 AI 生产力的讨论里，人们却很快就忘记这一点。假设某项原来需要三小时的工作现在缩短到 18 分钟，那么可见的加速倍数确实是十倍。问题是，这项工作可能只是一个总共需要八小时的变更中的一部分。

剩下的工作不会自动消失。

业务 Requirement 仍然需要被理解。架构决策仍然必须适配现有系统。测试不仅要“存在”，还必须验证有意义的命题。一个 Diff 可以语法完全正确，却在业务上是错的。一个 Migration 可以本地成功，却在生产环境失败。Security Requirement 也不会因为模型自信地声称自己已经遵守就自动成立。

Coding Agents 同样可以帮助完成这些工作。这也是它们价值的重要组成部分。但如果如此，我们就应该测量这些步骤真正被加速了多少，而不是只拿实现代码生成速度的倍数作为整个 Software Engineering 的倍数。

10× 代码生成
≠
10× Software Engineering
≠
10× 成本下降

当前的实证研究恰好说明，测量结果高度依赖你观察的是哪一段工作。在一项著名的随机 GitHub Copilot 实验中，95 名招募来的软件开发者完成一个明确边界的 JavaScript 任务，使用 Copilot 的参与者平均快了 55.8%。随后，在 Microsoft、Accenture 和另一家 Fortune 100 企业进行的三项更大型随机现场实验，共覆盖 4,867 名开发者，合并分析显示完成任务数量提高了 26.08%。这项研究现在已经发表在 Management Science。即便如此，不同实验之间的结果差异仍然很大；合并估计的标准误为 10.3 个百分点。

另一个场景甚至得出了相反结果。2025 年，METR 让经验丰富的开源开发者在他们已经熟悉多年的真实 Repository 中完成真实任务。在当时可用的 AI Tools 帮助下，随机实验中的开发者平均反而多花了 19% 的时间。METR 自己明确强调，这只是一个针对 2025 年初工具、特定环境的历史快照。2026 年，使用更新模型的后续实验更倾向于显示加速，但 Selection 和测量问题严重到作者自己都认为无法可靠给出精确的效果规模。

更有意思的是，2026 年 9 月修订的 NBER Working Paper Writing Code vs. Shipping Code。它使用超过 50 万 GitHub 开发者的数据及其 AI 使用 Telemetry。随着 Coding Tools 的更新换代，测得的 Commits 大幅增长。对于 Autonomous Coding Agents，作者报告 Commits 的累计效应达到 240%。但随着生产层级上升，这个效应显著减弱：到 Projects 只剩 80%，真正的 Releases 只有 30%。这仍然是一篇 Working Paper，而不是最终的因果结论。但它非常清楚地说明了本文的问题：Writing Code 和 Shipping Code 是两个不同的生产阶段。

因此，真正重要的乘数并不在 Editor 里，而在完整的生产流程里。

从 Token 到 Accepted Change

语言模型最简单的经济指标是 Token 单价。它精确、容易比较，因此非常诱人。

可惜，它回答的问题非常小。

更有意义的层级应该是：

Cost per Token
↓
Cost per Run
↓
Cost per Successful Run
↓
Cost per Accepted Change
↓
Economic Value

Cost per Token 回答的是：按定价表计算，Inference 有多贵。

Cost per Run 加上了一个实际 Run 到底用了多少 Context 和 Output。

Cost per Successful Run 还要考虑 Agent 可能失败、终止，或者走上一条不可用的方案路线。

Cost per Accepted Change 最终还要计算：为了让这个 Change 真正达到可接受状态，我们经历了多少次尝试、测试、修正、Review，以及多少 Human Work。

再往上一层，才是 Economic Value：这个改动到底创造了什么经济收益？

换一种说法：

Model Pricing 回答的是计算本身多少钱。它并不回答解决问题多少钱。

这是一个根本差别。如果一个 Agent Run 只花 20 美分，却让我再花 45 分钟去修，它完全可能比一个花 5 美元、只需要 10 分钟 Review 就能接受的 Run 更贵。

而一个技术上已经 Accepted 的 Change，也完全可能只是一个没人需要的 Feature。

所以，Cost per Accepted Change 不是 ROI 的替代品。它是 ROI 下面紧邻的 Engineering 运营层。

Generation 实际上要花多少钱？

在基于 Token 的计费里，首先有三类直接定价的 Token 特别重要。Input Tokens 包含模型接收到的 Context：Prompt、Conversation History、Source Code、Agent Instructions、Tool Results，以及可能很大一部分 Repository。Cached Input 是可复用的 Context，Provider 可以用更低价格计费。Output Tokens 包含模型产生的输出使用量。对于 Reasoning Models，其中还可能包含内部的 Reasoning Tokens；这些 Tokens 不一定以可见答案文字出现。

Agentic Workflow 会让这笔账比一次普通 Chat 更复杂。Agent 会读取文件、调用 Tools、接收 Tool 的返回、修改代码、启动测试，再继续处理测试输出。它可能反复看到同一份 Repository Context，也可能因为第一个 Hypothesis 失败而进入多轮 Loop。

Tool Calls 根据平台也可能有额外收费。超长 Context 可能进入不同的价格规则。例如 GPT-5.6 Sol 的 API Request 超过 272,000 Input Tokens 后，整个 Request 会以 2× Input 和 1.5× Output 的费率计算；Cache Write 则是普通 Input 费率的 1.25×。GPT-6 Astra 同样有自己的 Cache-Write 和 Long-Context 规则。Codex 这样的产品界面又可能存在不同的例外。

因此，单纯的模型 List Price 仍然不是一个完整的 Agentic Flow 成本函数。

2026 年 9 月的模型价格

截至 2026 年 9 月 10 日，OpenAI 对 GPT-5.6 Sol 和 GPT-6 Astra 的标准文本 Token 价格如下：

模型	Input / 1M	Cached Input / 1M	Output / 1M	备注
GPT-5.6 Sol	$4.00	$0.40	$20.00	Promotion 价格至少持续到 2026-11-21
GPT-6 Astra	$10.00	$1.00	$50.00	本文日期时的标准价格
Astra / Sol 比例	2.5×	2.5×	2.5×	基于以上 List Price

这些数字来自 OpenAI 当前官方模型页面和 Token Rate Card。OpenAI 明确说明，目前的 Sol 价格是有期限的 Promotion。

因此，从名义 Token 单价看，Astra 确实比 Sol 贵 2.5×。

这个说法是正确的。

但下面这个说法并不能由此推出：

Astra 每解决一个任务贵 2.5 倍。

更不能推出：

Astra 每个 Accepted Change 贵 2.5 倍。

这些具体价格到了 2027 年很可能已经过时。但背后的计算模型仍然成立。

Reasoning 不是固定倍数

像“High Reasoning 要贵三倍”这样的说法尤其需要谨慎。在 OpenAI，同一个模型内部提高 Reasoning Level，并不会自动提高每 Token 的 List Price。当前 Rate Card 对 GPT-5.6 的不同 Reasoning Level 使用同样的费率。

但更多 Reasoning 可能产生更多 Usage。OpenAI 会在 output_tokens_details 中列出 Reasoning Tokens；它们属于 Output Usage。max_output_tokens 也同时包含可见 Output 和 Reasoning Tokens。

所以，经济上更准确的表达是：

Reasoning Effort 不是固定的价格附加项。更高的 Effort 可能带来更多 Compute 和更多 Tokens，而实际增加多少取决于任务、模型和具体 Run。

这不是文字游戏。某个任务上，更高的 Reasoning 可能增加 Token 数量，但如果它因此省掉了后续两个 Agent Runs，总成本反而更低。对于一个非常简单、已经高度 Converged 的任务，同样的额外 Reasoning 可能只是纯粹浪费。

一个 Change 不只是 Implementation

我们用一个刻意简化的例子：传统 Engineering 总共需要八小时，其中真正 Implementation 占三小时。

Coding Agent 恰好把这一部分加速十倍：180 分钟 Implementation 变成 18 分钟。

同时，工作会转移到其他阶段。Agent 生成更多测试并自行迭代，开发者则在 Review 和 Verification 上投入更多。下面这些数字不是实证平均值，只是透明的模型计算：

工作步骤	传统	Agentic
理解 / 分析	60 min	55 min
架构 / 决策	45 min	50 min
Implementation	180 min	18 min
测试 / Iterations	75 min	90 min
Review / Verification	60 min	100 min
Integration / Acceptance	60 min	67 min
总计	480 min	380 min

真正的 Code Production 下降了 90%。但总时间只从八小时降到六小时二十分钟，也就是大约 21%。

这绝对不能算令人失望。

如果一个高成本 Engineering 组织能够稳定获得大约 20% 的生产率提升，这在经济上会非常有吸引力。只是与“10×”放在一起时，它没有那么戏剧化。

而这正是许多 AI 讨论的问题：当真实的系统级收益紧挨着某个单独工作步骤的巨大加速倍数时，它看起来反而“小”。

实证研究与这种谨慎态度是吻合的。在边界清晰的任务里，非常大的加速确实可能出现；而在更复杂的真实工作环境里，效果差异很大，并且沿着生产链往后常常会衰减。

因此，我个人约 20% 的估计也就只是个人估计。它既不证明，也不反驳任何研究。

更贵的模型可能反而更便宜

用当前 OpenAI 的价格，可以把这个问题算得更具体。

假设有一个比较困难的 Change，每个 Agent Run 大约使用 200,000 Input Tokens 和 15,000 Output Tokens。第一个 Run 使用未缓存 Input；对于后续尝试，我们做一个非常强的简化假设：大 Context 可以全部从更便宜的 Cache 中读取。

Sol 需要三次尝试。Astra 在这个例子里一次就达到可接受方案。

人力方面，我们用 $100 / 小时 的 Fully Loaded Cost 作为示例。它同样只是一个计算参数。

指标	GPT-5.6 Sol	GPT-6 Astra
Token 类别 List Price	1×	2.5×
每个 Run 的 Tokens	200k Input + 15k Output	200k Input + 15k Output
Runs 数量	3	1
修正 Loop	2	0
模型成本	$1.86	$2.75
Steering / 修正时间	70 min	25 min
Review / Verification	35 min	20 min
Human Active Time 总计	105 min	45 min
按 $100/h 计算的人力成本	$175.00	$75.00
Accepted	是，第 3 个 Run 后	是，第 1 个 Run 后
Cost per Accepted Change	$176.86	$77.75

这里 Sol 的模型成本由首个 $1.10 的 Run，加上两个大量缓存、各 $0.38 的后续 Run 构成。Astra 的纯 Inference 成本 $2.75，确实更高。

但在总账上，Astra 依然便宜得多，因为假设中的 Human Work 降得更多。

这个模型计算当然不能证明 Astra 普遍更好或更便宜。它只是说明，List Price 不是一个足够的优化变量。

最便宜的模型未必是 Token 单价最低的模型。真正便宜的是：以最低总成本产生一个足够好、经过验证的 Change 的模型。

反例同样重要。如果只是一个标准化 CRUD Endpoint，测试完善、架构规则明确、几乎没有决策空间，那么 Frontier Model 可能完全没有必要。如果一个更便宜的模型能以同样可靠性生成同样的 Change，那么额外 Capability 只是在吞噬 Margin。

因此，Model Routing 不只是质量问题，也是经济控制问题。

模型经济性很快就会过时

过去两年的发展已经足以说明，今天的计算有多快会老化。

下面这张表明确不是 Benchmark 时间序列。Benchmarks、Harnesses、Prompting、Reasoning Budgets、Test-Time Compute，甚至数据集本身都可能发生变化。因此，不能把这些数字连成一条数学上的“Capability 曲线”。

它展示的是另一件事：用于 Coding 和 Agentic Work 的能力可以大幅提升，而 List Price 保持不变，甚至下降。

时间	模型	Input / 1M	Output / 1M	相关 Coding / Agentic 信号
06/2024	Claude 3.5 Sonnet	$3	$15	新 Sonnet 世代，保持原 Mid-Tier 价格
10/2024	Claude 3.5 Sonnet, update	$3	$15	Anthropic 报告 SWE-bench Verified 从 33.4 提升到 49.0%，价格不变
02/2025	Claude 3.7 Sonnet	$3	$15	内部可运行的 489 项 SWE-bench Verified 子集上 63.7%；额外 Test-Time Compute 下 70.3%
05/2025	Claude Sonnet 4	$3	$15	发布 Setup 中 SWE-bench Verified 72.7%
09/2025	Claude Sonnet 4.5	$3	$15	SWE-bench Verified 77.2%，但 Thinking / Prompt Setup 不同
02/2026	Claude Sonnet 4.6	$3	$15	价格不变；早期 Claude Code 测试里相对 4.5 约 70% 偏好
04/2026	GPT-5.5	$5	$30	Terminal-Bench 2.0 为 82.7%
07/2026	GPT-5.6 Sol	当前 $4	当前 $20	Terminal-Bench 2.1 为 88.8%；2026 年 9 月价格为临时优惠
06/2026	Claude Sonnet 5	$2	$10	6 月的 Introductory Price 在 8 月变为永久价格

Anthropic 在 2024 年以 $3/$15 推出 Claude 3.5 Sonnet，并把这个价位维持到了多个后续版本。例如 Claude 3.5 Sonnet 的更新版，在价格不变的情况下，把 Anthropic 报告的 SWE-bench Verified 从 33.4 提高到 49.0%。Claude 3.7、Sonnet 4 和 Sonnet 4.5 同样保持 $3/$15。

但这些 SWE-bench 数字之间的可比性有限。例如 Claude 3.7 只有 500 个任务中的 489 个能够在 Anthropic 基础设施内部运行；High-Compute 结果还用了并行尝试和 Selection Mechanism。Sonnet 4 使用的是简单的双 Tool Setup；Sonnet 4.5 又采用了定义明确的 Thinking Budget 和额外 Prompt Instruction。

到 2026 年，价格变化更加明显：Sonnet 4.6 仍然是 $3/$15。Sonnet 5 在 6 月以 $2/$10 的 Introductory Price 发布，Anthropic 随后在 2026 年 8 月把这个价格改成永久价格。

OpenAI 也不存在简单的“越新越贵”。GPT-5.5 发布时是每百万 Token $5 Input / $30 Output。本文写作日期的 GPT-5.6 Sol 是 $4/$20，只不过这是有限期 Promotion。OpenAI 报告 GPT-5.6 Sol 在 Terminal-Bench 2.1 上是 88.8%，GPT-5.5 是 85.6%。

到了 GPT-6 Astra，Terminal-Bench 已经跳到了 4.0 版本。在那里 OpenAI 报告 Astra 57.9%，Sol 37.3%。这些数字不能和旧发布里的 Terminal-Bench 2.0 或 2.1 连成一条连续历史曲线。对于名称仍保持一致的 DeepSWE v1.1，在同一份当前 OpenAI Evaluation 里，Astra 和 Sol 的差距反而小得多：74.1% 对 72.7%。

真正重要的经济结论是：

Capability 可以显著提升，而 List Price 保持不变，甚至下降。

因此，一个基于某个具体模型“今天”的价格性能比建立起来的 Business Case，本质上只是一个时间截面。

很小的 Capability 提升也可能产生很大的 Agentic 效果

Benchmark 增加几个百分点，有时看起来并不惊人。但在长链条 Agentic Flow 里，局部 Reliability 的小幅提高可能产生更大的最终影响。

我们做一个纯思想实验：一个 Workflow 有十个关键决策。假设每个决策彼此独立，并且都有 90% 的概率正确：

0.9^10 ≈ 35%

如果是 97%：

0.97^10 ≈ 74%

这明确不代表真实 Agents 可以这样进行数学建模。真实决策既不独立，也不具有相同难度。有些错误后来可以修正，有些则会同时影响多个后续步骤。

这个模型只说明一个机制：决策链越长，额外 Reliability 对“整个 Workflow 能否不依赖人工介入而走完”的概率影响就越可能被放大。

这也解释了为什么某些模型世代主观上会让人感觉像“量子跃迁”，即便某个 Benchmark 只提高了一点。并不是所有提升都会表现成单条回答突然好很多。有时真正决定性的差别，只是 Agent 到第七次 Tool Call 时，不再从最初目标上漂走。

Agentic Capability 对模型 Reliability 的相对小幅提升，可能表现出非线性的系统级响应。

也正是在这种情况下，一个名义上更贵的模型可能突然显著减少 Human Active Time。

880 亿 Tokens 的信息量惊人地少

在一次 Quarterly Meeting 上，我目前的雇主曾很自豪地报告：一个季度大约消耗了 880 亿 Tokens。公司大约有 1,000 名员工。

我的第一反应是：听起来非常夸张。

第二个反应更有意思：这个数字到底意味着什么？

是 Input Tokens？Cached Input？Output？Reasoning？Coding Agents？其他 AI Workloads？一遍遍重新载入的大型 Repository Context？高效的自动化 Flow？还是一些昂贵的 Agent Loop 不必要地频繁运行？

用当前 Sol 和 Astra 的 List Price，可以非常直观地看出：裸 Token 数量对成本的说明能力有多差。

880 亿 Tokens 等于 88,000 份“一百万 Tokens”：

假设全部 880 亿 Tokens 都属于……	粗略成本
Sol Cached Input，$0.40 / 1M	$35,200
Sol Input，$4 / 1M	$352,000
Astra Input，$10 / 1M	$880,000
Sol Output，$20 / 1M	$1,760,000
Astra Output，$50 / 1M	$4,400,000

这笔计算使用的是 OpenAI 在 2026 年 9 月 10 日的官方价格。

当然，这些极端情况都不现实。真实 Workload 一定由不同 Token 类型、模型、Caching Rate，以及可能存在的额外 Tool Cost 混合组成。

而这正是这张表有价值的原因。

同样的 880 亿 Tokens，在这些边界情况里对应的成本区间大约从 3.5 万美元到 440 万美元，相差 125 倍。

而且，即便我们知道精确成本，我们仍然不知道这笔使用到底是否值得。

Token Consumption 首先是 Activity Metric，而不是 Productivity Metric。

880 亿 Tokens 可能代表优秀的自动化，也可能代表非常昂贵的循环执行得非常频繁。仅凭这个数字无法区分两者。

当 Usage 变成成功 KPI

很多组织仍然处于 AI 引入的早期阶段。因此，Active AI Users、Agent Runs、生成的代码行数、Tokens Consumed 这样的 KPI 很自然。

这些指标不是没用。它们可以回答 Adoption、基础设施需求和成本走势问题。

但不能把它们与结果本身混为一谈。

Usage
↓
Cost
↓
Verified Outcome
↓
Engineering Value
↓
Business Value

如果 Token Consumption 本身变成成功衡量标准，就会出现一个奇怪激励：一个用一半 Tokens 生成同样 Change 的团队，在 Usage Dashboard 上看起来反而比一个为同样工作烧掉两倍 Inference 的团队“差”。

Goodhart’s Law 在这里非常合适：当一个 Proxy Metric 变成目标，它就可能失去原本的信息价值。

对于 Engineering Dashboard，更有意义的指标可能包括：Successful Agent Runs、每个 Accepted Change 的 Retries、Human Active Time、Review Rework、Defect Escape Rate，或者直接 Cost per Accepted Change，而不是纯粹的 Token 数量。

只有到了这一层，Usage 才开始真正描述生产。

很贵的 Inference 也可能非常经济

读到这里，很容易产生另一个错误印象：本文是不是想说，AI 比看起来更贵？

不是。

即使绝对 Inference 账单看起来吓人，AI 仍然可能非常划算。

假设一个组织有 200 名开发者。作为简单模型，按每人每月 160 小时、每开发者小时 €75 Fully Loaded Cost 计算。

那么每季度理论工时为：

200 名开发者
× 160 小时
× 3 个月
=
96,000 开发者小时

如果真实生产率提升是 10%、20% 或 30%，理论上意味着什么？

Productivity 假设	每季度理论释放的 Capacity	按 €75/h 估值
10%	9,600 h	€720,000
20%	19,200 h	€1,440,000
30%	28,800 h	€2,160,000

这张表同样只是一份模型计算。

释放的 Capacity 不是银行账户里的现金。某些工作少花 20% 时间，并不自动意味着多 20% Features、多 20% Revenue，或者少 20% 员工。Bottleneck 可能在别处。Demand 可能有限。节省的时间也可能部分被消耗掉。

但量级仍然说明：每季度几十万欧元的 Inference 账单，完全不能自动被判定为“太贵”。

如果昂贵的 Inference 能真正提高昂贵人力的生产率，那么它本身可能惊人地便宜。

真正关键的是“真正”。

所以，我们再次回到 Accepted Changes，而不是 Tokens。

Wall Clock 不等于 Human Active Time

Agentic Work 还有另一个特殊之处。

假设 Agent 花了 20 分钟做分析、Implementation 和 Tests。

这 20 分钟都是开发者成本吗？

不一定。

如果我一直盯着屏幕等它结束，那么 Agent Time 和我被占用的时间几乎一致。如果我可以同时准备一个架构决策、澄清 Requirements 或者读 Documentation，就会产生有效的时间重叠。

我现在经常把这样的阶段用于 Documentation、架构工作，或者进一步学习 AI。对我而言，这是 Agentic Work 实际生产率收益的一部分。

因此，区分三种时间概念很有价值。

Agent Time：机器独立工作的时间。

Human Active Time：人必须主动决策、规划、Review、修正或提供 Context 的时间。

Coordination Time：Human Work 的一部分，包括 Handoff、问题、Context Switching、多 Agent 同步，以及重新构建自己的 Mental Model。

Wall Clock
├── Agent Time
└── Human Active Time
    └── 其中：Coordination Time

Agent Time 与 Human Active Time 可以重叠。

因此，这些类别不能简单相加。在 Agent Time 运行期间，人完全可以同时在同一活动或另一活动上进行 Human Work。

所以，经济上真正有意思的并不只是 Agent Runtime。

Agentic Work 不仅可以缩短任务持续时间，也可以在这段持续时间里释放人类注意力。

但只有当这种注意力真正流向有价值的工作、学习、规划或其他生产活动时，它才具有经济价值。

技术并行不等于人类并行

多个 Agents 并行运行，一开始看起来像完美的 Scale Strategy。

一个 Agent 实现 Feature，第二个同时编写 E2E Tests，第三个也许已经开始分析下一个 Change。

技术上非常漂亮。

认知上却很快会变得难受。

我对自己有一个相对简单的原则：“专注一件事，把它做好。” 这不是普遍规律，只是我处理复杂 Engineering 工作时最可靠的方式。

认知科学至少支持这个机制。Task Switching 研究区分稳定 Task Focus 与在任务间切换时需要的 Cognitive Flexibility。关于 Interruption 的 Reviews也显示，包括恢复时间和主要任务准确性在内的一些指标会受到可测量影响。这并不等于“人不能 Multitask”。它只是意味着切换和恢复并不是免费的。

对于 Agentic Work，这一点非常关键。

机器可以并行运行三个 Workstreams，但开发者可能必须同时在脑中保持三个不同的 System State、Solution Space 和未决问题。

Agentic Parallelism 在技术上很便宜。Human Parallelism 在认知上不是免费的。

因此，可有效并行运行的 Agent 数量，并不会随着 Compute 线性增长。

同一个 Solution Space 内的并行更有效

以我的经验，并行工作在所有活动都围绕同一个问题时明显更有效。

例如：

Feature
├ Implementation Agent
├ E2E Agent
├ Review Agent
└ Human：Architecture 与 Acceptance

所有参与者都处于同一个业务 Context 里。Implementation Agent 做出一个决定，Review Agent 就检查这个决定。E2E Agent 测试的是同一个 Flow。我自己只需要在脑中保持一个 System Model。

如果三个 Agents 同时修改三个业务上毫不相关的 Features，情况会困难得多。技术 Parallelism 可能继续上升，但 Human Active Time 和 Coordination Time 可能增长得更快。

由此可以提出一个实践 Hypothesis：

Agentic Parallelism 特别有价值的场景，是机器处理同一个问题的不同部分，而不是强迫人类同时维护多个开放的 System Models。

所以，最佳 Agent 数量并不是纯粹的基础设施问题。它还依赖人类能否有效协调并验证由此产生的变化。

真正的 Invest 叫 Agent Infrastructure

如果只从持续 Token Cost 来看 Agentic Work，就会漏掉另一个巨大的成本块：建设一个让 Agents 能够可靠工作的环境。

我现在有意识地尽可能少直接干预 Agent 的具体 Implementation。我的目标并不是手动去“救”每一个失败的 Agent Run。

我更愿意投资那些能让下一次 Run 变得更好的结构：

• Agent Files 和 Skills，
• 清晰的架构规则与 Module Boundaries，
• 可理解的 Slicing，
• 稳定的 Contracts，
• Automated Tests，
• 可执行的 Architecture / Quality Checks，
• 清晰的 Review Rules，
• 一致的 Naming 和 Project Structure。

于是，工作重心发生了变化。

我直接写 Implementation Code 的时间减少，更多时间投入 Architecture、Solution Design、Constraints、Inspiration、Review 和 Agent Enablement。甚至一些从来不是我喜欢做的事情——例如把 Ticket 写得干净、完整——AI 往往也能比我临时手写得更结构化。

我并不声称自己已经完美掌握 Agentic Work。恰恰相反：我当前的一部分工作，正是在探索一个设计良好的 Flow 到底能推进到什么程度。

但有一个变化越来越明显：长期来看，最重要的 Prompt 也许不是生成下一个 Change 的那个 Prompt，而是那套能够可靠地产生一百个类似 Changes 的 Infrastructure。

代码里的最大无聊程度

对我来说，可重复 Agent Work 的目标并不是最大 Creativity。

我想要尽可能多的无聊。

类似问题应该产生结构上类似的解决方案。新的 Capability 应该出现在预期位置。API Access 应该沿用上一个的规则。State Management 不应该每个 Feature 都重新发明一次。

这对人类团队本来就有价值。到了 Agents 时代，它在经济上更加有意思。

因为 Repeatability 不只减少 Implementation Time。

它也会减少 Verification Cost。

如果我大致知道一个 Change 应该具有什么结构，我就能更快读懂它。Tests 可以更有针对性。Architecture Rules 可以机械检查。Surprises 变少。

可重复性不仅降低 Implementation Cost，也降低 Verification Cost。

这会改变 Agentic Work 的成本函数。

做一个极度简化的计算：一次性投入 €10,000，用于 Agent Instructions、Architecture Rules、Test Infrastructure 和 Review Automation。如果这些投入分摊到 20 个 Accepted Changes，每个 Change 是 €500 的前置成本；50 个 Changes 是 €200；100 个 Changes 是 €100。

Agent Files
+ Skills
+ Architecture Rules
+ Test Infrastructure
+ Review Setup
=
高前置成本

          ↓

20 Changes → €500 / Change
50 Changes → €200 / Change
100 Changes → €100 / Change

这仍然只是数字例子。但机制符合经典 Fixed-Cost Economics：前期投入很贵，而可重复生产的 Marginal Cost 之后可以下降。

Agentic Work 在一次性的 Prompt Work 变成可复用的生产逻辑时，经济价值会特别明显。

从长期看，我认为这里的潜力远大于“某一个 Prompt 写得够不够聪明”。

Local Models 有不同的成本函数

Cloud Models 有一个很舒服的特点：Usage 基本对应 Variable Cost。Tokens 多处理十倍，账单通常也相应提高。

Local Inference 改变了成本结构。

不再主要是持续 Provider Price，而是 Hardware Investment、Depreciation、Electricity、Maintenance、Administration 和 Utilization Risk。

作为 2026 年 9 月的具体例子，可以看 NVIDIA DGX Spark 上的 Qwen3.8-27B。官方 Qwen Model 以 Apache 2.0 发布。NVIDIA 对 DGX Spark 的规格包括 128 GB Unified Memory、273 GB/s Memory Bandwidth、GB10 的 140W TDP 和 240W Power Supply。当前 DGX Spark 的美国 List Price 为 $4,699。

截至本文日期，我找不到足够可靠的 Manufacturer Benchmark，可以把 Qwen3.8-27B 在这台机器上的速度当作通用 Throughput。一个明确标为 Community Measurement 的结果显示：在 NVFP4+MTP、Single-Stream Decode 配置下，大约为 25.1 Tokens/s。这不是 NVIDIA 或 Qwen 的保证，实际结果会随着 Runtime、Quantization、Context Length 和 Configuration 显著变化。

不过，它仍然足够构造一份透明的模型计算。

假设：

Hardware:              $4,699
Depreciation:          3 年
Working days:          220 / 年
Decode:                25.1 Output-Tokens/s
Electricity:           $0.30 / kWh
Power in the model:    240 W

这里的 240W 是 Power Supply 的额定值，被有意作为保守计算假设，而不是测得的持续 Inference 功耗。Administration、Maintenance、Downtime、Financing、Prompt Processing 和 Concurrent Users 都没有计算在内。这份账只看一个粗略的 Output-Token-Equivalent Capacity。因此，它不是与 Cloud Output Tariff 的直接 Full-Cost Comparison，而是一个 Local Hardware 的 Utilization Calculation。

场景	高利用率	低利用率
Active Inference	8 h / 工作日	1 h / 工作日
按 25.1 tok/s 的年 Output Capacity	约 159M Tokens	约 19.9M Tokens
3 年 Output Capacity	约 477M	约 59.6M
Hardware Depreciation / 1M Output Tokens	约 $9.85	约 $78.79
模型假设下 Electricity / 1M	约 $0.80	约 $0.80
Hardware + Electricity / 1M	约 $10.65	约 $79.59

高利用率时，Local Inference 突然显得非常便宜。低利用率时，Depreciation 主导整个计算。

这就是关键：

Local Inference 会把一部分 Variable Cloud Cost 换成 Fixed Cost 和 Utilization Risk。

本文明确不讨论生态效率。Energy Consumption 只作为经营成本项进入这里的计算。

Local 并不会自动更便宜

上一张表也可能导致另一个错误结论。

如果 Qwen 本地算下来每百万 Output Tokens 大约 $11，而 Astra Cloud 是 $50，那么 Local 不是自动就更便宜了吗？

不是。

一个 Qwen Token 和一个 Astra Token，在经济上不是同一种产品。

如果较小的 Local Model 在相同 Change 上更容易 Drift，需要更多 Retries，生成更弱的 Tests，或者占用更多 Human Active Time，那么名义上的 Token 优势可能完全消失。

而且简化的 Local 计算还没有包含 Administration、Upgrades、Monitoring、Downtime、Runtime Tuning，以及闲置 Hardware 的 Opportunity Cost。

所以，这里再次回到同一个指标：

Cost per Accepted Change。

如果 Utilization 高且可预测，Local 可以极具吸引力。对于简单或高度标准化的 Task Classes，小模型可能在经济上最理想。

对于复杂、低频任务，Frontier Model 即便 Token 单价高很多，仍可能总成本更低。

因此，有意思的架构也许并不是“Cloud 还是 Local”，而是一个 Portfolio：

Routine / 高频
→ 更便宜或 Local Model

复杂 / 高不确定性
→ Frontier Model

Critical
→ 额外 Verification

Local 作为战略选项

除了纯 Inference 账之外，Local Models 还可能拥有另外两类经济价值。

第一类是 Confidentiality。Local Model 可以移除最核心的外部 Model Trust Boundary。但这并不自动意味着整个 Agentic Flow 都是 Local 或 Secure 的。

Agent 仍然可能把数据发送到 Web Services、MCP Servers、Package Managers、Telemetry Systems 或其他 External APIs。

因此，Local Model 和 Local Workflow 是两个不同的命题。

第二类价值是 Strategic Optionality。如果一个组织能够为某些 Task Classes 运行 Local Alternative，那么在 Provider Pricing、Quotas 或 Product Conditions 发生变化时，就拥有一条 Exit Option。

即便这条路径今天并不是最便宜的，它本身也可能有价值。

不显眼的 Workflow Lock-in

这里藏着一个略带讽刺意味的发展。

一开始，团队可能会说：

AI 订阅每月大约 25 欧元。几乎可以忽略。

几年之后，Architecture、Delivery Processes、Team Sizes、Review Flows 和 Throughput Expectations 可能都已经围绕持续 Inference 进行了设计。

于是，计算可能变成：

现在贵了很多——但我们的生产 Flow 已经离不开它。

这个机制不需要假设 Provider 有任何恶意。

它只是一个正常的经济现象：某种技术被嵌入生产流程越深，Switching Cost 就可能越高。Agent Files、Tooling、Prompt Caches、APIs、Evaluations 和组织流程还可能进一步围绕特定模型进行优化。

Agentic Work 嵌入生产系统越深，实际 Switching Cost 就可能越高。

因此，长期真正有意思的数字也许不只是今天的 Token Price，还包括一个已经依赖持续 Inference 的组织，其需求对价格到底还有多大弹性。

Consumer Subscription 会制造价格错觉

Consumer Subscription 对 Enterprise Cost Calculation 的帮助也非常有限。

ChatGPT Plus 在美国仍然是每月 $20；本地价格可能因税费和结算方式不同。OpenAI 现在还提供 $100 和 $200 的 Pro Tier。按照当前产品信息，Pro $100 提供相当于 Plus 5× 的使用量，Pro $200 为 20×。API Usage 单独计费。

但由此无法推出一个保证的“API 等值”。

一个用户每月可能几乎不使用 Inference。Heavy User 则可能产生非常高的 Usage。Rate Limits、Product Quotas、Caching、不同模型，以及内部 Routing Mechanisms 都会进一步影响成本。

公开的 API List Price，也不是 Provider 内部生产 Inference 的 Marginal Cost。

所以，一个合理的假设是：Subscription Product 可以通过 Portfolio Economics 成立——有些用户按 API List Price 换算出的使用价值远高于订阅费，而另一些用户几乎不用满 Quota；Caching 和 Rate Limits 又进一步影响真实成本。

这不代表我们知道 Provider 的内部 Margin。

对于组织而言，结论更简单：Consumer Subscription 不是一个可靠的生产系统成本模型。

从 Accepted Change 到组织

到这里为止，观察角度一直是运营性的。

模型多少钱？需要多少 Runs？Human Active Time 还剩多少？Review Effort 多大？最终能产生多少 Accepted Changes？

这已经足以描述相当大一部分短期 Agentic Economics。

但还有第二张资产负债表。

如果 AI 长期承担越来越多的 Execution，不只是单个 Change 的成本结构会改变。它还可能改变人类如何积累经验。

于是，我们进入一个变化更慢的经济变量：Human Capital。

Entry-Level Hiring 的确承压——但不只是 AI 的原因

Junior Developers 的问题如今已经很难和 AI 讨论完全分离。

但必须非常小心地区分 Observation 与 Causality。

在美国，2026 年 8 月修订的 Stanford Working Paper “Canaries in the Coal Mine?” 使用覆盖数百万员工的 ADP Payroll Administrative Data，显示出一个值得注意的关联。对于 22 至 25 岁、处在高度 AI-Exposed Occupations 的年轻人，根据论文使用的比较方法，其 Employment 大约比同龄、较低 AI Exposure 的人所对应的轨迹低 19%。作者没有在 Experienced Workers 中发现同样的差距。尤其重要的是：根据研究，这种调整主要发生在减少 Hiring，而不是增加 Separations。下降也更集中在那些现实 AI 使用更偏向 Substitution、而非 Complementarity 的任务中。

这是一个很强的 Descriptive Signal，但明确不是 AI 单因果效应的因果证明。作者本人在早期版本受到批评后重新分析，也承认早期的一部分下降很可能来自其他原因；使用更严格 Controls 后，时间上的关联到 2024 年之后才更加清晰。

其他数据也要求我们谨慎。LinkedIn Economic Graph 在 2026 年 2 月报告，Software Engineering 的 Entry-Level Hiring 与整个 Technology Sector 和美国 Labor Market 的走势相似。因此，LinkedIn 当时主要把 SWE 的下降解释为更广泛的宏观经济疲软，而不是一个孤立 AI 效应。同时，根据这些数据，2023 和 2024 年美国 Computer Science 毕业生中，有 55% 的第一份全职工作并不在传统 Software Engineering Roles，而 2016 年这一比例是 49%。

两件事完全可以同时为真：Tech Labor Market 本身可能处于周期性疲弱，而 AI 又在这个弱市场内进一步给某些 Entry-Level Tasks 施压。

德国还有额外的周期性 IT 问题

不能把美国数据直接套到德国。

德国 Bundesagentur für Arbeit 对 2025 年 ICT Labor Market 的描述显示，需求明显变弱。全年平均登记的 ICT Vacancies 约为 13,000 个，比上一年少 22%，也是自 2015 年以来最低水平。职业特定的 Unemployment Rate 从 3.7% 上升到 4.5%。同时，仍然有约 115 万人在 ICT 职业中进行 Social-Security-Contribution Employment，比前一年增加 2%。

因此，图景不是“IT 正在崩溃”。

更准确地说：长期 Employment 仍然增长，但短期 New Hiring 和 Open Positions 显著变弱，需求更多向高资质 Specialists 和 Experts 偏移。

仅凭这些数据无法推出 AI Effect。

但对 Juniors 而言，这个机制依然重要：如果企业在弱市场里本来就招得更少，同时又通过 Senior-plus-Agent Configuration 提高了生产率，那么某个 Entry-Level Opening 根本不被创建，就会在经济上变得更容易。

劳动力市场可以从底部收缩，而不出现大规模 Layoffs

公共 AI Labor Market 讨论经常寻找戏剧化事件。

哪个职业被替代了？多少人被裁员了？大规模自动化浪潮在哪里？

也许部分影响要安静得多。

一个从未被发布的职位，不会出现在任何 Layoff Statistic 里。

一个因为现有团队生产力提高而从未组建的 Junior Team，也不会产生任何 Termination Letter。

这正是 Stanford 关于 Hiring 而不是 Separations 的发现如此有意思的原因。

因此，Hypothesis 不是：

AI 突然摧毁 Software Developer 这个职业。

而是：

一部分调整可能通过“某些进入职业的机会根本不再产生”来发生。

对于单个企业，这在短期完全可能是理性的。

但长期来看，它会引出另一个经济问题。

Senior + Agent 在短期是非常理性的组合

经验丰富的开发者已经拥有一个建立起来的 Mental Model。

他们更早发现 Requirements 模糊。知道典型 Failure Patterns。能够区分漂亮 Diff 和 Robust Solution。知道哪里需要额外 Tests，也知道什么时候某个提议架构的复杂度完全不成比例。

强大的 Agent 恰好为这样的开发者补上快速 Execution。

于是产生一个极具吸引力的组合：

经验
+
高 Generation Speed
+
Automated Tests
+
快速 Iterations
=
高短期 Output

从企业角度，“那我为什么还要改招一个 Junior？”这个问题并不荒唐。

Junior 需要 Onboarding、Mentoring 和 Review。而许多过去 Entry-Level 可以直接贡献生产力的任务——边界清晰的小实现、Standard CRUD、Tests、简单 Refactorings——恰好又是 Coding Agents 进步特别快的领域。

这里不需要任何道德评价。

短期看，Senior + Agent 完全可能只是更具经济吸引力的生产单元。

问题只在于：如果我们只做短期计算。

Junior Task 生产两样东西

一个 Junior Task 至少有两个 Outputs。

Junior Task
├ 今天的软件
└ 明天的经验

第一部分显而易见。它会产生 Endpoint、Form、Test、Migration 或 Bugfix。

第二部分几乎不会出现在任何 Delivery Metric 里。

Junior 在过程中学会这个系统是怎么工作的。

他犯错，然后理解为什么错。他在 Review 中学会为什么一个看似优雅的 Abstraction 长期会有问题。他 Debug 一个 Production Failure。他看到一个业务例外是如何改变技术 Architecture 的。随着时间推移，他开始承担更大的系统范围和更多 Responsibility。

Junior Task 不只是生产软件，它也在生产经验。

如果 AI 能更高效地承担第一种生产过程，短期当然非常好。

但如果第二种生产过程也同时消失，就会产生一笔 Token 账里根本看不到的长期成本。

经验就是 Human Capital

经验不能完全靠阅读 Documentation 获得。

它来自反复面对真实系统：

Implement
→ 犯错
→ Debug
→ 接受 Review
→ 经历 Production
→ 做决策
→ 承担 Responsibility
→ 建立 System Understanding

这并不意味着 Juniors 必须手写 CRUD 十年，才有资格成为“真正开发者”。

那样的想法反而是在反对进步。

如果 AI 接管 Routine Work，Training 没必要被人为保持低效。真正有意思的问题是：

如果越来越多过去用于练习的空间被自动化，人类要如何建立 Systemic Engineering Judgment？

Agents 甚至可能帮助我们做到这一点。它们可以解释 Code、展示 Alternatives、模拟 Reviews、加速 Learning Loops。

但这不会因为 Agent 把整个任务完全接管就自动发生。

企业可以买经验，市场必须创造经验

对我而言，这是 Agentic Economics 最值得思考的长期问题之一。

单个企业可以说：

我们不需要 Juniors。我们直接招聘有经验的 Developers。

这可以完全理性。

下一家公司也可以这么决定。

再下一家也是。

最终会出现 Coordination Problem。

企业可以购买经验。劳动力市场只能创造经验。

企业招聘一个 Senior，实际上是在购买多年投入的结果：Education、Mentoring、Projects、Mistakes、Reviews 和 Responsibility——而这些投入经常由别的企业承担。

如果许多组织同时减少 Junior Hiring、减少 Mid-Level Development，只想采购“现成经验”，那么长期来看，劳动力市场可能会生产更少的经验。

这明确只是一个假设，不是预测 2036 年会突然没有 Seniors。

市场会反应。Training Models 会变化。新的 Roles 会出现。AI 自己也可以成为 Learning Tool。

但经济问题仍然存在：

只想购买成品经验的人，必须依赖别人先为这份经验付过钱。

这就是经典 Human-Capital Economics，只是处在新的技术条件下。

Fluctuation 不会让能力建设变得没有意义

反对 Junior Investment 的一个常见论点是：员工反正会离开企业。

这是真的，但仍然不是一个有说服力的反对理由。

作为一个粗略参考，美国 Bureau of Labor Statistics 在 2024 年 1 月对 “Computer and mathematical occupations” 给出的当前雇主 Median Tenure 为 4.3 年。这不是全球 Software Developer Turnover Rate，也无法说明 Remote vs. Office。它只说明，多年 Tenure 并不罕见，但也不能期待终身绑定。

工作条件也会影响 Retention。一项发表在 Nature 的 Peer-Reviewed RCT，覆盖一家中国科技公司的 1,612 名员工，发现每周两天 Work From Home 可以把 Resignation Rate 降低大约三分之一，而 Performance 和 Promotion 没有可测量的恶化。对于这个具体 Setting，这是一个很强的结果，但仍然不是“Remote 员工一定多留 X 年”的普遍公式。

人会换公司。

但在他们任职期间，Domain Knowledge、System Knowledge、Relationships 和 Productivity 仍然会积累。

Fluctuation 不是反对能力建设的理由。它恰恰说明组织必须持续再生产 Capability。

一家只从外部购买经验的公司，会越来越依赖一个自己并没有参与建设 Supply Side 的市场。

培养 Nachwuchs 是投资，不是慈善

所以，Junior 问题也不应该主要以道德方式讨论。

“企业有社会责任招聘 Juniors”是另一个论点。

单从经济角度，下面这一点已经足够：

培养 Nachwuchs 是对 Future Capability 的投资。

这种投资会产生 Company-Specific Knowledge、Domain Understanding、Technical Succession、Team Relationships，以及内部 Responsibility Pipeline。

当然，一个培养出来的员工也可能离职。

Database 也可以被 Migration，Server 也会 Depreciate，Platform 也会被替换。任何投资都不保证永续价值。

真正的问题是：长期 Expected Value 是否高于 Invest。

Agentic Work 恰好改变了这笔计算：简单 Junior Tasks 的直接 Production Value 可能下降，但它们的 Training Value 仍然存在。

因此，Training 必须比过去更显式地成为 Production System 的一部分。

培训必须改变

面对 AI，仅仅呼吁“更多传统 Coding”没有太大意义。

如果 Agents 可以可靠地生成代码，人就应该学会在这个现实中高效工作。

但这也意味着不只是再加一门“Prompt Engineering”。

关于 GenAI 在 Programming Education 中使用的 Systematic Reviews 呈现出混合结果。AI 可以支持 Learning Performance、Feedback 和 Problem Solving。但与此同时，也会出现 Overreliance、错误输出，以及不同学习者对生成结果进行 Verification 能力差异带来的风险。2025 年一篇包含 40 项实证研究的 Review 因此强调，有意识的 Didactic Integration 和合适的 Assessments 很重要。2026 年 9 月一篇覆盖 76 项实证研究的 Heliyon Review 得出了类似结论：AI 尤其在与 Scaffolding、Process-Oriented Feedback 和 Human Judgment 结合时更有帮助。

对于 Software Engineering，这可能意味着 Training 要更加聚焦完整 Production Flow 中真正需要的能力：Problem Understanding、Requirements、System Models、Architecture、Debugging、Review、Trade-offs、Security Awareness、Verification 和 End-to-End Responsibility。

Coding 不会消失。

无法阅读 Code 的人，很难做好 Review。从未经历“为什么某种 Implementation 会失败”的人，也缺少建立 Engineering Judgment 的基础。

但各部分的权重可以变化。

我在私人环境里也能看到这种 Gap。一个家庭成员曾在 Semester Project 中因为 Software Architecture Structure 获得非常积极的评价。但构建这种结构所需要的架构理解，并不是主要来自课程本身，而是在很大程度上来自平时关于架构的非正式交流。

这只是个人 Anecdote，并不能证明任何具体大学课程质量。

它对我而言只是说明了一个问题：当 Technical Execution 越来越容易获得时，我们究竟有多系统地在教人识别并设计好系统？

从 Specialist 到 End-to-End Understanding

Agentic Work 一个可能的正面发展是：开发者能够再次沿完整 Flow 工作得更广。

DB
→ Service
→ API
→ Client
→ View

这并不意味着每个 Frontend Developer 突然都必须成为 Database、Backend、Networking、Security 和 UX Specialist。

Agents 可以承担一部分技术 Execution。

更重要的会变成 Meta-Model。

Frontend Developer 也许不需要像 Backend Specialist 一样，亲自把 CQRS-Oriented 或 Hexagonal Microservice 写到同样深度。但如果他和 Agent 一起工作，他至少应该理解各 Layer 的 Responsibility、Domain Logic 应该放在哪里、Contract 如何运作，以及生成出来的代码是否在结构上 Plausible。

反向同样成立。

Agentic Work 可以扩大 End-to-End Responsibility，而不需要消灭专家知识。

尤其是 Security、Cryptography 或高度 Critical Domain，完全不适合“Generalist 只要有足够 AI Support 就可以替代所有深度”的想象。

Agentic Work 可以拓宽技术 Execution，但不会让 Deep Expertise 失去价值。

也许未来强团队恰恰由两类人组成：拥有广泛 System Model 的人，以及在经济或安全上真正需要深度的地方提供 Specialist Depth 的人。

Software Engineering 正在移动重心

我目前有意识地尽量少亲自写代码。不是因为我认为 Coding 没价值，而是因为我想知道，一个设计良好的 Agentic Flow 到底可以走多远。

这已经明显改变了我的工作。投入 Direct Code Production 的时间减少，更多时间进入 Architecture、Solution Design、Constraints、Reviews、Agent Infrastructure 和 System Understanding。我不把这看成退出 Software Engineering，更像是在 Software Engineering 内部移动重心。

Agent 也许实现了 Method。我越来越关注的是：让它最好一开始就只能在一个“有较高概率产生合理方案”的空间中工作。这包括清晰的 Module Boundaries、Tests、Architecture Rules 和 Mechanical Checks。但也包括判断能力：什么时候一个自动生成的 Solution 虽然全部 Build Green，却依然选择了错误 Abstraction。

我现在认为 Agentic Work 是一个极其强大的 Tool。同时，我也不会声称自己已经完美掌握它。恰恰因为如此，两种工作方式的差异越来越明显：把 AI 当成更快的 Autocomplete 是一回事；构建一个让 Agents 可以自主分析、Implementation、Testing 和 Reviewing 的 Engineering System，是完全另一回事。第二种方式需要明显更多的前置投入。但它也产生完全不同的成本结构。

两张经济资产负债表

最终，我们得到两张彼此独立、却相互连接的经济账。

第一张是运营性的。

它问：

一个经过验证、可以接受的 Change 到底多少钱？

这个计算里需要包含 Model Price、Input / Output、Caching、Reasoning、Tool Calls、Failed Runs、Retries、Tests、Review、Human Active Time 和 Coordination Time。

它的终点是：

Cost per Accepted Change

第二张账是战略性的。

它问：

完成这个 Change 之后，组织还拥有什么 Capability？又在为未来建设什么 Capability？

这里要计算 Agent Infrastructure、System Understanding、Domain Knowledge、Junior Development、Expert Knowledge，以及持续再生产 Capability 的能力。

第二张账并不会让第一张账变得不重要。

企业短期必须经济运作。一个 Agentic Flow 如果不能创造可测量价值，不会因为有人声称它“长期战略重要”就自动合理。

反过来，一张 Quarterly Calculation 如果把每一个消失的 Junior Task 都算作纯 Efficiency Gain，同时把 Future Experience Building 的价值记为零，也一样是不完整的。

Agentic Work 真正有意思的经济学，恰好就在这两个时间尺度之间。

Token
↓
Agent Run
↓
Successful Run
↓
Accepted Change
↓
Engineering Capability
↓
Business Value
↓
Future Capability

模型还会继续变便宜、变贵、然后再变便宜。Capability 会继续提高。有些任务会接近完全自动化。有些任务则会表现出惊人的抗自动化能力。新的工作方式会出现；今天关于 Token Price 的某些争论，几年后回头看，可能就像过去争论每 GB Cloud Storage 多少钱一样遥远。

但经济机制依然存在。

Code Generation 只是一个 Production Step。

Token Consumption 只是一个 Activity Measure。

Inference Cost 只是一个 Cost Item。

Accepted Change 还不是 Business Value。

而短期 Productivity 也不是 Engineering Organization 唯一需要生产的 Capability。

Agentic Work 可以非常经济。我的个人经验明确说明，即使今天的系统已经能带来显著的生产率提升。同时，实证研究也表明，实际幅度高度依赖 Context，而且局部非常大的加速，一旦沿着完整 Production System 计算，可能会显著缩小。

因此，正确结论既不是：

AI 会让 Software Development 极其便宜。

也不是：

AI 其实太贵了。

更有意思、更冷静的表达是：

Agentic Work 的经济性，只有放在 Model Cost、Verification、Human Attention、Reusable Infrastructure 与 Long-Term Capability Building 的完整系统中才会真正出现。

运营层面，我们应该问：

一个经过验证、可以接受的 Change 到底花了我们多少钱？

战略层面，还应该再问：

在这个过程中，我们建设了什么 Capability？又可能拆掉了什么 Capability？

Code 正在变便宜。Software Engineering 并不会自动同步变便宜。

如果想真正理解 Agentic Work 的经济学，就必须把账算到 Token Price 之外。

Token 会出现在账单上。真正的价值——以及某些长期成本——出现在别的地方。

来源与说明

本文中的具体价格和产品信息，是 2026 年 9 月 10 日 的时间截面。模型价格、产品名称、Usage Limits 和 Benchmarks 变化尤其快。因此，即便未来某些数字已经过时，这里的经济计算模型仍应保持可读和可复用。

OpenAI – ChatGPT Rate Card / Token-Based Pricing。
GPT-5.6 Sol、GPT-6 Astra 等模型的当前价格，以及 Long Context、Fast Mode 与区域处理相关说明。
https://help.openai.com/en/articles/20001415

OpenAI – GPT-5.6 Sol。
模型价格、Promotion Rate、Context Window、当前 Coding Evaluations，以及效率相关说明。
https://developers.openai.com/api/docs/models/gpt-5.6-sol
https://openai.com/index/gpt-5-6/

OpenAI – GPT-6 Astra。
当前价格，以及 Coding / Agentic Evaluations。注意：Terminal-Bench 4.0 不能被视为旧 Terminal-Bench 版本的直接历史延续。
https://developers.openai.com/api/docs/models/gpt-6-astra
https://openai.com/index/gpt-6-astra/

OpenAI – Understanding and Counting Tokens。
Reasoning Tokens 不以可见答案文字出现，但会计入 Output Usage，并按 Output Tokens 计费。
https://help.openai.com/en/articles/4936856-w

Anthropic – Claude 3.5 Sonnet、Claude 3.7 Sonnet、Sonnet 4.5、Sonnet 4.6 和 Sonnet 5。
历史价格与 Coding Evaluations 的 Primary Sources。不同 SWE-bench 结果在 Harness、Prompting、Thinking Budget 与 Test-Time Compute 上存在差异，因此本文不会把它们视为统一的时间序列。
https://www.anthropic.com/news/3-5-models-and-computer-use
https://www.anthropic.com/news/claude-3-7-sonnet
https://www.anthropic.com/news/claude-sonnet-4-5
https://www.anthropic.com/news/claude-sonnet-4-6
https://www.anthropic.com/news/claude-sonnet-5

Peng et al. – “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot”。
针对一个边界清晰的 JavaScript Task 的随机实验；Copilot 组完成任务快 55.8%。
https://arxiv.org/abs/2302.06590

Cui et al. – “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers”。
三项随机现场实验，总共 4,867 名开发者；合并估计显示完成任务增加 26.08%。2026 年发表于 Management Science。
https://doi.org/10.1287/mnsc.2025.00535

Demirer, Musolff, Yang – “Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools”。
NBER Working Paper 35275，2026 年 9 月修订。当前版本使用超过 50 万 GitHub 开发者的数据，对 Autonomous Coding Agents 报告了从 Commit-Level 到真正 Releases 的强烈效果衰减。Working Paper，不是最终因果共识。
https://www.nber.org/papers/w35275

METR – Developer Productivity Studies。
2025 年早期 RCT 覆盖 16 名经验丰富的开源开发者、246 个 Tasks，发现平均慢 19%。METR 现在自己把这个结果称为历史快照。2026 年后续研究更偏向加速，但 Selection 和 Measurement 问题意味着无法可靠给出精确效果。
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
https://metr.org/blog/2026-02-24-uplift-update/

Stanford Digital Economy Lab – “Canaries in the Coal Mine?”。
2026 年 8 月修订版，基于 ADP Payroll Data。22 至 25 岁、处于高度 AI-Exposed Occupations 的年轻人，相比低 Exposure Peers，Employment 明显更低；差距主要通过更低 Hiring 形成。作者明确把结果描述为 Descriptive Early Indicators，而不是 AI 的 Causal Estimate。
https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/

LinkedIn Economic Graph – U.S. Software Engineer Talent Landscape / February 2026。
用于说明美国 SWE Hiring 的疲弱，以及 CS Graduates 直接进入传统 Software Engineering Roles 的 Pipeline 变弱。
https://economicgraph.linkedin.com/content/dam/me/economicgraph/en-us/PDF/us-software-engineer-talent-landscape-2026.pdf

德国 Bundesagentur für Arbeit – 2025 ICT Labor Market。
全年平均约 13,000 个登记 ICT Vacancies，比上一年少 22%；Unemployment Rate 4.5%；同时仍约有 115 万人在 ICT Occupations 中进行 Social-Security-Contribution Employment。
https://www.arbeitsagentur.de/presse/2026-24-arbeitsmarkt-in-der-informations-und-kommunikationstechnik-ikt-im-spannungsfeld-konjunkturelle-schwaeche-trifft-auf-strukturellen-wandel

U.S. Bureau of Labor Statistics – Employee Tenure 2024。
“Computer and mathematical occupations” 在当前 Employer 的 Median Tenure 为 4.3 年；并不是 Software-Developer-Specific 或 Remote-Tenure Metric。
https://www.bls.gov/news.release/tenure.t06.htm

Bloom et al. – “Hybrid working from home improves retention without damaging performance”。
针对 Trip.com 1,612 名员工的随机实验；每周两天居家办公让实验中的 Resignation Rate 降低约三分之一。
https://doi.org/10.1038/s41586-024-07500-2

Nathaniel et al. – “Literature Review on the Integration of Generative AI in Programming Education”。
关于 GenAI 融入 Programming Education 的 40 项实证研究的 Systematic Review。
https://doi.org/10.1007/s40593-025-00524-3

“Artificial intelligence in programming education: A systematic review …”, Heliyon 2026。
关于 AI 在 Programming Education 中使用的 76 项实证研究的 Systematic Review。
https://doi.org/10.1016/j.heliyon.2026.e45361

Qwen – Qwen3.8-27B。
官方 Model Weights、Apache 2.0 License 与模型信息。
https://huggingface.co/Qwen/Qwen3.8-27B

NVIDIA – DGX Spark。
官方 Hardware Specifications：128 GB Unified Memory、273 GB/s Memory Bandwidth、140 W GB10 TDP、240 W Power Supply。NVIDIA 在 2026 年 2 月把 MSRP 提高到 $4,699。
https://www.nvidia.com/en-us/products/workstations/dgx-spark/
https://forums.developer.nvidia.com/t/2-23-2026-price-change-announcement/361713

Qwen3.8-27B on DGX Spark – Community Benchmark。
模型计算中使用的 25.1 tok/s，是明确标为 Community Measurement 的 NVFP4 + MTP 结果，并非 Manufacturer Guarantee。不同 Runtime Configuration 可能显著不同。
https://axforge.ai/benchmarks/qwen-3-8-dgx-spark/

OpenAI – ChatGPT Pro tiers。
当前美国 Product Tiers：Pro $100 的 Usage 为 Plus 的 5×，Pro $200 为 20×。这些 Allowances 不是保证的 API Token 数量。
https://help.openai.com/en/articles/9793128

Stephen Monsell – Task switching (2003)；Simon Y. W. Li, Farah Magrabi, Enrico Coiera – A systematic review of the psychological literature on interruption and its patient safety implications (2012)。
关于任务切换与中断的综述研究，涉及 Switch Cost、恢复时间和错误等问题。它们支持本文中有限的认知机制论证，并不构成对 Coding Agents 的具体生产力估算。Task switching；关于 Interruption 的 Review。