企业官网建设流程全解析

1. 从"Agent-Reach"这个名字说起：它到底想解决什么问题

第一次看到"Agent-Reach"这个项目名，我脑子里冒出来的第一个念头是：这又是一个套壳的AI对话工具吗？毕竟这两年"Agent"这个词已经被用烂了，什么项目都往上面蹭。但仔细琢磨"Reach"这个词，再结合它被归类到CLI工具这个方向，我大概能猜到它想干的事情——让AI Agent真正"够得着"外部世界，而不是困在对话框里自娱自乐。

说白了，现在大部分所谓的AI Agent，本质上还是一个"你问我答"的聊天机器人。你让它帮你查个资料，它给你编一段看起来很像那么回事但经不起推敲的文字；你让它帮你操作个文件，它告诉你"我无法直接访问你的文件系统"。这种Agent，用行内话说就是"没有手"，只有一张嘴。而Agent-Reach这类工具的核心价值，就是给Agent装上"手"和"脚"，让它能通过命令行接口（CLI）去触碰真实的系统、真实的文件、真实的网络服务。

我之所以对这个方向特别有感触，是因为过去大半年我一直在折腾各种Agent的落地场景。从最早用Python写脚本调API，到后来尝试各种Agent框架，踩过的坑能写满一个笔记本。最核心的痛点始终没变：Agent的"感知-决策-执行"闭环里，执行这一环太弱了。你可以在Prompt里把任务描述得天花乱坠，但Agent真正能调用的工具就那么几个，稍微复杂一点的操作就抓瞎。Agent-Reach瞄准的就是这个执行层的缺口，用CLI作为Agent与外部世界交互的统一接口。

这篇文章适合谁看？如果你是一个正在尝试搭建AI Agent的开发者，或者是一个对"让AI真正干活"这件事感兴趣的技术爱好者，再或者你只是好奇CLI这种"老古董"技术为什么在AI时代又焕发了第二春，那接下来的内容应该能给你一些实在的参考。我会从CLI为什么适合做Agent的执行层讲起，然后拆解Agent-Reach可能的技术架构，再结合Python生态给出具体的搭建思路，最后分享一些我在实操中总结的避坑经验。

提示：本文不会涉及任何具体的网络访问工具或敏感技术，所有讨论都围绕本地系统操作和通用编程实践展开。

2. 为什么CLI是AI Agent执行层的最佳拍档

2.1 从"对话框困境"说起：Agent为什么需要CLI

先讲一个我自己的真实经历。去年我想做一个能自动整理项目文档的Agent，需求很简单：扫描指定目录下的Markdown文件，提取标题和摘要，生成一个索引页。听起来是个入门级任务对吧？但我试了三个不同的Agent框架，没有一个能顺畅完成。问题出在哪？出在文件系统操作这个环节。

大部分Agent框架的工具调用机制是这样的：你定义一个函数，写好docstring，Agent根据用户输入决定要不要调用这个函数。但文件操作涉及的东西太多了——列目录、读文件、写文件、判断文件是否存在、处理路径分隔符在不同系统下的差异。你不可能为每一个操作都定义一个独立的函数，那样工具列表会长到Agent自己都晕。而CLI天然就是干这个的：ls、cat、grep、find，这些命令经过几十年的打磨，已经覆盖了文件操作的几乎所有场景。Agent只需要学会"调用命令行"这一件事，就能通过组合不同的命令完成复杂任务。

这就是CLI作为Agent执行层的第一个优势：接口的统一性。不管底层是Linux、macOS还是Windows的WSL，命令行工具的基本语义是一致的。Agent不需要为每个平台写不同的适配层，它只需要生成正确的命令字符串，剩下的交给Shell去解释执行。

2.2 CLI的"可组合性"：管道才是Agent的杀手锏

如果说统一接口只是让Agent"能用"，那CLI的管道机制就是让Agent"好用"的关键。我举个例子你就明白了。

假设你让Agent完成这样一个任务："找出当前项目里所有超过500行的Python文件，按行数从多到少排序，取前10个，把文件名和行数写到一个报告里。"

如果用传统的函数调用方式，你需要定义至少三个工具：一个用来遍历文件，一个用来统计行数，一个用来排序和写入。Agent需要依次调用这三个工具，中间还要处理数据传递的格式问题。但如果用CLI，这整个任务就是一行命令的事：

find . -name "*.py" -exec wc -l {} + | sort -rn | head -10 > report.txt

Agent只需要生成这一行命令，Shell会自动处理管道中的数据流转。这种声明式的任务表达方式，比一步步调用函数要高效得多。而且管道的每一步都是独立的、可测试的，如果结果不对，你可以很容易地定位到是哪个环节出了问题。

我在实际项目中发现，当Agent能够自由使用管道时，它的"创造力"会明显提升。因为它不再受限于你预定义的那几个工具，而是可以用grep过滤、用awk提取字段、用sed替换文本、用xargs批量处理，这些命令的组合空间几乎是无限的。一个设计良好的Agent-Reach类工具，应该把"生成安全的Shell命令"作为核心能力，而不是把每个操作都封装成独立的API。

2.3 安全边界：让Agent用CLI不等于让它"裸奔"

说到这里，肯定有人要跳出来说："让AI直接执行Shell命令？太危险了吧！"这个担心完全合理。我刚开始做这类实验的时候，也犯过一个低级错误：Agent生成了一个rm -rf命令，幸好我在测试环境里跑，不然项目目录就没了。

所以Agent-Reach这类工具在设计时，安全沙箱是必须考虑的核心模块。我的经验是至少要做三层防护：

第一层是命令白名单。不是所有命令都允许Agent执行，像rm、dd、mkfs这种破坏性强的命令，要么完全禁止，要么限制在特定目录下。白名单的粒度可以细到"允许ls但不允许ls -R /"这种程度。

第二层是路径约束。Agent生成的所有文件路径，都必须经过校验，确保它们落在预定义的工作目录内。这可以通过在命令执行前解析路径参数来实现，也可以用更底层的chroot或容器隔离。

第三层是执行确认。对于高风险操作，比如写入文件、修改配置、安装依赖，可以设置一个确认环节。这个确认可以是人工的，也可以是规则引擎自动判断的。我在自己的工具里就加了一个简单的规则：如果命令包含>或>>重定向符号，就先打印出来让我看一眼再执行。

注意：安全防护不是一次性的工作，而是一个持续迭代的过程。每当你给Agent开放新的命令权限，都应该重新评估潜在的风险。

3. 拆解Agent-Reach的可能架构：从输入到执行的完整链路

3.1 输入解析层：Agent怎么"听懂"你的需求

虽然Agent-Reach的项目正文是空的，但根据它的定位和关键词，我可以合理推测它的输入解析层大概会包含这几个模块。

首先是自然语言理解。用户输入的可能是一句模糊的指令，比如"帮我看看最近改过的文件"，也可能是一个明确的任务描述，比如"把src目录下所有.js文件里的console.log删掉"。Agent需要从这些输入中提取出关键信息：操作对象是什么、操作类型是什么、有没有附加条件。

这一步通常依赖大语言模型来完成。但我的经验是，不要完全依赖模型的自由发挥。更好的做法是设计一套结构化的Prompt模板，引导模型输出特定格式的中间表示。比如让模型输出一个JSON对象，包含action、target、params三个字段。这样后续的处理逻辑就可以基于这个结构化数据来写，而不是去解析模型输出的自然语言。

其次是上下文注入。Agent需要知道当前的工作目录是什么、有哪些文件可用、系统环境是什么样的。这些信息可以通过在Prompt里附加一段"环境描述"来提供。我在自己的实现里，会在每次对话开始时自动执行几个探测命令（pwd、ls、uname -a），把结果作为上下文的一部分传给模型。这样模型生成的命令就不会出现"在当前目录下找不到xxx文件"这种低级错误。

3.2 命令生成层：从意图到可执行命令的翻译

这是整个架构里最核心也最微妙的部分。模型需要把结构化的意图翻译成具体的Shell命令。这里有几个坑我踩过，值得展开说说。

第一个坑是命令的幂等性。有些命令执行多次会产生不同的结果，比如mkdir不加-p参数时，目录已存在就会报错。Agent在生成命令时，应该尽量选择幂等的写法。我的做法是在Prompt里明确要求："生成命令时，优先使用幂等操作，比如mkdir -p、rm -f、cp -n等。"

第二个坑是路径的转义。文件名里带空格、带特殊字符的情况太常见了。如果Agent生成的命令没有正确处理转义，轻则命令执行失败，重则误删文件。我一般会在Prompt里强调："所有文件路径必须用双引号包裹。"同时在后处理阶段，对生成的命令做一次转义检查。

第三个坑是命令的跨平台兼容性。sed -i在Linux和macOS上的行为就不一样，macOS需要写成sed -i ''。如果你的Agent需要在多个平台上运行，要么在Prompt里明确指定目标平台，要么在命令生成后做一层适配转换。我目前的策略是优先使用POSIX标准的命令和参数，避免使用平台特有的扩展。

下面是一个命令生成层的简化实现思路，用Python伪代码表示：

def generate_command(intent, context): prompt = f""" 当前环境：{context['os']}，工作目录：{context['cwd']} 可用文件：{context['files']} 用户意图：{intent} 请生成一条Shell命令来完成这个任务。 要求： 1. 命令必须是幂等的 2. 所有路径用双引号包裹 3. 只使用POSIX标准命令 4. 如果任务无法用一条命令完成，可以用 && 连接多条命令 直接输出命令，不要解释。 """ command = llm.generate(prompt) return sanitize(command)

3.3 执行与反馈层：命令跑完之后怎么办

命令生成出来只是第一步，执行和反馈才是闭环的关键。我见过太多Agent项目，命令执行完就完了，不管成功还是失败，都不影响后续的对话。这种"开环"的设计，导致Agent经常在错误的道路上越走越远。

一个完整的执行反馈层应该包含这几个要素：

退出码检查。Shell命令执行后会返回一个退出码，0表示成功，非0表示失败。Agent应该根据退出码来判断命令是否执行成功。如果失败，需要把错误信息（stderr）捕获下来，作为下一轮对话的输入。

输出截断。有些命令的输出可能非常长，比如find /或者cat一个大文件。如果直接把全部输出塞给模型，不仅浪费token，还可能超出上下文窗口。我的做法是设置一个阈值（比如2000个字符），超过就截断，并附上一句"输出已截断，显示前2000个字符"。

状态更新。命令执行可能会改变系统状态，比如创建了新文件、修改了配置。Agent需要感知这些变化，才能做出正确的后续决策。最简单的做法是在每轮对话结束后，重新执行一次环境探测命令，更新上下文。

错误恢复。当命令执行失败时，Agent不应该直接放弃，而应该尝试分析错误原因并给出修复方案。比如command not found说明缺少依赖，Agent可以建议安装；Permission denied说明权限不足，Agent可以建议用sudo或者修改文件权限。这种错误恢复能力，是区分"玩具Agent"和"实用Agent"的重要标志。

3.4 会话管理层：多轮对话中的状态保持

Agent-Reach作为一个CLI工具，大概率会支持交互式会话模式。这就涉及到会话管理的问题：如何保持多轮对话的上下文，如何管理历史命令，如何支持撤销和重做。

我的经验是，会话状态应该尽量轻量。不要把整个对话历史都塞进上下文，那样很快就会超出模型的窗口限制。更好的做法是维护一个"工作记忆"，只保留最近几轮的关键信息：当前目录、最近执行的命令、最近的操作结果、待完成的任务列表。

另外，命令历史本身就是一个很有价值的上下文来源。用户可以输入"再执行一次上一条命令"或者"把刚才那个命令的输出保存到文件"，Agent需要能够引用历史命令。我通常会把最近10条命令缓存在内存里，并在Prompt里以编号列表的形式提供给模型。

4. 用Python搭建一个Agent-Reach原型：从零到跑通

4.1 环境准备：Python版本和依赖选择

动手之前，先把环境理清楚。Python版本我建议用3.10以上，因为3.10引入了结构化模式匹配（match-case），在处理命令解析时写起来会舒服很多。安装Python的教程网上到处都是，这里不展开，只提醒一点：Windows用户务必勾选"Add Python to PATH"，不然命令行里调不到python命令，后面全是坑。

依赖方面，核心的库就几个：

• openai或者anthropic：调用大语言模型，看你用哪家的服务
• subprocess：Python标准库，用来执行Shell命令
• shlex：Python标准库，用来安全地分割命令字符串
• pathlib：Python标准库，处理路径比os.path更优雅
• rich：可选，用来美化终端输出，让交互体验好一点

安装命令很简单：

pip install openai rich

如果你用的是其他模型服务，把openai换成对应的SDK就行。我个人的习惯是再装一个python-dotenv，把API密钥放在.env文件里，避免硬编码在代码中。

提示：如果你在国内网络环境下安装依赖遇到问题，可以配置pip的镜像源，比如清华源或者阿里源，这个网上教程很多，不赘述。

4.2 核心执行器：subprocess的正确打开方式

Python执行Shell命令，最直接的方式是os.system()，但我强烈不建议用这个。原因很简单：os.system()不返回命令的输出，你只能拿到一个退出码，而且它直接调用系统Shell，安全性很差。

正确的做法是用subprocess.run()。下面是我封装的一个执行器函数，经过多次迭代，目前用着比较顺手：

import subprocess import shlex def execute_command(command: str, cwd: str = None, timeout: int = 30): """ 执行Shell命令并返回结果 """ try: # 用shlex分割命令，避免shell注入 args = shlex.split(command) result = subprocess.run( args, cwd=cwd, capture_output=True, text=True, timeout=timeout, shell=False # 关键：不使用shell=True ) return { "success": result.returncode == 0, "stdout": result.stdout[:2000], # 截断输出 "stderr": result.stderr[:500], "returncode": result.returncode } except subprocess.TimeoutExpired: return { "success": False, "stdout": "", "stderr": f"命令执行超时（{timeout}秒）", "returncode": -1 } except Exception as e: return { "success": False, "stdout": "", "stderr": str(e), "returncode": -1 }

这里有几个关键点值得说明。shell=False是安全性的核心，它意味着命令不会被Shell解释，管道、重定向这些特性都用不了。但这也带来一个问题：如果Agent生成的命令里包含管道，shlex.split会把它拆成多个参数，subprocess会找不到对应的可执行文件。

我的解决方案是：对于简单命令用shell=False，对于包含管道的复杂命令，先做安全校验，再谨慎地使用shell=True。安全校验的逻辑包括：检查命令中是否包含危险字符（;、&&、||、$()、反引号等），检查命令的第一个词是否在白名单里。这个校验逻辑虽然不能做到100%安全，但能挡住大部分低级风险。

4.3 与模型对接：Prompt设计的几个关键决策

Prompt的设计直接决定了Agent的表现。我试过很多种写法，最后稳定下来的模板大概是这样的：

SYSTEM_PROMPT = """你是一个命令行助手，负责将用户的自然语言需求转换为Shell命令。 当前环境信息： - 操作系统：{os_info} - 工作目录：{cwd} - 目录内容：{files} 规则： 1. 只输出命令本身，不要输出任何解释或Markdown格式 2. 优先使用幂等命令（mkdir -p, rm -f, cp -n） 3. 所有文件路径用双引号包裹 4. 如果任务需要多条命令，用 && 连接 5. 如果无法完成，输出 ERROR: 加上原因 6. 不要使用 rm -rf、dd、mkfs 等危险命令 """

这个模板里有几个设计决策值得展开。第一，环境信息放在System Prompt里而不是User Prompt里，这样模型在每一轮对话中都能看到最新的环境状态，不需要用户重复描述。第二，明确要求"只输出命令"，避免模型输出一堆解释文字，后处理的时候还要去提取。第三，用"ERROR:"作为错误标记，方便程序判断模型是否放弃了任务。

还有一个细节：温度参数（temperature）要调低。命令生成是一个确定性很强的任务，不需要模型发挥创造力。我一般把temperature设在0.1到0.3之间，太高了容易生成奇怪的命令，太低了又可能陷入重复。实测下来0.2是个比较平衡的值。

4.4 跑通第一个Demo：让Agent帮你整理文件

环境搭好了，执行器和Prompt也准备好了，现在来跑一个完整的Demo。任务很简单：让Agent把当前目录下所有的.txt文件移动到一个叫texts的子目录里。

用户输入："把所有txt文件放到texts文件夹里"

Agent的处理流程大概是这样的：

第一步，环境探测。程序自动执行ls，发现当前目录有a.txt、b.txt、c.py、readme.md四个文件。

第二步，模型生成命令。把环境信息和用户输入一起发给模型，模型返回：

mkdir -p "texts" && mv *.txt "texts/"

第三步，安全校验。检查命令中是否包含危险操作，mkdir -p和mv都在白名单里，通过。

第四步，执行命令。调用execute_command，命令成功执行，返回码为0。

第五步，结果反馈。程序把执行结果告诉模型，模型生成一句自然语言的回复："已经把a.txt和b.txt移动到texts目录了。"

这个Demo虽然简单，但它涵盖了Agent-Reach类工具的核心流程。你可以在这个基础上逐步扩展：增加更多的命令白名单、支持更复杂的任务分解、加入错误重试机制、实现多轮对话的上下文管理。我自己的工具就是从这样一个几十行的脚本开始，慢慢迭代到能处理几百种不同任务的。

5. 实操中踩过的坑与应对策略

5.1 模型"幻觉"出不存在命令的排查过程

这是我最开始遇到的一类问题，而且排查起来特别费劲。现象是：Agent生成的命令看起来有模有样，但执行的时候报command not found。比如模型生成了一个findu命令，我查了半天才发现它把find和du混在一起了。

排查这类问题的第一步，是把模型生成的原始命令打印出来。不要只看执行结果，要看命令本身。我一开始就是只看报错信息，以为是环境问题，折腾了半天才发现是命令本身就不对。

第二步，分析模型的生成模式。我发现模型在生成命令时，倾向于"创造"一些看起来合理的命令，尤其是当它不确定某个操作该用什么命令时。比如要统计目录大小，正确的命令是du -sh，但模型有时候会生成dirsize或者foldersize这种不存在的命令。

应对策略有两个。一是在Prompt里提供常用命令的清单，让模型从清单里选，而不是自由发挥。二是在执行前做命令存在性检查，用shutil.which()判断命令是否在PATH里，如果不在就直接返回错误，让模型重新生成。

import shutil def check_command_exists(command: str) -> bool: """检查命令的第一个词是否是可执行文件""" first_word = shlex.split(command)[0] return shutil.which(first_word) is not None

这个检查虽然简单，但能挡住大部分"幻觉命令"的问题。而且它执行起来很快，几乎不影响性能。

5.2 路径处理：相对路径、绝对路径与空格文件名

路径问题是另一个高频踩坑点。我总结下来，主要有三种情况容易出问题。

第一种是相对路径的基准目录不对。Agent生成的命令里用了相对路径，比如./data/file.txt，但命令执行时的cwd和Agent以为的不一样，导致找不到文件。我的解决方案是：在执行命令时显式指定cwd参数，并且在Prompt里明确告诉模型当前的工作目录是什么。

第二种是绝对路径的拼接错误。模型有时候会把两个路径简单拼接，比如/home/user和data/file.txt拼成/home/userdata/file.txt，少了一个斜杠。这种错误很隐蔽，因为命令本身语法是对的，只是路径不对。我的做法是在Prompt里强调"拼接路径时使用os.path.join的语义"，并且在后处理阶段检查路径中是否有明显的拼接错误。

第三种是文件名中的空格和特殊字符。这是最烦人的，因为Shell对空格的处理很敏感。mv my file.txt dest/会被解释成移动两个文件。解决方案就是所有路径都用双引号包裹，并且在Prompt里反复强调这一点。我甚至在后处理阶段加了一个自动加引号的逻辑：用正则匹配出路径模式，如果发现没有引号包裹，就自动补上。

import re def auto_quote_paths(command: str) -> str: """自动给未加引号的路径加引号""" # 匹配常见的路径模式 pattern = r'(?<!["\'])((?:\./|/|[A-Za-z]:\\)[^\s"\']+)(?!["\'])' return re.sub(pattern, r'"\1"', command)

这个正则不一定完美，但能覆盖大部分常见情况。用了之后，因为空格导致的路径错误明显减少了。

5.3 超时与长输出：别让Agent卡死在一条命令上

有些命令执行起来特别慢，比如find /或者grep -r一个大目录。如果不设超时，Agent就会一直卡在那里，用户体验极差。我的做法是默认设置30秒超时，对于已知的慢命令（比如涉及网络请求或者大文件处理的），可以单独调大超时时间。

超时之后怎么办？不能直接报错就完了，应该给模型一个反馈："命令执行超时，可能是操作范围太大，建议缩小范围重试。"模型收到这个反馈后，通常会生成一个更精确的命令，比如把find /改成find ./src。

长输出的问题前面提过，这里补充一个细节：截断的时候要保留头部和尾部。有些命令的关键信息在输出的最后几行，比如tail或者sort的结果。如果只截断头部，可能会丢失重要信息。我的做法是：如果输出超过阈值，保留前1500个字符和后500个字符，中间用...省略。

5.4 多轮对话中的上下文污染问题

这个问题比较隐蔽，但影响很大。当对话轮次多了之后，历史信息会越来越多，模型可能会被之前的内容干扰，生成不相关的命令。

我遇到过一个典型案例：用户先让Agent查了一下Python版本，然后让Agent"把刚才那个文件改一下"。模型在生成命令时，把Python版本的信息也带进去了，生成了一个包含python3.10的奇怪命令。

解决这个问题的核心思路是区分"持久上下文"和"临时上下文"。持久上下文包括当前目录、系统类型这些不变的信息，每轮都带上。临时上下文包括上一轮的命令和输出，只保留最近一两轮。更早的历史要么丢弃，要么压缩成一句话摘要。

我在实现里用了一个简单的滑动窗口：只保留最近3轮的对话历史，更早的自动丢弃。同时，每轮对话结束后，重新探测一次环境状态，确保上下文中的环境信息是最新的。

6. 从原型到可用工具：还需要补哪些能力

6.1 命令白名单与权限分级的设计思路

原型跑通之后，下一步就是把它变成一个真正能日常使用的工具。第一件要做的事就是建立命令白名单和权限分级。

我的设计是把命令分成三个等级：

这个分级不是一成不变的，你可以根据自己的使用场景调整。比如在测试环境里，可以把rm降到"谨慎"级别；在生产环境里，连mv都应该慎重。

白名单的实现方式很简单，就是一个字典：

COMMAND_LEVELS = { "safe": ["ls", "cat", "grep", "find", "wc", "head", "tail", "sort", "uniq"], "caution": ["mkdir", "mv", "cp", "sed", "awk", "chmod", "touch"], "danger": ["rm", "dd", "mkfs", "shutdown", "reboot"] }

执行前先查一下命令属于哪个等级，然后根据等级决定是直接执行、弹确认还是拒绝。这个逻辑虽然简单，但能挡住大部分误操作。

6.2 错误重试与自我修复：让Agent学会"再来一次"

一个成熟的Agent不应该在第一次失败后就放弃。我给我的工具加了一个简单的重试机制：如果命令执行失败，把错误信息反馈给模型，让模型生成一个修正后的命令，最多重试3次。

这个机制在路径错误和命令拼写错误上特别有效。比如模型第一次生成了cd /wrong/path && ls，执行失败后，模型看到错误信息，第二次就会生成cd /correct/path && ls。

但重试也要有节制。如果连续3次都失败，说明模型可能理解错了任务，这时候应该把控制权交还给用户，让用户澄清需求。我在实现里加了一个计数器，每次失败递增，成功则重置。连续失败3次就触发"求助模式"，输出一段提示让用户重新描述任务。

6.3 日志与审计：出了问题能查得到

最后但同样重要的是日志记录。Agent执行的每一条命令、每一次输出、每一个错误，都应该被记录下来。这不仅是为了排查问题，也是为了审计——万一Agent执行了某个不该执行的命令，你得知道它是什么时候、在什么情况下执行的。

我的日志格式是这样的：

[2024-01-15 14:32:01] USER: 把所有txt文件放到texts文件夹里 [2024-01-15 14:32:02] CMD: mkdir -p "texts" && mv *.txt "texts/" [2024-01-15 14:32:02] RESULT: success (returncode=0) [2024-01-15 14:32:02] OUTPUT: (empty)

日志文件按天分割，保留最近30天。如果发现异常，可以随时回溯。这个习惯是我从运维工作里带过来的，看起来不起眼，但关键时刻能救命。

7. 一些个人体会和后续可以折腾的方向

折腾Agent-Reach这类工具最大的感受是：让AI"动手"比让它"动嘴"难太多了。聊天机器人你只要调好Prompt就行，但要让Agent真正操作系统，你得考虑安全、考虑兼容、考虑错误处理、考虑用户体验，每一个环节都有无数细节。

我现在日常用的这个工具，代码量大概在800行左右，其中真正跟模型交互的部分不到200行，剩下的全是安全校验、路径处理、日志记录这些"脏活累活"。但正是这些脏活累活，决定了工具是"能跑"还是"好用"。

后续我打算尝试几个方向。一个是任务分解，让Agent能把复杂任务拆成多个子任务，逐个执行。另一个是命令缓存，对于重复执行过的命令，直接复用而不是重新生成，既省token又稳定。还有一个是多Agent协作，一个Agent负责规划，一个Agent负责执行，一个Agent负责检查，互相配合。

如果你也在做类似的事情，我的建议是：从最简单的场景开始，先把闭环跑通，再逐步增加复杂度。不要一上来就想做一个全能Agent，那样大概率会卡在半路。先让它能帮你列个目录、查个文件，再慢慢扩展到更复杂的操作。这个过程本身就是最好的学习。