Agentic Coding 实践 – Diverge · Decide · Converge

我在私人项目里会相对有意识地尝试不同的模型和 Reasoning 等级。并不是出于学术兴趣，而是因为我会直接感受到差别。一次规模不小、但大部分只是机械操作的重构，用强大的 High-Reasoning 模型可能完成得非常出色，同时也可能消耗掉有限周额度中惊人大的比例。

因此，对于这类任务，我现在经常会刻意选择较低的 Reasoning 等级。并不是因为我认为这些模型本身更好，也不是因为高能力模型不值得它们的价格。尤其在 Requirements Engineering、架构问题或困难分析上，我目前几乎不愿意放弃强大的 Frontier 模型。但对于日常例行工作，我现在会问另一个问题：这件事真的还需要同样多的模型智能吗？

在企业环境中，这种反馈往往弱得多。Token 消耗、Credits 和 API 成本通常由组织集中承担，单个开发者只能间接看到这些成本。这很容易理解，但也很容易形成一种工作方式：几乎不会主动进行 Model Routing。最强的模型既然可用，就直接使用。私人使用时则会更快意识到，一次枯燥的重构可能突然吞掉周额度中的相当大一部分。

这改变了我看待 Agentic Coding 的方式。

当前可用的最强模型，并不会自动成为每个任务最合理的模型。

因此，对我来说，现在更有意思的问题已经不是：哪个模型最好？ 而是：

在任务执行到当前这个阶段时，这个具体任务究竟还需要多少模型智能？

这个答案与我们把活动贴上 Requirements、Architecture、Coding 或 Testing 的标签关系比想象中小得多。真正关键的是另一件事：还有多少真正相关的决策没有做出？

开放的决策空间

把 Agentic Work 粗略分成两类很诱人：Requirements 和 Architecture 交给大模型，Coding 和 Tests 交给小模型。这样很简单，但在工程上过于粗糙。

Coding 完全可能高度探索性。你如果在一个陌生的 Legacy 系统里寻找难以复现的错误、重建架构边界，或者必须设计一套可行的重构策略，那么你虽然在处理代码，却仍然位于一个很大的决策空间中。反过来，Requirements 也可能已经高度收敛。如果一个现有的领域 Contract 只需要增加一个被精确定义的字段，也许几乎没有什么需要继续决定。

因此，对我来说更有意义的轴线是开放的决策空间：

我们越处在上方，就越需要有意义的方差。我们希望看到替代方案、质疑假设、发现关联，甚至希望模型提出一些我们自己没有想到的解决方案。决策空间越小，真正有价值的方差也就越少。

变化的不只是任务本身，也包括模型在这项任务中应该扮演的角色。

Diverge：方差是有价值的

我今天很大一部分工作，并不是从一条清晰的实现指令开始的。Tickets 不完整。Requirements 有时只隐含在现有行为中。一个 Legacy 系统不会主动告诉我它的架构，而是迫使我从代码、依赖关系和历史决策中重建它。面对错误时，原因一开始通常是未知的。对于更大的改动，也常常存在多个看起来都合理、但 Trade-offs 不同的方案。

在这种地方，我需要探索。我会把问题交给一个强大的 Planning 或 Reasoning 模型，先让它分析真正的领域问题是什么、现有行为里隐藏了哪些隐式 Requirements、系统的哪些部分受到影响、有哪些替代方案，以及不同架构方案各自会带来什么后果。对我来说尤其重要的是，模型还要挑战我自己的假设。有时我甚至会刻意只说一句：给我一个惊喜。

尤其在 Requirements Engineering 上，我目前几乎只使用一个强大的 Frontier 模型。这不是在说某个模型客观上就是最好的 Requirements 模型，只是在描述我当前的实践。它对我真正的价值也不只是语言表达更好，而是可以和我一起探索一个有意保持开放的解决空间。

POC 对我来说也属于这一类。它的目的往往就是回答一个尚未解决的技术问题。过程中会产生代码，并不会自动把这项工作变成一个已经收敛的实现任务。Legacy 分析、未知的错误根因，或者我首先想理解多个可能切分方式的重构问题，也是一样。

在这个阶段，创造力确实是一种 Capability。它是我们想要的，因为我们还不知道哪一种方案才是正确答案。

Decide：不确定性不能在无人察觉的情况下流入代码

只有探索，还不会自动产生优秀的软件。某个时刻，可能的方案必须变成具体决策。对我来说，这正是“Agent 作为 Sparring Partner”和“Agent 作为自主决策者”之间非常关键的区别。

模型可以提出选项、解释 Trade-offs、批判我偏好的方案，并把不同选择的后果显示出来。但最终究竟构建哪一种方案，责任仍然属于负责这项工作的 Engineering Team。

因此，在实践中，Decide 远不只是选一个方案。分析结果会被评估，再交给强模型进行一次映照和审视，然后继续收紧，最终被翻译成明确的实现任务。这个过程可能需要好几轮。

重点并不是把每一个小细节都变成正式的 Architecture Decision Record。真正重要的是，相关决策要在机械化实现开始之前变得可见。

这延续了本系列前几篇文章的逻辑。Requirements Engineering 减少领域层面的模糊性。Architecture 限制结构性的解决空间。信息保护限制 Agent 的 Context 与能力。Decide 在这些边界之内继续回答下一个问题：剩下那些尚未决定的事项中，我们现在究竟要明确决定哪些？

进入 Coding 任务时，未解决的决策越多，Agent 就必须自行决定得越多。这完全可能顺利工作，甚至看起来令人印象深刻地合理。但那也意味着，我们已经把一部分 Software Design 隐式地交给了代码生成过程。

移动代码，还不等于完成重构

我自己的工作中有一个小例子，非常清楚地让我看到这条边界。

一个 Coding Agent 曾把 Business Orchestration 实现在 UI Component 里。对我来说，这是一个一眼就能看出的 Architecture Smell。这个 Component 在协调一些按照我们的架构理解根本不应该属于它的事情。

于是我向 Agent 解释，这部分 Business Orchestration 必须离开 UI。它的反应在形式上完全正确：它把这些逻辑移动到了 Facade。

遗憾的是，问题并没有因此解决。

现在责任只是换到了另一个文件里，但真正的 Orchestration 结构切分仍然是错的。Agent 完成了我表面上的指令，却没有重新解决这条指令背后的架构决策。

正是在这种地方，Code Production 与 Software Engineering 之间的区别会非常清晰。

识别一个 Architecture Smell 往往并不难。真正的 Engineering 工作，是从中推导出更好的结构。

这时我会有意识地回到分析和规划，而不是继续给出“再挪到别处”这种 Prompt。我会把相关 Context 再次交给一个强大的 Reasoning 模型，让它分析责任和依赖关系，自己检查结果，然后重新做决定。

这也说明了，Diverge · Decide · Converge 并不是一条线性 Pipeline。实现本身可能产生新的信息。一个 Smell 也可能暴露出：我们以为已经做出的决策，其实并没有被解决得足够充分。

这时，决策空间必须重新打开。

Converge：最大程度的无聊

当关键决策真正都已经做出之后，我对 Coding Agent 的期待会发生根本变化。这时我不再想要任何惊喜。

任务描述 Scope。Agent Files 说明规则。Skills 或项目特定的 Instructions 提供已经确定的做法。Layering 和 Slicing 已经定义。Patterns 已经存在。Tests、Linter、Architecture Rules 以及其他 Verification Mechanisms 一起限制结果。

这时，我对生成代码的理想状态可以用一句很简单的话概括：

最大程度的无聊。

不要发明没人要求的新 Pattern。不要因为看起来可能更优雅就增加额外抽象。不要自发重新解释架构边界，也不要把一个有意保持局部的问题“创造性地”泛化。

当一个 Task 已经充分收敛时，创造力并不一定仍然是一种 Capability。它也可能成为 Drift。

典型候选包括 Mapper、DTO 转换、简单 Adapter、Moves 与 Renames、机械式重构、明确描述的 CRUD 部分，或者按照已有 Pattern 编写的 Unit Tests。但这同样不能再变成一条新的僵硬规则。

一个 Unit Test 可以几乎是机械性的：按照这个 Use Case 已有的 Tests 实现对应 Tests。 另一个任务则可能是：分析这个未知算法，找出真正重要的 Invariants，并据此设计可靠的 Test Strategy。 两者最终都会产生 Unit Tests，但它们的决策空间完全不同。

Refactoring 也是同样的道理。对已经明确识别出来的结构做 Rename 和 Move，与决定什么结构在领域和架构上才真正合理，是两种不同的问题。

因此，对我来说，Task Type 最多只是一个 Proxy。

真正的问题，不是我们在生成哪一种文件或 Artefact，而是剩下的任务到底还需要多少 Exploration、Judgment 与 Verification。

Model Routing 应该跟随决策空间

当真正相关的决策已经做出、现有 Pattern 清晰、任务 Scope 可控，并且结果可以被很好检查时，更小、更快或者更便宜的模型就开始对我有吸引力。

一旦出现多个在领域上都合理的解决方案、根因未知、Architecture 需要改变、必须理解系统的大范围结构，或者需要评估复杂 Trade-offs，我就更倾向于使用强模型。

这明确不意味着小模型是 Deterministic 的。它们同样会 Hallucinate、忽略规则、误解一个简单任务，或者即使有不错的 Instructions 仍然走向错误方向。较小的决策空间不会改变模型本身的性质，它改变的是我们对这个模型工作的要求。

较小的决策空间，会减少一项任务所需要的 Exploration 和 Judgment。

因此，一个便宜模型并不是因为“我们让它把困难决策做得差一点”而变得经济，而是因为我们在把任务交给它之前，已经把真正困难的决策从任务里移除了。

对我来说，这还包含另一条规则：Stop，而不是猜。

如果 Agent 在实现过程中遇到一项必要但尚未做出的架构决策，我不希望它去猜“最可能”的方案。如果 Contract 不明确，我不希望它发明一个 Contract。如果现有系统中存在两个相互竞争的 Patterns，而任务没有说明应该继续哪一个，那么这本身就是新的信息。

此时正确的下一步已经不再是 Converge。决策空间重新打开了。无论当前正在工作的模型是大还是小，这一点都一样。

我的工作流是一个 Loop

因此，我今天实际的工作方式，与几年前已经很不一样。

很长一段时间里，我都是一个非常热爱 Coding 的开发者。即使后来成为 Tech Lead，再后来成为 Software Architect，我也一直亲自实现。对我来说，Coding 从来不只是让架构落地的必要手段，它本身就是我喜欢 Software Development 的一部分。

今天，我自己写的代码反而少得惊人。相反，我花大量时间理解问题、澄清 Requirements、分析解决空间、做架构决策、定义 Constraints、拆解工作任务、让 Agents 实现，再去理解并审查它们的结果。

现在，一个真实任务对我来说通常包含多个循环。首先，我自己理解 Ticket 和领域问题，并把它转化成一个分析任务。一个强模型分析系统和问题。我评估结果，把它重新喂回模型，并持续收紧，直到可以得到足够可靠的工作任务。只有到这个时候，Coding Agent 才真正开始实现。

实现结束后，这个过程也不会停止。我自己先评估结果，然后把每一个重要结果步骤重新交给强模型。接下来是领域和技术 Review，如有需要再生成 Correction Brief，再次实现并 Verification。只有当这整个循环被干净地完成之后，才会进入 Commit。

这里有一个细节对我很重要：我不是只有在已经发现错误之后，才把结果交回强模型。我会在每一个重要结果步骤都这样做。

我自己 Review，然后把模型作为第二条 Review Channel。原因很简单：即使有很多年的 Software Development 和 Architecture 经验，我依然会漏掉东西。强模型同样也会漏掉东西。

Human Review 不能替代 Model Review。Model Review 也不能替代 Human Review。

我并不声称这是一套科学上已经证明最优的工作方式。它只是我当前的 Workflow。但它直接来自本系列文章 Convincingly Wrong 里已经出现过的问题：Plausibility 不是 Verification。

一个 Diff 看起来完全合理，仍然可能在领域上是错的。一个 Model Review 听起来很有说服力，也可能漏掉问题。一个有经验的开发者可以完全理解一个 Patch，却仍然忽略某个 Interaction。因此，对我来说，质量越来越来自多个相互独立的控制机制：自己的理解、Model Review、Tests、Static Rules，以及在可能的地方使用可复现的领域 Verification。

好架构会缩短一次变更的“前史”

在这里，我日常工作中越来越明显地看到另一层联系：一个简单的 CRUD Feature，并不自动意味着一个简单的 Agent Task。

拿一个在领域上非常普通的 Comment Feature 来说。在一个拥有清晰 Boundary、明确 Layering、已经建立好的 Slice、现有 CRUD Patterns 和清楚 Contracts 的 Greenfield 系统中，这个任务确实可以很快收敛。Agent 不需要先重建 Feature 应该放在哪里，也不需要猜现有多个 Pattern 中哪一个才恰好是正确的。

但在一个长期演化的 Legacy 系统里，同样的领域功能往往要从更前面开始。首先要弄清楚，系统中到底哪一部分负责这件事。然后会出现多个相互竞争的结构，必须重建 Dependencies，同时新的 Feature 又不能继续扩大 Legacy。有时还得先找到一个 Boundary，把已有结构控制在那条边界之外。

在我的实践里，这一部分可能会花掉几个小时。不是因为之后的 CRUD 很复杂，而是因为在实现之前，首先必须建立一个足够可靠的决策空间。

这首先是我的个人经验。关于 Repository 结构与 Context Retrieval 的相关研究及其局限，我已经在第 08 篇 – Architecture as Constraint中做了整理。对 Diverge · Decide · Converge 来说，其中真正重要的是一个操作层面的问题：在任务进入实现之前，还有哪些结构性决策必须先被澄清？

好架构不会让 Agent 变得更聪明。但它可以减少 Agent 在能够合理实现之前必须完成的工作。

Ownership、Boundaries、Layering、Contracts、Tests 和 Architecture Rules 因此不只是给人类使用的 Maintainability Tools。它们也是 Orientation。Orientation 会减少 Agent 必须先重建“我们到底是什么意思”的那部分工作。

而且这里时间至少和 Tokens 一样重要。一个很长的分析 Loop 会消耗 Agent Runtime、Context、Model Usage、阅读、Reviews、进一步收紧和人的注意力。一个定义得很差的 Task，最昂贵的部分最后甚至可能根本不是 Code Generation，而是直到我们终于清楚“应该生成什么代码”为止的那一整段工作。

完整的经济分析值得单独写一篇文章。对于这一篇，只需要先确认：开放的决策空间不只是质量问题，它同样是成本因素。

Model Routing 开始变得具有经济意义

只要快速看一下当前的价格结构，就能看到这些差异已经可以有多大。

截至 2026 年 9 月，OpenAI 对 ChatGPT Work 和 Codex 列出的示例价格中，GPT-5.6 Luna 每百万 Input Tokens 为 0.20 美元、每百万 Output Tokens 为 1.20 美元；GPT-5.6 Sol 分别为 4 美元和 20 美元，属于限时 Promotion 价格；GPT-6 Astra 则为 10 美元和 50 美元。在同一个产品生态中，模型等级之间已经存在足以在高频 Agent Usage 下产生明显经济影响的数量级差异。OpenAI: Enterprise Rate Card；另见带有 Promotion 说明的 Sol 模型页面。

Anthropic 也体现出同样的原则：当前 API 价格表中，Claude Haiku 4.5 的 Input/Output 为每百万 1/5 美元，Claude Sonnet 5 为 2/10 美元，Claude Fable 5.1 为 10/50 美元。这些数字只是 2026 年 9 月 10 日这个时间点的快照，不是质量排名，更不是某类 Task 的长期固定推荐。Anthropic: API 价格表。

Reasoning 也比简单的“价格乘数”更复杂。在前面提到的 Enterprise 价格结构中，OpenAI 对 GPT-5.6 不同 Reasoning Level 按同样的 Token 单价计费。但这并不意味着不同 Reasoning Level 会产生相同的总消耗。GitHub 当前的 Copilot Documentation 明确指出，更高的 Reasoning Level 可能消耗更多 Tokens，因此也会消耗更多 Credits。单价相同和最终用量相同，是两件不同的事。

我在私人使用中会非常直接地感受到这个机制。对于一个单独的机械 Task，差别可能看起来没什么。但当 Agent Usage 很高时，它最终会决定一个额度是两天就耗尽，还是能够撑完整个星期。

而产业已经开始对此做出反应。

GitHub Copilot 现在已经拥有带 Task Optimization 的自动 Model Selection。根据 GitHub 的说明，Router 会考虑 Task Complexity 和当前 Model Availability 等因素，并试图把更昂贵的 Reasoning Models 留给真正需要额外能力的任务，而把更简单的任务路由到更快、更便宜的模型。

GitHub 自己的建议现在甚至明确倾向于 research, plan, then implement：先用更强 Reasoning 做 Planning，再用适合 Execution 的模型完成聚焦后的实现。GitHub 还建议对 Scope 明确的 Subagents 使用更便宜的模型，并指出精确 Instructions 与 Repository Maps 可以减少不必要的 Exploration。

因此，Model Routing 已经不再只是理论上的未来概念。即便如此，我也不会把这种自动化和我真正的 Decide 步骤混为一谈。

Router 可以从 Prompt 中估计一个 Task 看起来有多复杂。但它并不知道我所在组织允许哪一种 Architecture Decision，不知道两个现有 Patterns 是历史包袱还是刻意保留的不同方案，也不知道对现有 Pattern 的偏离是不是当前真正想要的。而且，如果一个相关决策没有作为 Context 或 Constraint 显式提供，它也无法可靠知道这个决策是否已经做出。

自动 Model Routing 不能替代对决策空间的定义。

它只能在我们真正让系统看见的东西之内进行优化。

本地模型扩大了可选的解决空间

当除了 Cloud Models 之外，Local Models 也进入可选范围时，Model Routing 会变得更有意思。

一个当前例子是 Qwen3.8-27B。Alibaba 在 2026 年 8 月 14 日以 Open-Weight Model 的形式发布了它。这个 Dense Model 拥有 270 亿 Language-Model Parameters，支持不同 Reasoning Settings，并以 Apache 2.0 许可证发布。

厂商自己公布的 Coding Benchmarks 很值得注意。例如 Qwen 在 Model Card 上给出的结果包括 SWE-bench Pro 61.7%，Terminal-Bench 2.1 73.0%，均是在其描述的 Evaluation Conditions 下得到的。这些数字是厂商 Benchmark，必须以这种身份去理解。

现在也已经存在 Artificial Analysis 的独立测量。在那里，Qwen3.8-27B 同样属于其 Open-Weight 尺寸等级中表现较强的模型。与此同时，Evaluation 还展示了一个对 Model Routing 非常有意思的 Trade-off：Maximum-Reasoning 版本会产生非常多的 Reasoning Output，并且相比之下明显更慢、更啰嗦。也就是说，即使 Model 本地可用，更多 Reasoning 也不是一种免费的抽象。

我自己目前还没有对 Qwen3.8-27B 的可靠实践经验。因此，我会带着兴趣，也带着一定怀疑去看当前的 Hype。这一等级的模型至少说明，本地可运行的系统已经达到一个性能区间，让人可以严肃讨论它们是否适合明确边界的软件任务。我现在不会从中推导更多结论。

尤其要强调的是，Local 并不等于 Free。官方 Model Card 描述的是一个约 280 亿参数的 BF16 Dense Model，同时也列出了可用的 Quantizations。仅这一点就足以说明，我们讨论的不是普通开发机上的轻量基础设施。高性能本地 Inference 需要 Memory 与 Compute；实际运行还包括 Hardware Acquisition、Electricity、Cooling、Maintenance、Updates 和 Utilization。

所以，本地部署只是改变成本结构，而不是消除成本。

Hardware、运维与 Utilization，以及哪一种方案在什么条件下更划算，都放在第 13 篇 – Agentic Work 的经济学中讨论。

一份 Specification 并不会自动关闭决策空间

到这里，一个很自然的误解就会出现。如果更小的决策空间能让 Implementation 更简单，那么我们似乎可以把一个非常古老的软件想法换一层 AI 外衣：写一份巨大的需求规格说明书，把它交给 Agent，然后从另一端拿到一个完成的 Product。

这行不通。

一份 Specification 可以非常大，同时仍然充满开放决策。从领域描述到真正工作的系统之间，Architecture、Ownership、Data Model、UX、Error Behavior、Security、Operational Behavior、Integration Strategy 与 Test Strategy 都可能仍未决定。这些决策不会因为 Requirement Document 有一百页就消失。如果没有人显式地做决定，它们会在实现过程中被做出——也就是被 Agent 做出。

一份很大的 Specification，并不自动意味着一个很小的决策空间。

因此，对我来说，Spec Driven Development 并不是把不确定性倒进一个更大的文档里，然后期待后面出现 Deterministic Code Generation。一份好的 Specification 会在真正已经做出决策的地方减少决策。Architecture Constraints 再减少一些。Contracts 再减少一些。Tests 和 Verification Rules 再减少一些。

只有这样，任务才真正开始收敛。

这正是本系列前几篇文章在这里交汇的地方。Requirements Engineering 限制领域解决空间。Architecture 限制结构解决空间。Information Protection 限制 Context 与 Action Possibilities。而在这个越来越被定义清楚的空间中，我们才有意识地决定什么时候应该制造方差，什么时候应该减少方差。

当代码生产变得更便宜

我自己的角色变化，也许是我最需要适应的一部分。

我喜欢写代码。我职业身份中很大一部分，都建立在“能够亲手实现困难的技术问题”这件事上。因此我也能够理解，为什么很多开发者面对 Code Production 的自动化，会和面对 IDE 里的一个新 Refactoring Tool 很不一样。如果你花了二十年时间让自己变得特别擅长写代码，那么当恰恰这件事开始越来越容易被自动化时，它当然不会是一种完全中性的体验。

但我仍然不认为，讲一个“开发者走向衰落”的故事有什么意义。我的个人观察是另一个方向：

代码生产正在越来越多地从人转移到 Agent。与此同时，真正的 Software-Engineering Disciplines 的相对价值正在上升。

Problem Understanding、Requirements Engineering、Architecture、Modeling、Testing、Security、Verification 和 Technical Decision-Making 都不是新活动。只是很长时间里，我们很容易把它们和这个行业最显眼的活动混为一谈：写代码。

也许我们需要重新多学一点 Software Engineering，也少一点以“自己能多快生产代码”为荣。因为当 Code Production 变得更便宜时，能够决定究竟应该产生什么代码的能力，其相对价值就会上升。

所以，对我来说，今天的 Agentic Coding 并不是简单把 Coding 交给一个模型，而是有意识地控制决策空间：需要探索的地方允许 Exploration，需要责任的地方明确做出 Decisions，在决策已经完成的地方减少 Variance。

而如果在实现过程中重新出现一项真正相关的不确定性，我们就回去。Loop 重新开始。

Software Engineering 在不同时间点，需要不同程度的方差。

当你还不知道正确答案是什么时，Diverge。在这份不确定性流进代码之前，Decide。决策已经做出后，再 Converge。

Coding 正在变得越来越可以委托。Software Engineering 仍然负责决定应该创造什么、哪些边界有效，以及最终结果到底是否真正优秀。

来源与说明

• GitHub Copilot – Auto Model Selection 与 Efficiency Guidance： 截至 2026 年 9 月，GitHub 已经记录生产环境中的 Routing：会考虑 Task Complexity、Cost 和 Availability，并针对开放程度和难度不同的 Tasks 推荐不同 Model Capacity 和 Reasoning Levels。这表明 Model Routing 已经实际存在；但这套产品逻辑并不会自动理解某家公司的领域和架构决策。
• OpenAI 与 Anthropic – 当前模型价格： 官方价格表显示不同 Model Classes 之间存在显著差异。上文链接的价格表和模型页面均于 2026 年 9 月 10 日访问。GPT-5.6 Sol 被标注为 Promotion，按 OpenAI 的说明至少持续到 2026 年 11 月 21 日。这些价格并不是长期稳定关系。
• Qwen3.8-27B： 发布信息、Architecture、License 和文中提到的 Coding Benchmarks 来自 Qwen 官方材料，因此这些 Coding Scores 应被视为厂商 Benchmarks。Artificial Analysis 提供额外独立测量，并在展示高性能的同时，也显示 Maximum-Reasoning Configuration 会产生很高的 Reasoning-Token Volume。本文并不基于作者自己的实际使用经验。