本文承接前四篇关于 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 工程进一步工程化之后的结果。
自主飞行系统的智能程度，首先受限于其对环境的感知能力。无论后续定位、规划或控制算法多么复杂，如果输入的信息本身不稳定、不完整或不可用，系统整体都将建立在不可靠的基础之上。因此，在讨论自主飞行之前，有必要首先厘清一个核心问题：无人机在工程意义上究竟“看到”了什么，又能在多大程度上信任这些信息。
与人类直觉中的“看见”不同，无人机的环境感知并非对现实世界的直接理解，而是通过一组传感器对物理量进行采样、处理与抽象后的结果。这种结果往往是不完整的、带噪声的，且强烈依赖具体应用场景。本章将从工程角度出发，系统性地分析自主飞行对感知信息的真实需求，不同传感器所提供的数据特征，以及在实际系统中感知模块的布置原则与失效风险。