KeyChan's Notes

1. 大模型的知识边界与问答局限

很多 AI 应用在面对简单问题时往往表现不错。通过 Prompt 输入问题，大模型能够生成流畅且看似合理的回答，看起来已经具备知识助手的能力了。但如果进入真实业务场景后，这种能力边界就会逐渐显现。例如询问昨天刚更新的公司制度，或者追问内部文档中的具体细节，模型依然可能给出完整且自然的回答，但其中的信息并不一定准确。

原因是模型会说，不代表模型真的知道。 很多人第一次使用大模型时会产生一种错觉。模型回答流畅、表达自然、知识丰富，于是容易认为模型像数据库一样存储了大量事实，并且能够随时准确调用。

上一篇已经完成了一个基于 LCEL（LangChain Expression Language）的自动化网页研究总结案例。整个案例讲了如何把用户问题自动转换成结构化研究结果，流程并不复杂。

1

用户问题 → 选择研究助手 → 生成搜索请求 → 执行网页搜索 → 抓取网页内容 → 总结信息 → 生成研究报告

从工程角度看，这已经是一个完整闭环。系统能够自动完成角色选择、搜索、抓取、总结和报告生成，适合大量路径明确的信息收集任务。

1. 上篇回顾：从问题拆解到搜索词生成

上篇完成了自动化网页研究总结器的前半段。它先从一个核心问题出发：当任务从“回答一句话”变成“完成一个研究流程”时，单次 Prompt 调用已经不够用。系统需要先理解问题，再拆解搜索方向，接入外部工具，并在多个中间结果之间保持稳定的数据结构。

围绕这个目标，上篇先解释了 LCEL 的价值：它不是为了让代码写得更短，而是为了让 LLM 应用里的数据流、组件边界和执行顺序更加清楚。Prompt -> LLM -> Parser 是最基础的链式结构；当流程变复杂后，还可以通过 RunnableLambda 接入普通函数，通过 RunnableParallel 保留上下文和并行分支，通过 .map() 批量处理列表数据。

1. 为什么需要 LCEL：从单次问答到 AI 工作流

早期的LLM是一个简单的问答器，输入一个问题，拼接一段提示词，调用模型，然后返回结果。这种方式可以完成翻译、摘要、改写、问答等单步任务，但当从“回答一句话”变成“完成一个流程”时，单次调用就很难满足需求。

以“自动化网页研究总结”为例，目标不是简单回答一个问题，而是根据一个开放式问题，需要自动完成搜索、抓取、总结、整合和报告生成。比如输入：

本文以 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 就会成为最接近现场的位置。