上篇完成了自动化网页研究总结器的前半段。它先从一个核心问题出发：当任务从“回答一句话”变成“完成一个研究流程”时，单次 Prompt 调用已经不够用。系统需要先理解问题，再拆解搜索方向，接入外部工具，并在多个中间结果之间保持稳定的数据结构。
围绕这个目标，上篇先解释了 LCEL 的价值：它不是为了让代码写得更短，而是为了让 LLM 应用里的数据流、组件边界和执行顺序更加清楚。Prompt -> LLM -> Parser 是最基础的链式结构；当流程变复杂后，还可以通过 RunnableLambda 接入普通函数，通过 RunnableParallel 保留上下文和并行分支，通过 .map() 批量处理列表数据。
本文以 Manthan Gupta 的两篇逆向分析为线索，对比 ChatGPT 与 Claude 的记忆机制。核心问题不是谁“记得更多”，而是：面对同一个跨会话连续性问题，两者为何选择不同的系统路径。
文中将记忆问题还原为上下文工程问题，并指出两种典型方案：ChatGPT 的预注入式连续性，以及 Claude 的按需检索式连续性。两者差异本质在于：过去信息是在一开始就引入，还是在需要时再引入。
这篇文章承接前八篇关于 Prompt、Coding Agent Anatomy、Context Engineering、Agent Governance、Terminal Execution、Testing / Security、Code Review 和 Prompt-to-App 的讨论，但会把焦点进一步推进到生产运行层。
要回答的问题已经不再是“怎么生成、怎么执行、怎么验证”，而是：当系统越来越快被做出来并上线之后，谁来持续维护它，出了问题如何更快搞清楚发生了什么。
本文承接前七篇的讨论，从“如何生成、执行与维护”，进入“如何被用户感知和验证”。
当 agent 已经能写代码、跑流程、补测试并处理运行期问题后，这些能力如何被验证是否真的成立。也正是在这里，前端和设计不再只是实现末端，而是最早提供反馈的入口。
本文承接前六篇关于 Prompt、Coding Agent Anatomy、Context Engineering、Agent Governance、Terminal Execution 和 Testing / Security 的讨论，关注点从“如何生成与执行”，进入“如何把关质量”。
系统已经具备了写代码、跑命令、补测试、形成基本验证闭环的能力，但当这些能力逐渐稳定之后，并且在生成和执行都被加速的情况下，质量由谁来兜底。也正是在这里，code review 的位置被重新拉高。
这篇文章的关注点从“如何让 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 在整体工作流中的位置。