KeyChan's Notes

本文会从前面两篇的“模型与提示词”转向“如何重新组织开发工作流”。要回答的问题也随之变化：不再讨论 prompt 为什么有效，也不再停留在 agent 的结构拆解，而是更进一步——当 agent 进入复杂项目之后，真正决定效果的，为什么不再是“模型能不能生成代码”，而变成了 上下文如何构建、规则如何定义、执行流程如何被组织。

从这个视角看，IDE 也在发生变化。它不再只是一个 editor，而正在演变为一个复合系统：LLM + repo context + code search + prompt system + tools。问题的核心，也从“如何写代码”转向“系统如何理解整个代码仓库”。围绕这个变化，本文会依次展开几个关键问题：界定 AI 原生 IDE 的系统边界；并且说明它如何围绕任务构建 repo context；讨论为什么“长上下文”并不是万能解法，以及为什么复杂任务必须依赖 intentional compaction 与 spec-driven workflow；最后在工程实现层面，分析 prompt layer、插件系统与 IDE agent 在整体工作流中的位置。

本文承接上一篇关于 Prompt → Agent 的讨论，关注点从“prompt 为什么有效”转向一个更贴近工程的问题：当模型开始具备读取文件、遍历目录、修改内容乃至连接外部服务的能力时，一个 coding agent 本质上是由哪些部分构成的。

本文将从最小可用结构入手，逐步拆解 agent 的组成；再结合两个案例，说明工具接入如何从“本地函数注册”演进为“协议化服务”；最后补充认证机制、registry 与 tool design 等关键要素——这些才是真正决定系统能否走向工程化的核心因素。

如果用一句话概括本文的中心思想，可以这样表达：Coding Agent 不是“会写代码的 LLM”，而是一个能够感知环境、调用工具、维护状态，并在循环中持续执行任务的系统。

本文作为 AI协作工程 系列的起点，想回答的不是“有哪些好的 AI 编码工具”，而是一个更基础的问题：当 Coding LLM 进入开发流程之后，软件开发到底是怎么被重新组织起来的。全文会围绕三个主题展开：先界定 Coding LLM 为什么不同于普通聊天模型，再解释为什么理解 LLM 的工作机制 是学习 prompt 的前提，最后通过 Ollama、本地模型和三个小案例 few-shot、chain-of-thought、tool calling，说明 agent 更适合被理解为 prompt 工程进一步工程化之后的结果。

1. 从模型能力到系统能力

在过去几年中，大模型在自然语言理解、代码生成、知识问答等领域展现出惊人的能力。随着参数规模持续扩大，模型在零样本与少样本场景中的表现不断提升，许多任务甚至无需额外训练即可获得可用结果。然而，在真实的企业场景与复杂系统环境中，一个基础大模型往往并不足以支撑稳定、可靠、可控的智能应用。

问题并不在于模型“不聪明”，而在于模型的能力边界与实际需求之间存在结构性差距。大模型擅长语言模式建模，却不天然具备长期记忆、稳定执行、多工具协同、成本可控等系统级能力。因此，真正的挑战不是构建一个更大的模型，而是设计一套完整的模型增强系统。

1. 语言模型视角下的 Prompt 本质

大模型的能力往往会被归因于参数规模、数据规模与算力规模的增长。然而，在实际应用中，同一模型在不同提示语下所表现出的能力差异，常常远超不同模型之间的差距。这一现象揭示了一个关键事实：提示语并非简单的输入文本，而是对模型行为进行条件控制的重要机制。

要理解 Prompt Engineering 的逻辑，首先需要回到语言模型的基本形式，从概率建模的角度重新审视提示语的作用机制。本章将从自回归建模出发，分析 Prompt 如何改变输出分布，解释 In-context Learning 的可能原理，并讨论提示优化的能力边界。

1. 环境感知：无人机“看到”的到底是什么

自主飞行系统的智能程度，首先受限于其对环境的感知能力。无论后续定位、规划或控制算法多么复杂，如果输入的信息本身不稳定、不完整或不可用，系统整体都将建立在不可靠的基础之上。因此，在讨论自主飞行之前，有必要首先厘清一个核心问题：无人机在工程意义上究竟“看到”了什么，又能在多大程度上信任这些信息。

与人类直觉中的“看见”不同，无人机的环境感知并非对现实世界的直接理解，而是通过一组传感器对物理量进行采样、处理与抽象后的结果。这种结果往往是不完整的、带噪声的，且强烈依赖具体应用场景。本章将从工程角度出发，系统性地分析自主飞行对感知信息的真实需求，不同传感器所提供的数据特征，以及在实际系统中感知模块的布置原则与失效风险。

1. 本篇定位与调试假设声明

飞行调试与性能优化是无人机从“能够起飞”走向“工程可用”的关键环节。在完整的无人机系统中，飞控算法、机械结构、动力系统、传感器与电源并非孤立存在，其飞行表现是多系统耦合后的综合结果。因此，飞行调试并不是单纯的参数修改过程，而是一项具有明确边界、假设前提和验收目标的系统工程活动。

在展开具体调试方法之前，有必要首先明确本篇的适用范围、研究对象以及隐含假设。这不仅有助于统一技术语境，也能避免在实际工程中对调试能力和调试目标产生不合理预期。

1. 语言模型的起点：自回归建模范式如何成立

很多人在第一次接触 GPT 时，往往会把注意力放在“模型越来越大”这件事上，好像只要参数足够多，能力自然就会出现。但如果只从规模的角度理解 GPT 的起点，很容易忽略一个更根本的问题：语言模型究竟在学什么？又是如何把人类语言转化为一个可以被训练、被优化的对象？

这一章并不从复杂的结构或数学公式讲起，而是回到语言模型最原始、也最朴素的任务定义。正是这个看似简单的起点，最终支撑起了 GPT 系列后续所有的能力扩展。

1. 从早期跨模态学习到 CLIP：视觉和语言对齐是如何发展的

在 CLIP 出现之前，让计算机同时“看懂图像、理解文字”，其实已经是一个被研究了很多年的问题。只要稍微想一想就能明白：如果模型既能处理图像，又能处理语言，那它就有可能完成图文搜索、图片描述、视觉问答等各种任务，这听起来非常有吸引力。

也正因为如此，计算机视觉和自然语言处理领域的研究者，早早就开始尝试“跨模态学习”，也就是把图像和文本放在同一个模型里一起建模。然而，有些尴尬的是：这些方法虽然在论文里能跑出不错的结果，但很难真正变成一种稳定、通用、可以长期复用的基础能力。模型往往是“为某个任务量身定做的”，而不是“可以反复拿来用的工具”。

1. 引言：自监督学习，真的能“看懂”图像吗？

在很长一段时间里，计算机视觉的进步，几乎完全依赖一种方式：监督学习。简单来说，就是给模型大量图片，再告诉它“这是什么”，让它不断做题、纠错、记答案。

ImageNet 分类、COCO 检测与分割，这些经典成果，都是在这种模式下取得的。只要数据够多、标签够准，模型的分数就能不断刷新。但随着模型越来越大、应用场景越来越真实，这条路开始遇到问题了：

• 标注图片成本很高
• 真实世界并不总是“有标准答案”
• 模型在新场景下，经常表现失常