I. 引言
在当前人工智能技术蓬勃发展的时代，大型语言模型（LLMs）正以其卓越的文本理解与生成能力，深刻地改变着各行各业，尤其是在软件开发领域。它们不仅重塑了人机交互的范式，更在文本生成、理解、总结、乃至复杂推理等任务中展现出前所未有的潜力。
然而，面对日益复杂的软件项目，单一 LLM 往往在准确性、一致性、逻辑严谨性和自主性方面力有未逮。正是在这样的背景下，AI Agent（智能代理）应运而生。Agent 不仅拥有 LLM 的"大脑"，更被赋予了规划、记忆、工具使用和自我反思的能力，使其能够像人类专家一样，将复杂目标拆解、逐步执行，并减少错误。
本文旨在深入探讨如何高效利用 Coding Agent 进行规约驱动开发 (Spec-Driven Development, SDD)，SDD 作为一个哲学思想可以追溯到软件工程的早期，它是在瀑布模型、MDD（模型驱动开发）、TDD（测试驱动开发）、BDD（行为驱动开发）、API-First 等方法论中不断演进，并在近年因为 Coding Agent 的出现，才展现出其巨大的潜力。我们将从 LLM 的核心工作原理、其固有的局限性（如幻觉）以及上下文窗口的挑战出发，深入理解 SDD "复兴"的深层逻辑。在此基础上，本文将提炼出 Agent 使用的核心指导原则，并详细阐述在 SDD 各阶段（包括需求分析、技术设计、代码实现与测试）与 Agent 协作的具体实践。最终会分享使用 Agent 的心得体会，帮助读者在 LLM 和 Agent 的浪潮中，更稳健、高效地把握技术趋势。
II. 背景知识：理解 LLM 与其局限
要高效利用 Coding Agent，首先需要深入理解其核心------大型语言模型（LLM）的工作原理、所具备的能力以及其固有的局限性。这些局限性是 Agent 在开发过程中可能"信口开河"或"胡说八道"的根源，也是我们设计指导原则的基础。
2.1 大型语言模型 (LLM) 基础
LLM 是一类基于深度学习的强大机器学习模型，它们在海量的文本数据上进行训练，旨在理解、生成和处理人类语言。其核心思想是学习语言的统计规律，通过预测给定上下文的下一个词（Token），从而涌现出词汇、语法、语义、事实知识和推理能力。
- 什么是 LLM： LLMs 具有数亿到数万亿的参数，使其能够捕捉语言中复杂的模式和关系，实现对自然语言的深入处理。它们本质上是概率预测机器，而非真理探测器。
- LLM 的输入与输出： LLM 虽与人类以自然语言进行交互，但在模型内部，所有的输入和输出都经历了一个严谨的数字化和向量化转换过程：
- 输入处理： 自然语言文本首先经过**分词（Tokenization）分解成 Token，然后通过 词嵌入（Token Embedding）转换为高维度向量，再加入位置编码（Positional Encoding）**以保留顺序信息。对于多模态 LLM，其他模态数据也会被编码为统一向量。
- 输出生成： LLM 根据当前上下文预测下一个最可能出现的 Token 的概率分布 ，通过**解码（Decoding）策略（如 Beam Search, Top-K, Nucleus Sampling）选择 Token。这一过程 循环（自回归）进行，直到满足停止条件。生成的 Token 序列再通过逆向分词（Detokenization）**转换为人类可读的自然语言文本。
2.2 LLM 的推理与幻觉
LLM 的强大能力之一是其推理能力 ，但这种能力与人类的逻辑推理有所不同，并且伴随着幻觉这一固有现象。
- LLM 如何实现推理： LLM 的推理能力并非基于编程逻辑，而是一种从海量数据中学习统计模式后涌现出来的能力。通过大规模模式识别、上下文理解、世界知识编码以及指令微调和思维链提示（CoT），LLM 能够进行多步骤思考并解决复杂问题。然而，其本质仍是基于概率和统计的模式匹配。
- 为什么会产生幻觉： LLM 的"幻觉"（Hallucination）是指模型生成听起来流畅、连贯，但在事实上虚假、不准确、捏造或与给定事实不符的内容。其根本原因包括：
- 统计性质局限： 模型以预测下一个 Token 为目标，而非保证事实绝对正确。
- 训练数据问题： 互联网数据中的噪声、偏差、稀疏性导致模型学到错误或不完整信息。
- 生成过程不确定性： 解码策略在追求多样性时，可能引入低概率但错误的 Token。
- 上下文长度限制： 长文本可能导致模型遗忘或混淆早期信息。
- 知识时效性： LLM 的知识库有截止日期，无法感知训练数据之外的新信息。
- 幻觉的当前缓解方式： 缓解幻觉是一个系统性工程，已取得显著进展，主要依赖：
- 高质量训练数据： 清洗、去偏、引入权威知识源。
- 模型训练与架构优化： 增大模型规模、改进预训练目标、事实知识注入。
- 微调与对齐： 指令微调和基于人类反馈的强化学习（RLHF）使模型更好地遵循指令和人类偏好。
- 推理与应用层面： 检索增强生成（RAG）、思维链提示（CoT）、自我修正与反思、置信度评估、集成外部事实核查工具、清晰具体的提示。
2.3 幻觉处理的持续挑战
尽管 LLM 在幻觉缓解上取得了显著进展，但问题远未彻底解决，以下是当前仍面临的主要挑战：
- 微妙幻觉与"自信的错误"： 模型可能篡改细节、不准确概括，此类幻觉更隐蔽，且 LLM 仍会以高度自信的语气呈现错误内容，损害用户信任。
- 领域特定性与推理幻觉： 在高度专业化、知识更新迅速或数据稀疏领域，幻觉仍易发生。即使单点事实正确，多步推理过程也可能出现逻辑错误。
- 多模态幻觉与可控性不足： 在多模态 LLM 中，幻觉不仅限于文本，还可能出现在图像生成、描述中。目前仍难以完全解释幻觉成因，也缺乏精确控制机制。
2.4 LLM 的上下文窗口与管理需求
LLM 的"上下文窗口"（Context Window）是指模型在生成下一个 Token 时，能够同时考虑和处理的输入文本的最大长度。它直接决定了 LLM 的"记忆"范围。
- 什么是上下文窗口： LLM 在进行推理和生成时，会将输入文本（用户提示、历史对话、检索到的文档等）编码成一个连续的序列，上下文窗口就是这个序列的最大 Token 数量限制。一个 Token 可以是一个单词、词根或字符。
- 为什么需要上下文管理：
- 更强的理解力： 处理更长文档、复杂指令，实现对意图的全面理解。
- 生成更连贯文本： 避免重复、脱节或矛盾的内容。
- 处理复杂任务： 对于文档摘要、代码审查等任务不可或缺。
- 减少"遗忘"问题： 避免在长对话中丢失早期信息。
- 上下文窗口大小受到的限制： 尽管大上下文窗口优势明显，但其扩展并非无限，主要受制于：
- 计算复杂性： Transformer 核心的自注意力机制计算量随序列长度
N呈O(N^2)增长，导致高昂的计算成本和时间消耗。 - 内存使用： 存储注意力权重矩阵和 Key-Value (KV) 缓存所需的内存同样呈
O(N^2)增长，易超出现有硬件限制。 - "迷失在中间"现象： 模型对长上下文两端的信息记忆能力强，对中间部分容易遗忘。
- 训练数据分布： 预训练数据平均长度可能较短，导致模型对超长序列处理不充分。
- 模型架构的固有局限： 早期位置编码对长度有限制，尽管新技术有所改善。
- 计算复杂性： Transformer 核心的自注意力机制计算量随序列长度
2.5 扩展与管理上下文窗口的技术（简述）
为克服上下文窗口限制，研究人员和工程师们开发了多种技术：
- 稀疏注意力 (Sparse Attention)： 减少每个 Token 关注的范围，降低计算复杂度。
- 分层注意力 (Hierarchical Attention)： 将长文本分块处理，再聚合摘要。
- 滑动窗口注意力 (Sliding Window Attention)： 每个 Token 只关注局部窗口内的 Token。
- Key-Value 缓存优化 (KV Cache Optimization)： 提高推理效率。
- 位置编码优化 (Positional Encoding Enhancements)： 允许模型更好地泛化到更长序列。
- 检索增强生成 (RAG)： 通过外部检索系统提供相关信息，间接扩展模型可利用的信息量。
III. 「Coding Agent 使用」的核心指导原则
理解了 LLM 的能力边界和局限性，特别是其在处理幻觉和上下文方面的挑战后，我们可以提炼出与 Coding Agent 高效协作的两大核心指导原则。这些原则是规避风险、最大化 Agent 价值的基石。
3.1 指令明确，信息充分：Agent 的"喂食"艺术
核心思想： AI Agent 缺乏人类的常识、隐性知识和领域经验。它们严格按照所接收到的信息和指令进行推理和行动。因此，**"垃圾进，垃圾出"（Garbage In, Garbage Out）**的原则在这里尤为适用。为了减少幻觉的发生，确保 Agent 生成内容的准确性和相关性，我们必须像对待一个极其严谨但缺乏创造力的初级工程师一样，提供所有必要的背景、约束和细节。
实践方法：
- 详尽的背景与约束： 在向 Agent 下达任务时，不仅要说明"做什么"，更要详细说明"为什么做"、"在什么背景下做"以及"有什么限制"。这包括业务目标、用户场景、技术栈要求、性能指标、安全规范、编码风格指南等。
- 提供所有必要的上下文信息： 如果任务涉及修改现有系统，Agent 无法"凭空"知道你的代码库。你需要提供相关的代码片段、API 文档、配置文件、设计文档，甚至是完整的仓库上下文。对于复杂的业务逻辑，提供流程图、状态机图或数据模型有助于 Agent 更好地理解。
- 在高度专业化、知识更新迅速或数据稀疏领域的人工介入： 对于 Agent 训练数据可能不足或已过时的专业领域（如新兴技术、特定行业法规），人工调研并提供权威、最新的文档和资料至关重要。将这些信息作为 RAG（检索增强生成）的外部知识源提供给 Agent，能够极大减少其"脑补"和幻觉的风险，使其基于事实而非推测进行生成。这相当于为 Agent 提供一个"外部大脑"或"实时知识库"。
- 明确的期望输出格式： 清楚地告知 Agent 你希望得到什么样的结果，例如是代码片段、一份详细的报告、一个逐步的指导，还是一个决策树，甚至包括文件路径和命名规范。这有助于 Agent 精准聚焦，避免生成不相关的输出。
3.2 留足推理空间：上下文的管理
核心思想： 尽管 LLM 的上下文窗口在不断扩大，但模型在内部进行复杂推理时，仍然需要足够的"思维空间"。如果上下文被无关信息过度填充，或者关键信息被淹没在冗余细节中，模型的推理能力就会受到限制，甚至出现"迷失在中间"的现象，导致判断失误或逻辑跳跃。
实践方法：
- 控制上下文大小： 并非上下文越大越好。关键在于提供相关且精炼的上下文。过长的、低质量的上下文不仅会增加 Token 消耗，更会稀释关键信息的重要性，干扰模型的注意力。
- 为 LLM 留足推理空间： 在设计 Agent 工作流或与 Agent 交互时，要确保输入给 LLM 的 Token 数量不会占据整个上下文窗口的绝大部分，而导致 LLM 自身进行思考、规划和生成答案的空间被压缩。例如，如果你有一个 200k Token 的上下文窗口，但你的输入占用了 180k Token，那么留给 LLM 进行复杂推理和生成长答案的空间就非常有限。
- 及时进行上下文压缩 (compact) 与清理 (clear history)：
- 压缩： 当对话或任务进行到一定阶段，历史信息变得冗长时，可以指示 Agent 对历史对话进行总结、提炼关键点，或者移除不再相关的细节，从而以更精简的形式保留核心上下文。
- 清理： 对于已经完成或偏离当前焦点的任务历史，应及时清除，避免"记忆碎片"干扰 Agent 的当前决策，导致其在后续任务中"跑偏"或反复提及不相关的信息。
- 策略性保留： 重要的全局配置、架构原则或核心数据模型等，应作为持久化上下文策略性地保留，但也要确保其格式精炼，避免过度占用空间。
遵循这两条核心指导原则，能够帮助我们在与 Coding Agent 的协作中，更有效地发挥其潜力，规避其内在局限，从而构建更可靠、高效的开发流程。
IV. Coding Agent 辅助的 SDD 项目开发实践
在理解了 LLM 和 Agent 的基本原理及指导原则后，我们可以考虑一下为什么是 SSD? SDD 的核心理念是将传统软件开发生命周期（SDLC）中那些被验证行之有效的实践------需求分析、系统设计、任务分解------进行压缩和自动化，并将其作为 AI 生成代码的强制前置步骤。虽然"Spec-Driven"的理念一直存在，但由于之前高层规范到实际代码的转换效率和准确性不高，其在大规模应用上一直面临挑战。现在由于强大 Coding Agent 的出现，具备了前所未有的理解自然语言/结构化规范、生成代码、修复错误和迭代优化的能力，并且 LLM 正需要明确的指令与高度的规范性来执行任务，这才使得真正意义上的"Spec-Driven Development"变得异常高效和实用。
本章将详细阐述如何根据核心指导原则，来使用 Coding Agent 融入 SDD 的各个阶段，以实现高效、高质量的软件交付。这些实践操作正是**遵循第三章提出的核心指导原则（"指令明确，信息充分"和"留足推理空间"）**而设计，旨在通过合理拆分子任务，确保每次任务目标足够准确专一、信息明确，并控制任务大小以留出足够的上下文空间，从而最大化 Agent 的效能并规避其局限性。我们将 Agent 视为一个能力极强但仍需引导的"智能助理"，通过迭代与协作，充分发挥其在需求分析、技术设计、实现与测试中的独特优势。
4.1 需求分析与产品设计
需求分析是项目成功的基石。在这一阶段，我们通过遵循**"指令明确，信息充分"的核心指导原则**，将复杂任务拆解为足够明确、复杂度适中的子任务，以确保 Agent 能更全面、严谨地协助我们定义和完善产品需求，为后续开发奠定坚实基础。
- 4.1.1 明确问题与目的：
- 实践： 在启动任何项目或任务前，我们应与 Agent 充分对话，清晰界定核心业务问题和最终目标，确保双方理解一致。例如，引导 Agent 提炼"目标用户是谁"、"解决什么痛点"等关键信息，形成初步的任务规格。
- 目标： 从源头避免方向性偏差，为后续开发构建坚实基础。
- 4.1.2 需求调研：
- 实践： 利用 Agent 强大的信息检索能力，进行深度调研 (deepresearch)，收集市场主流方案、竞品分析及行业最佳实践。例如，可指令 Agent 检索"XX功能在主流应用中的实现方式及用户反馈"或"XX类型产品的 UX 设计趋势"。
- 目标： 快速获取广泛的背景知识和前沿灵感，为产品设计提供有力支撑。
- 4.1.3 需求完善与细化：
- 实践： 将调研结果与初步需求框架提供给 Agent，让其协助完善细节并整理产品方案。由于 Agent 生成的文档可能偏向理想化，整体比较华丽 fancy，我们需要对其进行审阅，补充或删除细节，确保其紧密围绕 MVP 目标，并符合实际预期。
- 目标： 产出完整、具体且易于理解和实现的需求文档。
- 4.1.4 主要模块产品设计：
- 实践： 若 Agent 生成的模块设计方案（如 UX）不尽理想，可进一步使用其他 Agent 调研(避免污染 context)不同的 UX 设计方案，分析其优缺点。作为主导者，我们需综合考虑技术实现难度和交互方案，拍板最终设计，再由 Agent 协助补充具体细节。
- 目标： 在用户体验与技术可行性之间取得平衡，明确核心产品功能的设计细节。
- 4.1.5 需求评审 (Review)：
- 实践： 利用另一个 Agent（或不同模型的 Agent，以获得更广阔的视角对最终产品需求文档 (PRD) 进行评审。命令 Agent 检查 PRD 的逻辑一致性、描述清晰度，识别潜在的矛盾、歧义或冗余功能。根据评审结果进行修改，并循环评审，直至达到高质量标准。
- 目标： 在需求阶段即发现并消除潜在问题，显著提升 PRD 质量。
4.2 技术设计与架构规划
技术设计是连接需求与实现的桥梁。在此阶段，我们仍需严格遵循核心指导原则，确保指令明确、信息充分，并有效管理上下文，以便 Agent 能更好地协助我们进行技术选型、架构设计及方案评审，确保后续代码实现有据可依，不偏离方向。
- 4.2.1 技术栈选型：
- 实践： 向 Agent 提供详尽的 PRD 及现有系统约束，要求其调研实现需求所需的技术栈。Agent 将分析不同技术栈（如语言、数据库、框架、包管理工具等）的优缺点、社区活跃度、性能特点及学习成本，并根据项目具体需求（如并发量、数据一致性、开发周期等）给出选型建议。
- 目标： 做出基于充分信息的理性技术决策，为项目选择最合适的组合。
- 4.2.2 架构概要设计：
- 实践： 在确定技术栈后，与 Agent 共同提出架构需求：例如如何分层、必须遵守的核心原则（如方法要DRY, 类要SRP, 模块要OCP, 不同层之间要最小化层间依赖，符合依赖反转原则，方便不同层的无感替换，整体符合 KISS 等）。与 Agent 讨论并做架构概要设计，在调整没有问题后，指示 Agent 生成架构设计文档。
- 目标： 确保架构设计合理健壮、高内聚低耦合，支持并行开发（意味着模块独立、低耦合）、易于维护和独立测试。
- 4.2.3 详细设计：
- 实践： 针对架构概要中的每个模块，要求 Agent 深入进行详细设计。这里 Claude Code 表现很好，只需要下达指令时重申和强调需遵循的设计原则即可。
- 目标： 提供清晰无误的实现蓝图，保障代码质量和一致性。
- 4.2.4 技术设计方案评审：
- 实践： 人工 review 接口设计以及模块设计是否存在问题，是否需要合并整合，是否需要拆分，经过 Coding Agent 重修修改后，可以再次利用其他 Agent 进行技术设计方案评审。要求 Agent 的 review 重点可以放在设计方案与 PRD 的一致性、潜在遗漏或错误、与选定技术栈及架构的符合度，针对 review 问题可以在用新的 Agent deepresearch 否存在更优的实现方案（例如，考量性能瓶颈、扩展性限制和安全性漏洞）直到满意。
- 目标： 在编码前有效发现并修正设计缺陷，避免将问题带入后期开发阶段。
4.3 代码实现与功能开发
在需求和技术设计均已明确无误后，Coding Agent 便可大展身手，将清晰的规范转化为实际代码。这个阶段可以感受一下 Coding Agent 的速度，很哇塞。但是我们不要着急先生成代码，而是先按照SDLC制定开发计划，让 Coding Agent 按照计划一步一步实现，确保每一步目标明确、可执行、可测试，来提高输出质量。
- 4.3.1 制定开发计划：
- 实践： 与 Agent 协作制定详细的开发计划。严格遵循**"留足推理空间"原则**，将大型任务拆解为独立、粒度适中、复杂度可控的小任务。明确每个子任务的输入、预期输出和验证方法，并确保每个阶段完成后都能进行阶段性验证。
- 目标： 通过敏捷迭代、小步快跑的方式，有效降低开发风险。
- 4.3.2 逐步实现与验证：
- 实践： 严格按照开发计划，要求 Agent 完成各阶段的开发任务。Agent 完成后，立即执行测试验证，确保其严格符合规格和预期行为。
- 目标： 通过快速迭代，保障每个功能模块的高质量交付。
4.4 测试与验证
测试是软件质量的最后一道防线。尽管 Coding Agent 能够高效生成代码，但对其产出的验证必须严格且全面，以确保最终交付的正确性与可靠性。
- 4.4.1 单元测试：
- 实践： 命令 Agent 为其生成的每个方法自动编写全面的单元测试用例。这些用例需覆盖正常路径、边界条件及异常情况（最好人工对单测设计进行 review，infra 部分的单测设计最好给出提示规范）。在代码生成后，立即运行这些单元测试，确保每个方法均能独立且按预期工作。
- 目标： 从代码原子层面验证功能正确性，确保符合设计规格。
- 4.4.2 端到端测试 (E2E Test)：
- 实践： 根据项目实际情况决定端到端测试 (E2E Test) 的投入。虽然 Agent 可协助生成 E2E 测试脚本，但在当前阶段，对于关键业务流程，人工主导 E2E 测试更为稳妥，以确保整个系统集成后的行为完全符合预期。
- 目标： 全面验证系统的用户流程和端到端业务逻辑的正确性。
4.5 需求迭代与更新
软件开发是一个持续演进的过程，需求变更在所难免。
- 实践： 当需求发生更新时，提前让 Agent 回顾历史代码和设计文档，快速理解现有模块状态。然后检查是否有需修改或重构的模块，可指令 Agent 协助执行代码重命名、接口重构等操作。新需求的迭代流程（明确问题、调研、设计、实现、测试）与前面的保持一致，但是根据功能难易程度进行适当调整。
- 目标： 确保需求变更能够高效、安全地集成到现有系统中，同时保持代码的可维护性和架构的稳定性。
V. Coding Agent 使用心得与技术洞察
在与 Coding Agent 协同工作的过程中，除了遵循上述原则和实践，一些心得体会和对技术趋势的洞察也至关重要。这有助于我们更有效地驾驭 Agent，并避免陷入技术概念的迷宫。
5.1 专注核心：充足上下文与明确目标是高质量结果的前提
"Attention is all you need"这是 Google 的工程师提出 LLM 训练基石 Transformer 的一篇 paper 名称，有兴趣可以搜搜看，这句话不仅适用于 Transformer 架构本身，也是 LLM 及 Agent 交互的关键。Agent 能够给出高质量结果的根本，在于你提供了：
- 足够的上下文： 包含了任务所需的全部背景信息、技术规范、代码片段、领域知识等。
- 足够明确的目标： 清晰地定义了任务的范围、期望的输出、成功的标准。
当这两者都得到满足时，Agent 能够更好地理解你的意图，进行准确的推理，并生成符合预期的内容。
5.2 上下文管理是 Agent 协作的关键技巧
LLM 的上下文窗口是其"思考"和"记忆"的载体。有效的上下文管理是提升 Agent 性能、降低成本、避免错误的重中之重。
- 控制上下文大小： 无关信息会稀释关键信息，甚至引起"迷失在中间"效应。需要策略性地选择哪些信息进入上下文，减少 Attention 偏离主题。
- 为 LLM 留足推理空间： 确保输入给 LLM 的指令和信息不会填满整个上下文窗口，留出足够的 Token 空间供 LLM 进行内部思考、规划和生成。这尤其重要，因为 Agent 本身的规划、反思、工具使用等机制都需要 LLM 进行额外推理，这些推理活动同样会消耗上下文。
- 及时进行上下文压缩 (compact) 与清理 (clear history)： 当对话变得冗长或任务阶段性完成时，应指示 Agent 对历史对话进行总结提炼，或清除不再相关的历史信息。这能避免"记忆碎片"干扰 Agent 的当前决策，保持其"思维"的清晰度。
5.3 警惕"Agent 疲劳"与"隧道效应"
在使用 Agent 的过程中，如果发现其开始钻牛角尖、回复质量明显下降，或者陷入重复的逻辑循环，这通常意味着 Agent 已经"疲劳困顿"了。它可能因为上下文过长、信息混乱或推理路径受阻而进入一种"隧道效应"（Tunnel Vision），无法打开更广阔的视野了。
- 应对策略： 及时中止当前的 Agent 会话，清理其状态或启动一个新的 Agent 实例。这相当于给 Agent 一个"刷新"，让它从零开始。这与人类在长时间高度集中后需要休息或切换任务以恢复思维清晰度异曲同工。
5.4 Agent 特性化使用策略
不同的 LLM 或 Agent 在设计和训练上有所侧重，因此在特定任务上表现会更优。但是随着 Agent 的发展这种表现可能会有变化，目前个人的使用习惯上是这样的：
- Gemini： 因其背后强大的 Google 知识图谱和搜索能力，个人推测以及使用感受也更适合进行 deepresearch、信息收集和需要广阔知识面的任务。在技术调研、方案对比分析上，Gemini 往往能提供更全面的视角。
- Codex： 在代码 Review 方面享有良好口碑，可以用于检查代码规范、潜在 Bug 或提出优化建议。其对代码结构和逻辑的理解能力, 基本上每次都能 review 出一些有价值的问题。
- Claude Code： 在代码编写方面暂时表现突出，在编写技术文档方面也表现不俗，在技术文档编写上我也经常使用它。
合理利用不同 Agent 的长处，可以构建更高效、更专业的开发工作流，在不同 Agent 上进行 deepresearch 或者 review 与 SubAgent 类似，任务独立同时避免干扰其他 Agent 的上下文。
5.5 超越概念：把握 Agent 设计哲学与 LLM 本质
当前 Agent 领域新技术概念层出不穷，如 MCP、Skills、Rules、Slash Command、Speckit、OpenSpec、Kiro 等等。面对这些快速迭代的概念，我们不必过于关注其表象，而应回归到其背后的 Agent 的设计哲学和 LLM 的本质。
- 避免概念陷阱： 这些新概念往往是解决特定问题或提升 Agent 某种能力的具体实现。它们可能随技术发展而演变、合并甚至消亡。过度追逐概念本身，容易让我们迷失方向，投入不必要的精力。重要的是理解它们试图解决的问题以及背后的技术原理。
- 理解本质： 核心在于如何发挥 LLM 的优势（强大的理解、生成、推理能力）和抑制其劣势（幻觉、上下文限制）。Agent 的设计哲学, 个人极其尊崇 Anthropic，Agent 要以人作为设计目标。无论外层概念如何变化，其底层都应服务于提升 Agent 的自主性、可靠性和解决问题的能力。
- 以 MCP 为例： MCP 统一工具协议并支持远程调用，到现在也火的一塌糊涂，但常驻上下文会带来 Token 消耗过大问题。对于上下文窗口较小的模型，一个 MCP 可能就占据了大部分推理空间，即使上下文窗口不断增加，常驻无用信息仍然是硬伤。后续无论在使用方式或者协议本身，都可能会继续迭代优化或者被其他新概念所取代。
- Skills： 相较而言，**Skills（技能）**的概念更符合 Agent 更趋向于人的设计哲学，但是具体的设计方式包括组织为 description、 script、 resource 等方式有待商榷。
VI. 结论与展望
本文对高效利用 Coding Agent 进行规约驱动开发 (SDD) 进行了全面深入的探讨。我们从大型语言模型 (LLM) 的基本原理、幻觉现象及其缓解策略、以及上下文窗口的限制与管理技术入手，为我们高效使用 Agent 完成任务，提炼出了"指令明确，信息充分"和"留足推理空间"两个核心指导原则，并分享了这些指导原则在实际开发项目中的实践，以及是如何在 SDD 的需求分析、技术设计、代码实现和测试迭代等各个阶段在指挥 Agent 完成任务。
我们需要具备对 LLM 本质的理解，掌握有效的上下文管理技巧，减少幻觉现象，警惕 Agent 的"疲劳"和"隧道效应"，并策略性地选择和运用不同 Agent 的优势。同时，面对层出不穷的新技术概念，我们应保持批判性思维，超越概念表象，聚焦于Agent 设计哲学，才可以更好地发挥 Agent 的优势并规避其局限。
展望，Coding Agent 技术将持续演进，朝着更智能的方向发展。掌握与 Agent 高效协作的能力，将是未来软件工程师必备的核心竞争力。我们应保持对新技术的开放心态，坚守对技术本质的学习和理解，才能避免在乱花渐欲迷人眼的新技术中迷失方向，才能在智能时代稳健前行，创造更具价值的产品。当然这种巨大的生产力变革（类似于人工到自动化的变革），所带来的程序员核心能力变化、个人发展方式、方向等变化，软件开发成本变化造成的技术普及方面的变化都是一些有意思的话题。