Agent 最近这一年 系列二
为了仔细了解 Antropic 最近爆火的 Agent Skill，于是找来这一系列的文章仔细读了一遍，下面是这一系列的 6 篇文章介绍。
第一篇 Claude Code：智能体编码最佳实践
Anthropic 去年 4 月就已开始让大模型写代码。 Claude 在写代码这事儿上本身能力就很强，但去年4月，我并未留意它在做这件事。当时全力交付其他项目，竟把这件重要事忽略了。
智能体编码最佳实践 一文介绍了当时的Claude Code最佳实践。其核心观点可以概括为：深度定制上下文、灵活扩展工具链、先规划后执行、利用多实例协作，把Claude从代码生成器提升为工程伙伴。
多实例很好，多模型更好。
工具提供接近原始模型访问的低抽象接口，不强加固定模式，支持脚本化、自定义和安全控制。包括：通过 CLAUDE. md 文件记录项目命令、代码风格和开发环境，提高上下文质量；管理工具白名单和集成 Bash、MCP、REST API 及自定义命令；采用常见工作流如“探索-规划-编码-提交”、测试驱动开发、视觉迭代等；利用 GitHub/Git 交互、Jupyter 支持和安全版 YOLO 模式；优化协作方式，如明确指令、提供图片/URL、使用 /clear 清理上下文、Scratchpads 记录任务；以及多实例并行（多Claude、多工作区、headless模式）提升大型项目效率。这些技巧能帮助工程师在安全可控前提下提高效率。
第二篇：AI 模型的上下文
这篇 AI 智能体的高效上下文工程 发表于 2025 年 9月 29 日，是继提示工程之后，一种构建高效 AI 智能体的核心方法。相比只优化提示词，上下文工程关注在有限窗口中精挑并管理信息，即在每次推理前动态决定哪些信息进入模型的注意力预算，从而更高效地解决当前问题。
上下文越多，Token越多。模型的精确理解与推理能力会下降，因此需要系统化策略。如何精炼并结构化系统提示？如何挑选少量且高代表性的内容与示例？运行时如何按需检索？
提示词与上下文工程：
- 提示词是指为获得最佳效果而编写和组织大语言模型（LLM）指令的方法
- 上下文工程则指在 LLM 推理过程中，策划并维护最佳 token（信息）集合的一套策略，其中包括所有可能出现在上下文中的信息，而不仅限于提示内容本身。
模型虽强，注意力分散、理解混乱在所难免；如何让模型在海量信息中专注于当前任务？如何让大模型能够大海捞针，在海量信息中专注于当前任务，这是上下文工程关键要解决的问题。大模型的 Trasnformer 结构，导致了模型看到每一个 Token 就像群消息一样，几条消息很容易理解。但成千上百的群消息直接导致很多重要消息被稀释。那么越多的上下文，就越可能关注不到某些信息，这也就是注意力权重被稀释（attention scarcity）。在信息检索与长程推理方面尤甚。既然 LLM 的注意力容量有限，那么上下文工程的目标就是尽量用最少的文字，保留最具价值、最能影响结果的关键信息，从而达成用户期望的目标。
这太难了，写提示词谁都会，但写好的提示词很需要功力
不过这也是两个很好的提示词重写，可以让大模型帮你重写你的提示词：
| 中文提示词 | 英文提示词 |
|---|---|
| 用清晰、直接的语言编写系统提示：提供具体明确信号（约束、示例、成功标准），不假设共享语境；把握“合适的层次”，既足够具体以有效引导，又保有以可复用启发式为主的灵活性，避免脆弱的硬编码流程和空泛的高层指令。 | Write system prompts in clear, direct language that give concrete signals (constraints, examples, success criteria) without assuming shared context, and aim for the “right altitude”: specific enough to guide behavior yet flexible via reusable heuristics—avoiding brittle hardcoded workflows and vague high‑level instructions. |
太精确难泛化，太宏观不指导。
就像我们设计一个函数库一样：
- Self-contained: 独立运行，不依赖外部复杂流程。
- Robust to error: 容错能力强，输入不完美也能给出合理反馈。
- Descriptive: 名字和参数直观，便于理解和调用。
- Unambiguous: 没有多义性，减少误解。
- Play to the inherent strengths: 设计任务发挥LLM擅长的能力，让工具和模型互补。
文章特别强调提供示例，对大模型来说，示例胜过千言万语，如同图片更能说明问题。。
自Anthropic发布Agent指南起，其一直推动LLM在循环中自主使用工具。并且智能体能力越来越强，独立探索、从错误中恢复等能力日益精进。可以动态地把如文件路径、已存查询、网页链接等加载到上下文中，这和人类的思考和使用工具相似，不会记住所有的信息，而是使用工具来解决问题。
为了让智能体能够在更长时间跨度内高效运作，他们团队开发了一些直接应对上下文污染的技术：压缩处理、结构化笔记记录以及多智能体（multi-agent）架构。
- 上下文压缩是指上下文过长时，压缩并生成摘要上下文。也就是让 LLM 保留架构决策、未解决的 bug 以及实现细节，同时舍弃多余的工具输出或消息。关键在于：压缩是否能捕获先前工作的全部相关信息。迭代优化去除冗余内容，以提升精确度是关键。但压缩必定就会有丢失… 适用于需要频繁往返交流的任务。
- 结构化记录，践行‘好记性不如烂笔头’。创建待办清单、写入 md 文件都是有效的方法。适合具有明确里程碑、需进行迭代开发的场景。
- 子智能体负责专门任务，可进行深度探索，最终仅返回其工作的精炼摘要，大约 2000 tokens。主智能体专注综合与分析，子智能体专注具体任务。适用于复杂的研究与分析任务，并行探索提升效率。
第三篇：Claude 开发者平台推出高级工具使用功能
为说明Claude Code的发展，先谈开发者平台推出高级工具使用功能。2025年11月24日，Anthropic宣布新增三项测试功能，使 Claude 能够动态地发现、学习并执行工具。
- 工具搜索工具（Tool Search Tool）：允许Claude通过搜索访问数千工具，几乎不占用上下文窗口。
- 编程式工具调用（Programmatic Tool Calling）：允许Claude在代码执行环境中调用工具，从而降低对模型上下文窗口的影响 。
- 工具使用示例（Tool Use Examples）：为高效使用特定工具提供统一标准。
AI智能体的未来，是模型能够在工具之间实现无缝协作。但现实也很麻烦，很多工具在加载时就已经消耗很多的 Tokens，随便一加载十万 Tokens 就没了。
- GitHub：35 个工具（约 26,000 tokens）
- Slack：11 个工具（约 21,000 tokens）
- Sentry：5 个工具（约 3,000 tokens）
- Grafana：5 个工具（约 3,000 tokens）
- Splunk：2 个工具（约 2,000 tokens）
工具搜索工具的核心：按需加载。只预加载Tool Search Tool，其他工具按需加载。这样可以实现 token使用量降低85%，并且测试数据表明：Opus 4 的准确率由 49% 提升至 74%，Opus 4.5 由 79.5% 提升至 88.1%。
例如，Claude与GitHub交互时，会搜索GitHub。这时只会加载 github.createPullRequest 和 github.listIssues，而不会加载你在 Slack、Jira 或 Google Drive 上的其他 50 多个工具。
生产环境需权衡：启用工具搜索工具会增加一次搜索步骤的时间成本。
编程式工具调用 PTC 就像让 AI 写好一份精确的执行脚本，由电脑直接跑完所有数据处理，然后只把精炼的结果交给 AI。这样做减少了 AI 需要记住和处理的冗余数据，减少上下文大小（节省 token）、减少轮次（降低延迟）、让结果更可控（提高准确率）。
程序处理if-else，AI负责分析总结。下面以员工报销检查为例：
- PTC 通过 Python 程序来处理编排流程，在沙箱里处理完数据，Claude 只在最后收到处理好的结果，比如员工报销超出预算。
- 传统查询：20人明细，每人50—100条，共2000多条数据。上述数据均由 Python 处理，数据量极大，但现在 PTC 方式只需要看汇总后的结果。
- 所以，代码环境里是确定性的计算，让最终的 AI 结论准确率极大提升。
- 多数环境的工作流通常涉及杂乱数据、条件逻辑和需要扩展的操作，PTC尤适用于此类工作流。
文档给出 5 步配置与一个使用场景：
- 需要在 tools 中开启 Code Execution 工具
- 给要用 PTC 的业务工具开放代码可调用权限
- Claude 会生成编排代码，本质是Python逻辑：循环、条件判断、并行执行
- 工具执行时不会占用 Claude 上下文
- 最终结果才进入 Claude 上下文
使用 PTC 的判断标准
- 数据量大（一次任务返回的原始工具数据 > 几百 KB）。
- 需要批量或并行调用多个工具（比如循环 20 次调用）。
- 对准确性要求高（避免自然语言推理中数据管理出错）。
- 希望降低延迟（减少每个工具调用都回到模型推理的往返）。
这些功能使之前单纯的 AI 工具从简单的函数调用迈向了智能编排，当智能体（Agent）处理跨越数十种工具及大规模数据集的复杂工作流时，动态发现、高效执行与可靠调用便成为核心能力。
第四篇：使用 MCP 执行代码：打造更高效的智能体
使用MCP执行代码：打造更高效的智能体发布于2025年11月4日。详细介绍了如何通过代码执行，让智能体更高效地与模型上下文协议服务器交互，在处理更多工具的同时减少 token（标记）消耗。
传统的软件工程比如写一个 Python 脚本或者用 ETL 工具可以很高效地处理数据，实现了数据的直接搬运，那么文章中为什么认为这在 MCP 里被视为一种突破？
传统软件工程，如果 Google Doc 的格式变了，或者客户突然想把数据存到 HubSpot 而不是 Salesforce，系统就崩溃了，需要重写代码，非常僵化。
那么如果用 Agent 呢，不也能解决吗？但 Agent 模式下，AI 充当了运行主体。于是必须像 CPU 一样，一步步处理数据，耗费太多的 Tokens。这种模式下，AI 退化成了数据管道，而且极度低效。
为何选用 MCP 加代码执行？
这时的 AI 升级为架构师。AI 不直接搬运数据，而是即时编写一个软件工程脚本，然后交给代码去跑。这时候既有程序代码的效率，也有了 Agent 的聪明，因为代码是 AI 现写的。
但是，为什么动态扫描目录就能让 AI 理解业务逻辑呢？ 这利用了 LLM 训练数据中最大的结构：代码仓库的目录结构。
- 当它看到 servers/google-drive/，它基于概率预测立刻知道这里面大概率包含 download、list 等功能。
- 当它看到 servers/salesforce/，它知道这里面是 CRM 相关的操作。
也是用了一些聪明的设计：从提示词那样的全量灌输（放入所有信息和数据），进化到主动检索。
- 把 1000 个工具的说明书强行塞进提示词。这不仅挤占空间，更引入了噪声。模型注意力分散，容易产生幻觉。
- MCP 动态扫描是先给文件树，让 AI 语义推理，找到需要的目录，而且还可以精确读取，只选择需要的内容。
这也是作者真正想要表达的、区别于传统方法的三个高效关键点。
- 传统 Agent：控制逻辑与数据流混杂在模型的上下文窗口里… 导致模型变笨、忘记指令。MCP 代码模式只负责思考逻辑、编写代码，数据从未进入 AI 的大脑。
- 让擅长逻辑的代码/CPU跑循环，让擅长规划的AI/GPU写代码。
- 传统 Agent 每次对话都是新的，它记不住之前的中间结果（除非全塞进 Context）。 MCP 通过文件系统给了 Agent 一个外挂硬盘。
感觉这是 AI Agent 的终极进化方向：从基于文本流的对话者进化为基于代码流的操作者。用大模型的编程能力，将高负载、重复性、确定性的任务，从昂贵的AI推理中剥离出来，下沉高效的代码中，从而实现了智能体能力的指数级扩展。
第五篇： 把智能体带入现实世界：Agent Skills
把智能体带入现实世界：Agent Skills一文发布于 2025 年 10 月 16 日，而在 2026 年 1 月底回头来看，显然已成为跨平台可移植的开放标准。
在这之前，Claude Code 能够利用本地代码执行和文件系统，完成跨领域的复杂任务。随后 Anthropic 在此基础上，演化出Agent Skills，通过结构化的指令、脚本和资源文件夹， AI能动态发现并加载这些内容，从而在特定任务中表现更出色。
以前为不同任务，比如处理发票、写公关稿，我们需要建立很多零散的 AI 应用，或者每次把所有背景信息都塞进对话框，既浪费token又易出错。这篇文章介绍了利用 Agent Skills 来快速把某个领域的工作整理成一个文件夹，里面包含一个核心说明文件 含 SKILL.md 与相关文档或脚本即可解决问题。
- 除了能把自己手边的工作整理成一个 Agent Skills，其他的工作呢？写 PPT、查数据、分析新闻…
- 延续使用MCP执行代码：打造更高效的智能体 的思路，不会一次加载所有 Agent 的详细信息，而是由浅入深慢慢来。
- 这意味着你可以给 AI 装上几百个技能，但只有在用的时候才会占用资源，极大地扩展了 AI 的能力边界。
新的人机协作模式来了：
- 实践几遍： 先让 AI 试着干活，看它哪里做得不好，哪里缺背景知识。
- 沉淀 SOP： 不要只是骂它，把纠正后的正确流程、参考资料写进 SKILL.md。
- 让AI自我总结并修复： 当你和 AI 配合完美完成一次任务后，直接让 AI 把这次的对话总结成一个 Skill 文件。
- 复用与分享： 下次再做同样的任务，或者其他人要做这个任务，直接加载这个文件夹即可。
也就是说 Agent Skills 本质上是把你的业务经验标准化、文件化。它让 AI 从一个需要你时刻盯着的实习生，变成了一个可以随身携带、随时查阅厚厚一摞操作手册的资深专员。
Agent 如同人的大脑。它负责理解意图、规划路径、分配资源。 Skills.md 和配套代码，不再是简单的参考文档，而是可执行的程序包。 最容易忽略的 Virtual Machine，也就是文中的 local code execution filesystems，实际上是给 Agent 提供了一个沙盒环境（Sandbox/VM）。
这让 Agent Skills 在从一个 PPT worker，快速演变成一个多面手工程师。 如果只有 Agent + Skills 知识，那只是 RAG 检索增强生成。加上 Virtual Machine，才是 Agentic Workflow。
没有 VM，AI 只能输入输出文本，有了 VM 后 AI 可以读取文件、修改文件、运行脚本…
以前，Prompt Engineer 试图用自然语言催眠模型，让它按你的意思说话。之后你是一个真正的 AI Architect，把任务交给 Agent 推理，把具体的任务封装成代码交给 VM执行，这是 Prompt + Code + Data 的完整功能包。
第六篇：安全＝沙箱？
[让Claude Code更安全、更具自主性]一文发表于2025年10月20日，介绍Claude Code的全新沙箱功能，包括 bash 工具和网页版 Claude Code，通过提供文件系统隔离和网络隔离两重防护，减少了权限请求提示，并提升了用户安全性。
但实际上上一篇文章是在给 AI 发了枪/ 执行代码的能力 使用MCP执行代码：打造更高效的智能体之后，继续给这把枪装上了保险。
在之前，Agent Skills = Agent + Skills + Virtual Machine 现在，Enterprise Agent = Agent + Skills + (Sandboxed VM + Network Policy)
如果没有沙盒，很多时候 Agent 会老老实实执行代码，造成灾难。而这篇文章宣布了 Claude 拥有了操作系统级别的用户权限管理机制，防止意外发生。现在 Agent 只能在这个文件夹玩耍，要访问 Web等操作需要报警。
当然也意味着 Agent 真可以跑上几天几夜的任务了。
AI 时代，安全也变得越来越重要了。别那么随意装一些这样或者那样的所谓热门的 Agent Skills 了！
未来的 Agent 开发，将不再仅仅是写 Prompt，还需要要定义安全策略了。
一来 Github 为代表的技能库那可是浩如烟海，机会难得。二来是难得借这个 AI 的机会，生产力大幅提升啊。
参考文献
- Anthropic — 详细阐述了 Anthropic 对 Agent 架构及其协作逻辑的见解。
- AI 智能体的高效上下文工程 — 虽然模型越来越强，但是不可避免地常常会出现注意力分散，理解混乱等
- 智能体编码最佳实践 - 深度定制上下文、灵活扩展工具链、遵循先规划后执行，将 Claude 从单纯的代码生成器提升为全能的工程伙伴
- 使用MCP执行代码：打造更高效的智能体 - 利用模型上下文协议（MCP）来调用工具，具有更强的可扩展性
- 把智能体带入现实世界：Agent Skills - 利用文件夹目录构建 Agent 的新方式
- 让 Claude Code 更安全、更具自主性 -
- 开发者平台推出高级工具使用功能 工具搜索工具 / 编程式工具调用 / 工具使用示例
讨论
登录后可评论、点赞、引用回复。