MCP Server 不是银弹，但它为 AI 在生产环境的落地提供了一条清晰、可扩展。

而且，因为整篇系列是一个整体，所以有些概念的解读/学习会在不同的文章中出现，还请大家谅解。因此，在第 2 个批次及以后，所优化的轨迹都不是那个 model 自己生成的，而是上一个 step 的 model 生成的，这就引入了 off-policy。如果等所有任务完成再更新： → Task A在 policy v1 时生成，等待时变成 stale → 等 Task B完成，TaskA已经是30分钟前

现在，我们来加点难度，让 Codex 追一条更具体的路线：当用户写了一个 Typer 应用，并在终端里运行它时，代码大概会经过哪些关键步骤。Codex 这一步做的事情，就是先帮我们把项目拆开：哪些文件是入口，哪些目录是源码，哪些地方是测试，哪些地方是文档。这样一来，Typer 的核心代码就有了一条比较清楚的阅读路线：先看对外入口，再看主流程，然后看参数定义和内部数据结构，最后再进入底层命令行为。这

Agent 系统里的 Prompt 很少是一次写对的。更常见的情况是，线上 case 出错以后，人去翻日志、看工具调用、读模型输出，再手工改一版 Prompt 或 Skill，跑评测，分数涨了就先收下。这个流程能跑，但很累，也不稳定。最麻烦的不是“改不动”，而是改了 A 以后 B 退化。比如分类更准了，回复变得生硬；检索召回上去了，推理链路开始乱跳。只拿一个总分做判断，很容易把某些长尾能力一起丢掉