KeyChan's Notes

这篇文章的关注点从“如何让 agent 动起来”，转向一个更实际的问题：当实现成本被压低之后，质量如何被保证。

随着 AI 让代码生成和命令执行变得越来越容易，效率瓶颈开始明显转移——难的已经不再是写出来，而是验证有没有问题、能不能上线。也正因为如此，重点不再只是 AI coding，而是 AI coding + AI testing + AI security 的整体能力。

本文承接前四篇关于 Prompt、Coding Agent Anatomy、Context Engineering 和 Agent Governance 的讨论，但关注点继续前移，不再停留在系统如何设计，而是落到一个更实际的问题：当 agent 真正开始执行任务时，动作到底发生在哪里。

前面几篇解决的是“怎么让系统动起来”，而这一篇关心的是：一旦开始跑命令、查环境、串脚本、推进多步流程，这些动作由哪个界面承接。答案其实很直接——是 terminal。构建、测试、部署、日志、脚本，本来就发生在终端里，只要进入执行阶段，terminal 就会成为最接近现场的位置。

本文承接前面对 Prompt、Coding Agent Anatomy 与 Context Engineering 的讨论，但将视角从执行机制进一步上移到协作治理层。前面分别解决了三个问题：模型行为如何被 prompt 影响、agent 如何通过 tools 与 loop 完成执行闭环，以及在复杂任务中，spec、context 与 workflow 为什么不可或缺。

在此基础上，一个更现实的问题开始出现：当 agent 已具备较强执行能力时，开发者应赋予它多少自主权？又该如何在放权与控制之间建立边界？因此，本文不再讨论“如何让 agent 做事”，而是讨论：如何让 agent 在可控范围内做事。

本文会从前面两篇的“模型与提示词”转向“如何重新组织开发工作流”。要回答的问题也随之变化：不再讨论 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. 本篇定位与调试假设声明

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

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