第一次被 ChatGPT 震到的时候，很多人应该都还在研究 Prompt 怎么写。那时候它更像一个会聊天的知识库。你问，它答；你不问，它也不会自己动。三年过去，AI 已经不只是在聊天框里回复文字了。它开始会调用工具，会读文件，会跑代码，甚至能操作电脑界面。
再往前走一步，就是现在大家反复提到的 AI Agent。
OpenAI 有 Assistant API，Anthropic 有 Claude Agent，Coze、Dify 这类低代码平台也都在围绕 Agent 做能力封装。热度确实高，但很多人聊 Agent 时容易把概念讲得特别玄。
这篇会把 AI Agent 拆开讲清楚。全文接近 7000 字，主要看这几块：
长任务一跑起来，很快就会撞到几件硬约束：上下文窗口有上限，Token 账单会一路涨，Session 结束后如果没有落库，上一轮轨迹默认就跟进程一起消失。很多时候不是模型不够聪明，而是它没有一套能挂载历史记录的记忆层。
记忆层要解决两件事：当前这轮对话里，关键事实别丢；隔几天再开一个新 Session 时，还能把与用户相关的偏好、背景和历史决策捞回来。下面会按记忆的表征和功能分类、读写生命周期、短期和长期实现、主流产品与检索优化、Markdown 记忆这几条线展开。滑动窗口怎么裁、overload 怎么卸，和同站的 《上下文工程实战指南》 有交集，两篇可以对着看。
你好，我是小 G。现在这个时候再去聊 Context Engineering，很多朋友内心 OS 是：还有必要吗？这不老掉牙的概念了么？
毕竟 DeepSeek-V4、GPT-5.5、Claude Opus 4.7 这些模型，上下文窗口都干到 1M 级别了（当然具体能用多长取决于不少因素）。
窗口这么大，把项目资料多塞一点进去，让模型自己看不就完了？
说实话，我之前也是这么想的。但后来实际去深入了解了才发现，根本不是这么回事。
Agent 每次调用 LLM 之前，窗口里到底放了什么内容，放得干不干净，排的顺序对不对，工具描述写得够不够清楚——这些东西对最终效果的影响，远比很多人想象的大。
别只盯模型。
很多人第一次做 Agent，直觉都是先买更贵的模型。结果模型换了，Agent 还是会重复犯错，做到一半放弃，上下文一长就开始不稳定。这个时候继续调 Prompt，收益往往也很有限，因为问题可能根本不在模型本身。
有个实验挺能说明这件事：同一个模型，只换了文件编辑接口的调用方式，编码基准分数从 6.7% 跳到了 68.3%。模型没有变，变的是它外面那套系统。也就是说，Agent 能不能稳定干活，很多时候取决于模型之外的环境、工具、反馈和约束。
最近 AI Agent 开发圈里经常提到一个词：Harness Engineering。它讨论的就是这件事：决定 Agent 表现上限的，可能不是模型，而是你给模型搭的那套工作环境。
这几天 Loop Engineering 突然火起来，我第一反应是：这又是哪个新名词？怎么天天造新词？
看了一圈之后，感觉它确实有点新瓶装旧酒。Agent Loop、Workflow Graph、Context Engineering、Skills、MCP、CI、测试验证，这些东西 JavaGuide 之前其实都聊过。换个名字重新包装一下，味道很熟悉了。
代码 Agent 真能连续读文件、改代码、跑命令、处理 PR 之后，我们确实不能只盯着“下一句 Prompt 怎么写”。以前是人守在对话框前，一轮一轮补充提示；现在越来越多任务会由 /loop、/goal、CI、PR 评论或者定时任务触发。Agent 被叫醒后自己读材料、跑命令、写状态，卡住再把问题抛回来。
做 LLM 应用时，我一开始也以为最麻烦的是模型接入。
后来发现不是。OpenAI、Claude、DeepSeek、Qwen 这些模型虽然接口不完全一样，但各家 SDK 已经把很多细节包掉了，真要接起来并不算特别难。更烦的是工具。
比如同样是“让 AI 读本地文件、查 GitHub、连数据库”，在 Claude Desktop 里要配一套，在 Cursor 里可能又是一套，自己做 Agent 时还得再封一层。工具少的时候还能忍，工具一多，维护成本就开始上来了：参数变了要改，鉴权变了要改，宿主换了还要改。
MCP 解决的就是这类问题。
它不是让模型变聪明，也不是替代 Function Calling，更不是新一代 Agent 框架。它更像一套接线规范：外部系统把能力封装成 MCP Server，支持 MCP 的 AI 应用连接上来之后，就能发现这些能力并调用。
很多朋友在写 Prompt 的时候，都会犯一个毛病：恨不得把所有背景、要求、限制都塞进去。
看起来很详细，但效果不一定会好。Prompt 太长，模型反而容易抓不住重点。上下文里噪声一多，幻觉概率会上来，推理也会变慢。
Prompt 写得好不好，不在于你写得够不够多，重要的是把边界要讲清楚。
通过阅读这篇文章，你可以搞懂下面这些问题：
团队里有套完整的代码审查规范，想让 Claude 按这个来 review。最直接的做法是每次粘到 Prompt 里——它倒是照做了，但下次换个会话，换个同事，又得粘一遍。
后来有人说放进 AGENTS.md，情况好一些，但又不知道该放多少合适：规范太长了模型会不会忽略中间那几段？哪些约定是全局的，哪些只在某类任务里才有用？
这类问题，Agent Skills 正好能接住。
本文接近 9000 字，建议收藏，通过本文你将搞懂：
刚上手 AI 工作流时，很容易有类似的困惑——这不就是传统工作流换了个壳吗？为什么不用 Camunda、Temporal 这些成熟引擎？甚至觉得把几个 Prompt 用 if-else 串起来就算“工作流”了。
但真正上手做项目后，这些想法很快会被现实打脸。LLM 的输出天然不确定，单次生成往往不达标，工具调用随时可能失败，上下文窗口还有硬上限。光“跑一遍就完事”的线性流程不够用，你需要的是一套能动态决策、自动修正、可控收敛的执行机制。
今天这篇文章就来系统梳理 AI 工作流中三个核心概念——Workflow、Graph、Loop，帮你建立从概念到实现的完整认知。本文接近 7300 字，建议收藏。通过本文你会搞懂：
很多 AI 应用的第一个版本都很“顺”：本地调通一个大模型 API，页面上能看到回答，Demo 就算跑起来了。
但一上生产，麻烦马上变得具体：
{"answer": "根因是。