大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



过去一年，行业对 Agent 的普遍构想是，为大型语言模型（LLM）配备一个工具箱，里面装满了各种 API。模型就像一个调度中心，根据用户指令，选择合适的 API 工具来执行任务。

以这种思路出发，大家做了很多工程化的工作，却发现效果远远比不上 Claude Code。

Anthropic 的工程师 Thariq Shihipar 在一场关于 Claude Agent SDK 的分享中，提出了一个观点。他认为，最强大的 Agent 工具，不是无数个定制的 API，而是开发者最熟悉的两样东西：Bash 和文件系统。

这听起来有些原始。但在 Thariq 的解读中，这套基于 Unix 哲学的 Agent 构建思路，展现出远超传统 API 工具模式的灵活性和潜力。它预示着，AI Agent 不必是一个 API 调用大师，而是一个在虚拟环境中自主工作的工程师。

要理解 Anthropic 的思路，首先要明确 Agent 的定义。Thariq 将 AI 的能力演进分成了几个阶段：

从「工作流」到「Agent」的跃迁，核心在于「自主性」。

一个固定的 RAG 流程无法处理“检索结果为空”的意外情况，但一个真正的 Agent 应该能够意识到这个问题，并主动尝试用不同的关键词再次搜索，甚至去其他地方寻找信息。

这种自主性，正是传统 API 工具模式的瓶颈所在。当 Agent 面对一个工具箱里没有的、或者需要组合多个工具才能解决的复杂问题时，它就束手无策了。

而 Anthropic 的答案是，与其给它无数把功能单一的「接口」，不如直接给它一个可以制造任何工具的「环境」——Bash。

Claude Agent SDK 的设计哲学，深受 Claude Code 的影响。Anthropic 团队在内部构建各种 Agent 时，发现他们总是在重复造轮子，而 Claude Code 中那个看似简单的 Bash 工具，却能解决绝大多数问题。

一个关键的洞察是：人类开发者会如何解决问题？

假设一个开发者需要将一个视频文件转换成 GIF。他不会去找一个专门的 videoToGif API。

他会在命令行里输入 ffmpeg -i input.mp4 output.gif。如果他需要在一个代码库里查找所有包含特定函数调用的文件，他会用 grep -r "functionName" .，而不是一个 codeSearch API。

Bash 和它背后的庞大命令行工具生态，是几十年来软件工程的**实践沉淀。

它具备两个 API 模式难以比拟的优势：

Unix 哲学的核心是「做一件事并把它做好」。无数个小而美的命令行工具（grep, sed, awk, jq, curl）可以通过管道符（|）任意组合，形成强大的数据处理流。这种能力使得 Agent 可以动态地构建解决方案，而不是被困在预设的工具集中。

比如，一个邮件 Agent 需要计算用户本周在打车软件上的总花费。

在这个过程中，Agent 扮演一个经验丰富的 Linux 系统管理员，每一步都有明确的输出，每一步都可以被验证。它甚至可以将这个流程保存为一个可复用的 .sh 脚本，供未来使用。

一个 API 工具箱对模型来说是个黑盒。除非在 Prompt 中详细描述，否则模型不知道每个工具的具体参数和用法。当工具数量达到几十上百个时，Prompt 本身就会变得臃肿不堪，模型也会开始困惑。

而命令行工具是「可发现」的。Agent 如果不知道 ffmpeg 怎么用，它可以自己运行 ffmpeg –help 来阅读文档。这种自主学习和探索的能力，是实现真正自主性的关键。

Anthropic 的观点是，不应该把 Agent 限制在人类为它精心打造的「安全花园」里。相反，应该把它放到一个真实但受控的计算环境中，让它学会像人一样使用通用工具。这是一种更彻底的赋能。

如果说 Bash 是 Agent 的双手，那么文件系统就是它的「外部大脑」和「工作台」。这也正是去年下半年以来行业发力的上下文工程上下文工程（Context Engineering）。

上下文不仅是输入给模型的 Prompt，还包括 Agent 可以访问和操作的整个环境，其中最重要的就是文件系统。

LLM 的上下文窗口是有限的。Agent 不能把所有的中间步骤和思考过程都保留在对话历史里。一个聪明的 Agent 会把重要的信息、计划、中间结果写入文件。

例如，Agent 在执行一个复杂的编码任务时，可以创建一个 CLAUDE.md 文件，在里面记录自己的总体规划、已完成的步骤和下一步的打算。当它因为某些原因（比如上下文窗口被清空）失忆时，只需读取这个文件，就能立刻找回状态。这比任何花哨的记忆模块都来得更简单、更可靠。

Agent 如何知道自己的操作是否成功？通过文件系统。

当 Agent 使用一个 create_file 工具时，它只是相信操作成功了。但如果它使用 Bash 的 touch new_file.txt，它可以在下一步立刻运行 ls 来验证 new_file.txt 是否真的存在。

这种「操作-观察-验证」的闭环，是构建可靠 Agent 的基石。文件系统为 Agent 提供了一个客观的、可供核查的外部世界。

Anthropic 最近推出的「技能（Skills）」功能，正是「上下文工程」思想的完美体现。一个「技能」本质上就是一个包含特定指令和脚本的文件夹。

当 Agent 需要执行一项它不熟悉的复杂任务（比如「创建一个前端应用」）时，它不是在 Prompt 里被灌输所有知识，而是可以 cd 到 frontend_skill 文件夹，读取里面的 skill.md 文件，学习如何一步步完成任务，并使用该文件夹下提供的脚本工具。

这种模式被称为「渐进式上下文披露」（Progressive Context Disclosure）。Agent 只在需要的时候去学习特定的知识，极大地节省了上下文，也让 Agent 的能力可以被模块化地无限扩展。

有了 Bash 和文件系统，Agent 的核心运行逻辑就变得清晰起来：

这个循环的精髓在于「验证」这一步。它赋予了 Agent 自我修正的能力。如果 Agent 写的代码有 bug，编译步骤会报错。Agent 会“看到”这个错误，然后返回第一步，重新阅读代码（收集上下文），思考如何修复 bug（执行动作），然后再次尝试编译（验证工作）。

这种能力是僵化的工作流所不具备的。为了让这个循环更加可靠，Anthropic 还引入了「钩子（Hooks）」机制。钩子允许开发者在 Agent 运行的特定事件点（如工具调用前后）注入确定性的逻辑。

比如，Agent 有时会幻觉出一个文件的内容，而不是先去读取它。开发者可以设置一个钩子，在 Agent 尝试写入文件前，检查它是否已经读取过该文件。如果没有，钩子可以拦截操作，并向 Agent 返回一条反馈信息：「你必须先读取文件才能写入。」

这种确定性的规则和护栏，极大地提高了 Agent 的可靠性，而无需重新训练模型。

除了宏大的理念，Thariq 也给出了许多可落地的实践建议。

关于 Agent 的原型设计：不要一上来就陷入 SDK 的细节。直接打开 Claude Code，把你的 API 客户端库、相关的文档（可以整理成一个 CLAUDE.md 文件）上传，然后用自然语言和它对话，让它帮你完成任务。观察它的思考过程、它犯的错误、它对工具的理解。这个过程能让你以最低的成本，快速验证你的 Agent 设计思路是否可行。

关于处理大型代码库：当代码库达到千万行级别时，传统的 grep 会很慢，将所有文件塞进上下文也不现实。目前流行的语义搜索方案其实很脆弱，因为模型本身并没有针对你的特定代码索引进行训练，它不理解这个索引的语义。Anthropic 的建议更偏向于传统的软件工程智慧：

关于安全：赋予 Agent Bash 权限无疑是危险的。Anthropic 采取「瑞士奶酪防御」（Swiss Cheese Defense）模型，在每一层都设置防护：

Thariq 将 Claude Agent SDK 类比为前端框架的演进。早期的 jQuery 很方便，但 React 带来了虚拟 DOM、组件化等更深刻的抽象，虽然上手门槛更高，却构建出了更复杂、更强大的应用。

Anthropic 的 Agent 构建哲学也是如此。它放弃了简单的 API 封装，回归到 Bash 和文件系统这两个计算世界最基本的第一性原理。这要求开发者像设计一个小型操作系统一样，去思考 Agent 的运行环境、工具链和工作流。

这无疑是一条更难的路，但可能是一条更正确的路。它旨在构建一个真正通用、自主、能够处理开放式问题的智能体，而不是一个只能在预设轨道上运行的工作流执行器。

世界是复杂的、充满意外的，一个只能使用特定工具的 Agent 永远无法应对无穷的可能性。而一个手握 Shell、能够不断学习和创造新工具的 Agent，才真正拥有了通往通用人工智能的潜力。

参考素材：

Claude Agent SDK [Full Workshop] — Thariq Shihipar, Anthropic