当 Coding Agent 已经足够快，一晚上能替你写几千行代码，真正的问题就变了：不再是"它写不写得动"，而是"它写出来的是不是你要的"。很多人第一反应是 vibe coding 那种玩法——丢一个"给我一个按钮"的 prompt，看结果，挑毛病，再让 agent 重来，循环到满意为止。对按钮它挺好使，对一个要维护一年的项目，它留下的是一长串没保存的对话历史，和一堆一次性代码。 规范驱动开发（

一、为什么要给 RAG 一张图 1.1 纯向量检索的两个短板 向量 RAG 的标准流程大家都熟：文档切块（chunk）、每块算嵌入（embedding）、问题也算嵌入、按余弦相似度捞回最相近的几块，塞进 prompt 让 LLM 作答。这套流程在课程里先跑了一遍：NetApp 的 10-K 文件，Item 1 章节切成 254 块，全部写入 Neo4j 并建好向量索引，套上 LangChain 的

一张四行的太阳镜库存表，字段是 id / name / description / price / stock。顾客问：「有 100 美元以下、还有货的圆框墨镜吗？」表里没有「圆框」这一列，这个词埋在 description 的自由文本里；有没有货在 stock 列，贵不贵在 price 列。开发者当然可以把「查描述 → 查库存 → 查价格」这三步写死进代码，但下一个顾客问「我上个月退的那副处理好

一、先做出原型，再谈评估 1.1 别空想几周，先做个能跑的 构建 Agentic 系统最难的地方在于，你没法提前知道它在哪些输入上会工作得很好、在哪些输入上会翻车，也就不知道力气该往哪儿使。所以常见的建议是：先做一个快而糙的原型，跑一遍，看它在哪里表现不如意，再集中精力改进。反过来，坐在那里推演几周该怎么做，通常是更差的选择。 关键前提是：这个原型要安全、负责任地做，不能泄漏数据，在这个底线上越快

本文内容整理自吴恩达（Andrew Ng）《Agentic AI》课程模块3「工具使用」 LLM 只会生成文本 token，它凭什么能查数据库、发日历邀请、跑一段 Python？答案是它压根不执行任何东西。工具使用（tool use）的真实链路是：LLM 按约定格式输出一个调用请求，宿主代码解析这个请求、真正执行函数、把返回值写回对话历史，LLM 再基于这段历史继续生成。「请求—执行—回填」这个三

一、反射设计模式：让 Agent 审视自己的输出 1.1 从人类反思到 LLM 反思 人写东西很少一遍到位。草稿写完回头看，会发现日期不明确、用词不准、漏了签名，改完再发。这个「写完 → 审视 → 修改」的过程就是反思（reflection）。 LLM 也能走同样的流程。与其让它一次生成最终答案，不如分两步：先生成初稿，再让它以另一个提示词审视初稿、指出问题、写出改进稿。课程里用邮件举过例子：约朋

本文内容整理自吴恩达（Andrew Ng）《Agentic AI》课程模块1（共 8 节） 一、从一次性单向生成到 Agentic 工作流 1.1 一次生成的问题（直接调用裸模型思考） 今天大多数人用 LLM（大语言模型，接收提示、逐词生成文本的模型）的方式，相当于要求一个人从第一句写到最后一句，中途不许回头、不许查资料、不许改。人在这种约束下写不出好东西，因为输出顺序必须一次就对。 模型也一样。

一、问题：摘要没错，执行却跑偏 1.1 现象：上下文摘要准确无误，Agent 却越执行越偏 面试里经常会问一个看似矛盾的问题：上下文摘要明明没有丢事实，Agent 为什么越执行越偏？ 用一个数据任务举例：从订单表查出本月已支付订单并生成汇总报表。原始上下文里还有几条执行要求：分页查询，每页 1000 条；逐批处理，直到没有下一页；只能访问只读副本库；SQL 超时 30 秒；失败重试不超过三次。 经