我挺喜欢的

这 10 篇我会按“建立直觉 → 做好单 Agent → 可靠运行 → 复杂系统”放进博客，而不是再拼成一门必须从头刷完的课程。 筛选依据是有没有具体实现、失败案例、工程取舍和验证方法，不是作者名气或阅读量。全部是原作者／团队的一手文章；下面标注原始发布时间，老文章只推荐其中仍有价值的方法，不把旧模型、价格和 SDK 写法当成当前标准。 一、刚入门：先理解自己在做什么 ① Building effective agents 来源：Anthropic Engineering｜2024-12-19 https://www.anthropic.com/engineering/building-effective-agents 适合：刚接触 Agent，分不清工具调用、工作流和自主 Agent 的开发者。 推荐原因：比如做客服系统，退款规则明确时，用固定流程可能比让模型自主规划更合适。文章从这类选择出发，拆解串联、路由、并行、协调者与执行者等模式，讲清楚什么时候增加复杂度、什么时候根本不需要 Agent。 它的价值不是“架构图大全”，而是帮助新人形成判断：业务需要多少自主性，就给多少自主性。 时效提醒：官网已经明确提示，文中的工具生态自发布以来发生了变化。这篇适合学架构判断，不适合当最新框架选型指南。 ② How to Build an Agent 来源：Amp｜Thorsten Ball｜2025-04-15 https://ampcode.com/notes/how-to-build-an-agent 适合：有基本编程能力，用过 Coding Agent，但不理解它怎么工作的读者。 推荐原因：作者用不到 400 行 Go 代码逐步构建一个代码编辑 Agent，把消息历史、模型调用、工具执行和结果回传直接摊开。读完能理解：模型不是亲自执行函数，而是提出工具调用，由程序执行后把结果交回去。 这篇值得选，是因为它用可检查的代码消除神秘感，而不是拿框架封装掩盖机制。 放进你的博客时建议标注为“原理拆解，可选实验”，不要变成“新人必须从零手写 Agent Loop”。文中的模型和 SDK 示例也需要按当前文档调整。 二、开始开发：把单 Agent 做扎实 ③ Writing effective tools for agents — with agents 来源：Anthropic Engineering｜2025-09-11 https://www.anthropic.com/engineering/writing-tools-for-agents 适合：已经接通工具调用或 MCP，但 Agent 经常选错工具、参数填错、结果读不明白的人。 推荐原因：文章用安排会议、排查重复扣款等真实复杂任务说明，工具不是把后端 API 原样包一层就结束。工具边界、命名、描述、返回信息和 token 开销，都会影响任务完成率。 更重要的是，它给出了“原型 → 真实任务评测 → 分析错误 → 修改工具 → 再评测”的闭环，而不只是教你写一段漂亮的工具描述。 这是我最建议新人做完第一个 demo 后立即读的一篇。 ④ Effective context engineering for AI agents 来源：Anthropic Engineering｜2025-09-29 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 适合：Agent 对话越长越不稳定，开始靠不断加系统提示词补漏洞的人。 推荐原因：比如客服 Agent 查了很多订单和历史对话，下一步并不需要把所有原始结果继续塞给模型。真正要设计的是：此刻需要哪些信息、哪些可以按需获取、哪些应该压缩或保留。 文章把系统提示词、工具、外部数据和消息历史放在同一个框架下讨论，解释为什么上下文工程不是“提示词写得更长”。 它提供的是一个能迁移到不同模型和框架的分析视角；具体裁剪、压缩策略仍要用自己的任务验证。 ⑤ Context Engineering for AI Agents: Lessons from Building Manus 来源：Manus｜Yichao “Peak” Ji｜2025-07-18 https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus 适合：单 Agent 已经能完成任务，开始优化延迟、成本和长轨迹稳定性的开发者。 推荐原因：它把上下文设计落到了具体工程细节。例如，在提示词开头放每秒变化的时间戳，会破坏后续前缀缓存复用；中途频繁改变工具定义，也可能影响缓存并让历史工具调用难以解释。 与上一篇互补：上一篇回答“该怎样理解上下文”，这篇回答“实现细节怎样影响运行成本和行为”。 值得保留作者自己的限定：这些是 Manus 在当时系统里找到的局部最优，不是普遍定律。尤其“尽量不动态增删工具”，不能直接推广为所有 Agent 都不该使用工具检索；文中的价格也只能作为历史示例。 三、准备上线：评测、安全与长任务 ⑥ Demystifying evals for AI agents 来源：Anthropic Engineering｜2026-01-09 https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents 适合：所有准备让真实用户使用 Agent 的开发者，不必等成为老手才读。 推荐原因：文中一个很关键的例子是，订票 Agent 说“已经订好了”，不代表数据库里真的存在预订。评测必须区分最终回答、执行轨迹和环境中的实际结果。 文章进一步明确任务、重复试验、评分器、轨迹和评测运行环境之间的关系，解释为什么同一道任务需要多次运行，以及为什么不能只凭几个成功截图判断改动有效。 这篇能直接帮助读者把“我感觉新提示词更好”变成可验证的工程结论，是整份清单的核心文章之一。 ⑦ Designing AI agents to resist prompt injection 来源：OpenAI｜2026-03-11 https://openai.com/index/designing-agents-to-resist-prompt-injection/ 适合：Agent 能读取网页、邮件、外部文档，或者能执行写入、发送、退款等操作的人。 推荐原因：文章给出邮件中夹带“合规验证”指令、诱导 Agent 外传员工信息的攻击案例。它说明危险内容不一定长得像“忽略此前指令”，也可能伪装成正常业务要求。 最值得学的是安全目标的变化：不能只追求识别所有恶意文本，还要通过系统能力边界限制被骗后的损失。就像客服即使被说服，也不应该能绕过系统规定无限退款。 这不是上线后再补的选修。只要接触不可信内容和真实操作，就应该提前读；它也不是一份能保证杜绝注入的完整安全方案。 ⑧ Effective harnesses for long-running agents 来源：Anthropic Engineering｜2025-11-26 https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents 适合：正在做跨多个上下文窗口、持续数小时任务的开发者。 推荐原因：文章拿构建一个完整 Web 应用做实验，展示两种具体失败：第一次想一次做完，做到一半上下文耗尽；下一次看到已有部分功能，就误以为任务已经完成。 解决方向不是再加一句“请坚持完成”，而是让初始化阶段建立环境和功能清单，后续每轮增量推进，并留下可交接的进度与版本记录。 它把 harness——模型外面的执行、状态和反馈机制——讲得很具体。尤其值得理解：上下文压缩并不等于可靠的跨会话任务交接。 四、有开发经验：重新设计工程环境与协作边界 ⑨ Harness engineering: leveraging Codex in an agent-first world 来源：OpenAI｜Ryan Lopopolo｜2026-02-11 https://openai.com/index/harness-engineering/ 适合：深度使用 Coding Agent，或者负责团队 AI 开发流程的人。 推荐原因：最值得看的是具体环境改造：为每个工作副本提供可独立启动的应用，让 Agent 通过浏览器检查界面，并能查询日志、指标和追踪信息。这样，“修复这个问题”才有条件变成“复现 → 修改 → 验证”的闭环。 与上一篇的区别是：上一篇重点解决跨会话如何接着干；这篇重点解决整个工程环境如何让 Agent 看得懂、操作得了、验证得出结果。 不要被“没有手写代码”和效率数字带偏：那是作者团队的实验报告，不是所有团队都能复制的收益。真正值得迁移的是环境设计和反馈机制。 ⑩ How we built our multi-agent research system 来源：Anthropic Engineering｜2025-06-13 https://www.anthropic.com/engineering/multi-agent-research-system 适合：单 Agent 已经做扎实，确实遇到并行调研或上下文容量瓶颈的人。 推荐原因：文章用同时查找多家公司的董事会成员等任务说明，主 Agent 怎样拆分调研方向、子 Agent 怎样独立检索并压缩结果，再交回主 Agent 汇总。 它没有只宣传“多个 Agent 更聪明”，也讲了 token 开销、协调困难和适用边界：天然独立的调研任务比较合适，大量共享上下文、依赖紧密的任务未必合适。 文中有主从委派与结果回传，是实质性的多 Agent 协作，不只是同时开几个 Agent 窗口。它的历史评测提升不能当成今天所有任务的通用增益。 放进博客的建议 入门正文先放①②，让读者理解机制，但不要要求先读完全部再动手。 第一个项目旁边放③④⑥⑦：工具、上下文、评测、安全，是单 Agent 最该优先补齐的四件事。 遇到成本问题再读⑤，长任务中断读⑧，团队开发流程读⑨，确实需要多 Agent 才读⑩。 这份清单里 Anthropic 占六篇，是因为这些文章确实提供了互不相同的工程细节，不是为了凑来源。不过它们仍是厂商的一手经验：值得学方法、看失败案例，不应把各家产品上的局部结论当作行业定律。