本文承接上一篇关于 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 工程进一步工程化之后的结果。
自主飞行系统的智能程度，首先受限于其对环境的感知能力。无论后续定位、规划或控制算法多么复杂，如果输入的信息本身不稳定、不完整或不可用，系统整体都将建立在不可靠的基础之上。因此，在讨论自主飞行之前，有必要首先厘清一个核心问题：无人机在工程意义上究竟“看到”了什么，又能在多大程度上信任这些信息。
与人类直觉中的“看见”不同，无人机的环境感知并非对现实世界的直接理解，而是通过一组传感器对物理量进行采样、处理与抽象后的结果。这种结果往往是不完整的、带噪声的，且强烈依赖具体应用场景。本章将从工程角度出发，系统性地分析自主飞行对感知信息的真实需求，不同传感器所提供的数据特征，以及在实际系统中感知模块的布置原则与失效风险。
在 CLIP 出现之前，让计算机同时“看懂图像、理解文字”，其实已经是一个被研究了很多年的问题。只要稍微想一想就能明白：如果模型既能处理图像，又能处理语言，那它就有可能完成图文搜索、图片描述、视觉问答等各种任务，这听起来非常有吸引力。
也正因为如此，计算机视觉和自然语言处理领域的研究者，早早就开始尝试“跨模态学习”，也就是把图像和文本放在同一个模型里一起建模。然而，有些尴尬的是：这些方法虽然在论文里能跑出不错的结果，但很难真正变成一种稳定、通用、可以长期复用的基础能力。模型往往是“为某个任务量身定做的”，而不是“可以反复拿来用的工具”。