---
title: "Bash Is All Agent Need：Anthropic 重新定义智能体开发"
source: "https://zhuanlan.zhihu.com/p/1991967263100782525"
author:
  - "[[段小草​新知答主]]"
published:
created: 2026-01-07
description: "过去一年，行业对 Agent 的普遍构想是，为大型语言模型（LLM）配备一个工具箱，里面装满了各种 API。模型就像一个调度中心，根据用户指令，选择合适的 API 工具来执行任务。 以这种思路出发，大家做了很多工程化的…"
tags:
  - "clippings"
---
[![段小草](https://pic1.zhimg.com/6cc78144fed4969434ee35c1f5b0344f_l.jpg?source=32738c0c&needBackground=1)](https://www.zhihu.com/people/loveQt)

[段小草](https://www.zhihu.com/people/loveQt)

[​![](https://pic1.zhimg.com/v2-27bfcba90e66db79ce8768ab807e017e_l.png?source=32738c0c)](https://www.zhihu.com/question/510340037)

新知答主

[

收录于 · 小段同学的杂记

](https://www.zhihu.com/column/666666)

鹿辞鑫 等 80 人赞同了该文章

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

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

Anthropic 的工程师 Thariq Shihipar 在一场关于 Claude Agent SDK 的分享中，提出了一个观点。**他认为，最强大的 Agent 工具，不是无数个定制的 API，而是开发者最熟悉的两样东西：[Bash](https://zhida.zhihu.com/search?content_id=268654393&content_type=Article&match_order=1&q=Bash&zhida_source=entity) 和[文件系统](https://zhida.zhihu.com/search?content_id=268654393&content_type=Article&match_order=1&q=%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F&zhida_source=entity)。**

![](https://pic2.zhimg.com/v2-ddea68306ca988fd69a3202db2f6820f_1440w.jpg)

这听起来有些原始。但在 Thariq 的解读中，这套基于 [Unix 哲学](https://zhida.zhihu.com/search?content_id=268654393&content_type=Article&match_order=1&q=Unix+%E5%93%B2%E5%AD%A6&zhida_source=entity)的 Agent 构建思路，展现出远超传统 API 工具模式的灵活性和潜力。它预示着，AI Agent 不必是一个 API 调用大师，而是一个在虚拟环境中自主工作的工程师。

### **从「工作流」到「自主体」**

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

![](https://pic2.zhimg.com/v2-beafe70a32cc915401a0fa5a39bc6ffd_1440w.jpg)

1. **LLM 特性（Features）**：这是最初级的应用，比如文本分类、情感分析。模型执行单一、孤立的任务，一问一答。
2. **工作流（Workflows）**：这是目前主流的应用范式，比如 RAG（检索增强生成）。系统遵循一个固定的、由人类设计的流程（检索 -> 合成 -> 回答），虽然涉及多个步骤，但本质上是线性的、被动的。
3. **智能体（Agents）**：这是演进的下一阶段。Agent 不再遵循固定的流程，而是能够「**自主构建上下文，自主决定路径」**。它像一个活的系统，可以根据环境变化和任务进展，动态地规划和调整自己的行为。

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

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

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

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

### **被忽视的 Unix 哲学：Bash 作为终极工具**

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

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

![](https://picx.zhimg.com/v2-5f8faaa65cae86b6f230966752740bb9_1440w.jpg)

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

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

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

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

**1\. 通用性与组合性。**

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

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

- **API 模式**：Agent 调用 search\_email(query="Uber OR Lyft")，得到一百多封邮件。接下来怎么办？模型需要将所有邮件内容加载到上下文中，然后用孱弱的内置计算能力去解析和累加。这不仅消耗了宝贵的上下文窗口，而且极易出错。
- **Bash 模式**：Agent 可以生成一个脚本。首先，用一个 gmail\_search 脚本将结果保存到文件 emails.txt。接着，用 grep "Price: " emails.txt 筛选出包含价格的行。然后，用 awk 或 sed 提取出数字。最后，用 paste 和 bc 将所有数字相加。
![](https://pic2.zhimg.com/v2-f82abf65dfa061d63549e3828535b2df_1440w.jpg)

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

**2\. 天然的「可发现性」。**

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

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

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

### **从「提示工程」到「[上下文工程](https://zhida.zhihu.com/search?content_id=268654393&content_type=Article&match_order=1&q=%E4%B8%8A%E4%B8%8B%E6%96%87%E5%B7%A5%E7%A8%8B&zhida_source=entity)」**

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

![](https://pic4.zhimg.com/v2-71262a68fe4b54b0f001635d73d96831_1440w.jpg)

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

**1\. 文件作为记忆。**

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

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

**2\. 文件作为真相的来源。**

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

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

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

**3\. 文件系统作为「渐进式上下文披露」的载体。**

Anthropic 最近推出的「**[技能](https://zhida.zhihu.com/search?content_id=268654393&content_type=Article&match_order=1&q=%E6%8A%80%E8%83%BD&zhida_source=entity)（Skills）」**功能，正是「上下文工程」思想的完美体现。一个「技能」本质上就是一个包含特定指令和脚本的文件夹。

![](https://pic4.zhimg.com/v2-f3358a731bba43dd7d7333a57a70de0f_1440w.jpg)

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

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

### **Agent 的自主循环与自我修正**

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

![](https://pic4.zhimg.com/v2-5661365071d54e8b3103743ef62b0415_1440w.jpg)

1. **收集上下文**：Agent 使用 ls, cat, grep 等工具来理解当前的环境和任务。它需要找到哪些文件是相关的，当前的状态是什么。
2. **执行动作**：基于收集到的上下文，Agent 决定下一步该做什么。可能是调用一个工具，也可能是生成并执行一段代码来处理数据。
3. **验证工作**：动作执行后，Agent 再次观察环境，检查动作是否达到了预期的效果。比如，代码是否编译通过？文件是否被正确修改？

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

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

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

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

### **Anthropic 的实践智慧**

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

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

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

- **限定范围**：不要让 Agent 一开始就面对整个代码库。把它放在一个特定的子目录里，先让它解决这个模块的问题。
- **提供好的地图**：编写高质量的 CLAUDE.md，作为代码库的导览，告诉 Agent 核心模块在哪里，关键的数据结构是什么。

**关于安全**：赋予 Agent Bash 权限无疑是危险的。Anthropic 采取「[瑞士奶酪防御](https://zhida.zhihu.com/search?content_id=268654393&content_type=Article&match_order=1&q=%E7%91%9E%E5%A3%AB%E5%A5%B6%E9%85%AA%E9%98%B2%E5%BE%A1&zhida_source=entity)」（Swiss Cheese Defense）模型，在每一层都设置防护：

- **模型层**：通过对齐训练，让模型本身具备安全意识。
- **Harness 层**：对 Bash 命令进行抽象语法树（AST）解析，识别并阻止危险操作。
- **沙箱层**：将 Agent 运行在严格隔离的容器中，限制其文件系统和网络访问权限。

### **结语**

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

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

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

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

---

参考素材：

[Claude Agent SDK \[Full Workshop\] — Thariq Shihipar, Anthropic](https://link.zhihu.com/?target=https%3A//www.youtube.com/watch%3Fv%3DTqC1qOfiVcQ)