过去一段时间，我系统学了一轮 Agent 开发的基础知识。
我现在能够理解并解释一条 Agent 的基本链路：模型如何生成意图，Runtime 如何校验和执行工具，messages 如何回填，状态和上下文如何保存，以及 RAG、MCP、Eval、Guardrails 和 Trace 分别解决什么问题。
我也写过一些 Demo，用它们验证过真实 API、Tool Calling、Agent Loop、RAG、状态恢复、人工确认和评测链路。
所以，我给自己的定位是：
我已经完成了一轮 Agent 开发基础学习，但工程实践主要还停留在 Demo，正在从"知道它怎么工作"走向"把它真正落地"。
我想选择的第一个真实场景，是文字创作。
Demo 能证明我看懂了链路，但还不能证明我会落地
Demo 的好处，是可以把复杂链路拆开，每次只观察一个问题。
我可以单独验证：
- 模型返回 Tool Call 后，究竟是谁执行工具；
- 工具结果怎样重新进入 messages；
- 循环到达上限时，Runtime 应该在哪里终止；
- 没有用户确认时，写入工具怎样被确定性拦住；
- Eval 如何用 expected 对照 Trace 中真正发生的 actual。
但真实的文字创作不会只出现一个这么干净的问题。
一个创作 Agent 需要同时处理角色、设定、时间线和大纲；需要知道几十章内容中哪些必须保留；还要面对更麻烦的问题：这次修改究竟让文字变好了，还是只让内部评分变好看了？
当评审和修改开始反复循环，系统还必须知道什么时候应该停止，怎样保留较好版本，以及如何承认当前结果没有收敛。
这些问题不可能靠再写一个通用 Loop Demo 得到答案。
昨天的学习，是一次落地前复习
昨天我没有从头学习 Agent Loop，也没有完成一个新 Agent。
我做的是落地前复习：重新检查已经学过的概念有没有变得含混，然后把它们放到"如何做一个文字创作 Agent"这个具体问题中重新判断。
为了不把复习变成从头再听一遍理论，我做了一轮快问快答。现在回头看，其中有些答案说明基础已经建立，有些答案则暴露了我仍然会把相邻概念混在一起。
如果你也觉得自己已经理解 Agent，不妨先别急着往下看，试着回答这几个问题。
模型发起 Tool Call 后，到底是谁执行工具？
我的答案是：Runtime。
LLM 并不会真的去读文件、调用接口或修改数据。它只根据工具定义返回一个结构化的调用意图；真正负责参数校验、权限判断、工具执行和结果回填的，是模型外部的 Runtime。
这个问题我答得很快。它也让我确认，过去学过的 Tool Calling 并没有只剩下几个名词，我对最基本的职责边界仍然是清楚的。
Chatbot 和 Agent 的区别，是不是一个只能回答、一个可以调用工具？
我的第一反应接近这个说法：Chatbot 主要负责文字回答，Agent 则能调用工具并产生真实动作。
但这个答案把"能力差异"说成了"本质差异"。Chatbot 同样可以接入工具，Agent 也不一定每次都要产生副作用。更关键的区别是：谁在主导流程。
在典型 Chatbot 中，人提出一个问题，模型完成一次回应，下一步仍由人决定；在 Agent 中，模型会在目标约束下持续判断下一步是回答、调用工具、读取结果、修正计划，还是停止。
我后来把答案改成了一句话：
Chatbot 通常由人推动每一步，Agent 则把一部分连续决策权交给模型。
这次改口看起来很小，却直接影响系统设计。因为一旦把下一步决策交给模型，终止条件、权限边界、失败恢复和过程可观测性就不再是附加功能，而是系统的一部分。
如果修改一轮后，问题反而更多，Loop 还要继续吗？
我的答案是：不能因为流程里写着"继续修改"就盲目循环。
达到最大轮数、任务已经成功、继续运行没有明显收益，或者结果开始恶化，都可以成为停止条件。尤其在文字创作里，评审发现的问题并不一定会稳定地从多变少：一次修改可能解决两个问题，又引入三个新问题。
所以 Loop 不能只会"再来一轮"。它还需要保存较好版本、比较变化、限制资源，并在无法收敛时把决定交还给人。
这个问题也让我看到，通用 Agent Loop 只是骨架。真正困难的是把"没有继续收益"翻译成特定场景中可以观察、可以执行的判断。
Prompt caching 缓存的是全部聊天记录吗？
这道题我最初答偏了。我把它理解成模型厂商替应用保存越来越长的历史上下文，因此还担心缓存会无限增长。
更准确地说，prompt caching 是服务商对重复 prompt 前缀进行复用。应用仍然要在请求中组织上下文，也仍然需要处理裁剪、摘要和状态保存；缓存优化的是重复计算的延迟与成本，并不会替我解决长期记忆问题。
这类误解很危险，因为两个概念都和"以前的信息还能不能用"有关，却分别属于推理优化和上下文工程。名字记住了，不代表边界真的分清了。
流式 Tool Calling 的坑，只是界面上断断续续吗？
我开始想到的是等待体验，以及"先展示还是先审核"的安全取舍。方向不算完全无关，但没有击中真正的工程问题。
流式响应里，文本和工具调用块可能交错出现，工具名与参数也可能被拆在多个 chunk 中。Runtime 如果看到半截参数就开始执行，得到的可能是无法解析的 JSON，甚至是一次错误调用。
所以 parser 必须先识别 block 类型，持续累积工具参数，确认完整的 tool_use 结束后再校验和执行。流式输出不是简单地把完整答案切成许多小片，它会改变 Runtime 读取模型结果的方式。
几十章内容，能不能全部塞进上下文？
我的直觉是不要全塞，而要通过摘要、状态和按需检索，只组装当前任务真正需要的信息。这个方向是对的，但理由不只是"可能超过上下文窗口"。
即使物理上塞得下，大量低相关内容也可能淹没关键信号，增加成本，并让模型的注意力被稀释。对长篇创作来说，比"有没有放进去"更重要的是：哪些设定必须常驻，哪些信息按当前章节装配，哪些原文只有出现冲突时才需要取回。
这几个来回没有推翻我原来学过的 Agent 基础。相反，它们帮我区分了两件事：我能复述一个概念，和我能在真实设计中用对这个概念，并不是一回事。
先分清我在选择哪一层
快问快答之外，另一个被纠正的问题，是我把不同层级的工具放在了一起比较。
我原来同时在看 Pi、Hermes、LangChain、LangGraph 和 Pydantic AI，然后问自己：到底应该选哪一个？
但它们不是同一层的备选项。
Pi 和 Hermes 更接近可直接使用的 Agent 或 Harness 实现；LangChain 是 Agent 框架，LangGraph 更偏低层编排 Runtime，Pydantic AI 则把自己定位为 Python AI SDK。"fork 一个完整实现"和"用框架或 SDK 构建自己的 Agent"，本来就不是同一个问题。
这些内容不会让我"再毕业一次"。它们的价值是，在真正开工前把认知边界重新对齐，避免一开始就在错误的层级上做选型。
我准备先做一条真实的最小链路
复习以后，我不再把目标设成"再写一个 100 行 Agent Loop"。
Loop 已经学过，也已经通过 Demo 验证过。这次真正要验证的，是我能不能把它放进文字创作场景，组成一条有实际输入和输出的最小链路：
text
具体创作目标
→ 组装必要的创作资产和上下文
→ 模型生成内容或请求工具
→ Runtime 校验并执行
→ 保存输出、版本和 Trace
→ 由真实使用结果判断是否有用这条链路的底层 Loop、工具回填、错误恢复和终止条件，可以直接复用前面学过的知识和已验证积木。
真正需要新增的，是文字创作自己的领域问题：创作资产如何组织，长上下文如何压缩，修改前后如何比较，什么结果算是变好，什么情况必须停止。
我也不打算在第一版里同时堆上子 Agent、MCP、RAG、长期记忆、复杂状态图和多轮评审。
这些能力将来都可能有用，但应该等第一条真实链路暴露出需求后再加入。框架也应该根据真实复杂度选择，而不是为了证明自己会用某个工具。
从学基础到做落地
昨天我还没有写下文字创作 Agent 的业务代码。
这次学习的产出，不是一个可运行的项目，而是一条更准确的起跑线：我知道哪些基础不需要重学，哪些概念需要重新校准，也知道第一版不应该装进太多能力。
下一步，我要选一个具体的文字创作任务，让它真正产生内容，保留过程和版本，然后由我自己判断它有没有完成目标。
如果结果不好，就回到 Trace、上下文和评测标准里找原因，而不是继续学新名词，或指望再换一个框架就能自动解决问题。
我已经有了 Agent 开发的基础地图。
现在，该开始验证这张地图能不能带我走进真实场景了。