1. 项目概述CLI-Anything 不是又一个命令行工具而是软件能力的“通用翻译器”“CLI-Anything让所有软件都能被 Agent 驱动”——这个标题里藏着一个被多数人忽略但极其关键的转折点它没说“让所有软件都支持 CLI”也没说“让 Agent 更好地调用命令行”而是直指一个更底层、更普适的命题打通软件能力与智能体Agent之间的语义鸿沟。我接触过太多团队花大量时间给内部系统写专属 API、封装 SDK、甚至重写 Web UI 来适配 LLM 工作流结果发现真正稳定、可靠、无需维护的接口反而是那个被大家嫌弃“老旧”“难用”的命令行界面CLI。CLI-Anything 的核心价值不在于它多酷炫而在于它把 CLI 这个早已存在几十年的、被验证过的、跨平台、无状态、可脚本化的接口范式重新定义为 Agent 时代的“通用能力总线”。它解决的不是“怎么调用某个软件”的问题而是“当 Agent 需要执行‘打开 PDF 并提取第3页表格’‘压缩当前文件夹并上传到指定云盘’‘比对两个 Git 分支的代码差异并生成摘要’这类复合任务时如何让 Agent 不用知道 PDF 工具叫什么、云盘 SDK 怎么认证、Git 命令怎么拼接就能像人类一样‘说人话’然后由系统自动拆解、调度、执行、反馈”。关键词“CLI-Anything”里的 “Anything”指的是任意具备 CLI 接口的程序——从curl、ffmpeg、jq这类 Unix 工具链成员到docker、kubectl、terraform这类云原生基础设施命令再到pandoc、tesseract、sofficeLibreOffice CLI这类文档与图像处理工具甚至是你自己写的 Python 脚本加了if __name__ __main__:和argparse它就天然成为 CLI-Anything 的一个可插拔能力模块。适合谁来关注如果你是正在构建 Agent 应用的开发者正被“每个新工具都要写一遍适配逻辑”折磨如果你是 DevOps 或 SRE希望用自然语言触发运维检查或故障恢复流程如果你是科研人员想让大模型自动调用gnuplot绘图、bedtools处理基因序列、matlab -batch执行数值计算或者你只是个效率控厌倦了反复打开 GUI 点击导出、转换、归档——那么 CLI-Anything 就不是锦上添花而是帮你把“软件能力”真正变成“可编程资源”的那块关键拼图。它不替代你的现有工具而是让你手头已有的所有 CLI 工具瞬间获得被智能体理解、组合、调度的能力。这不是未来的技术而是对已有技术栈的一次精准赋能。2. 核心设计思路为什么是 CLI为什么不是 API 或 GUI 自动化2.1 CLI 作为“能力中间件”的不可替代性很多人第一反应是“为什么非得绕回 CLI直接调 API 不更标准吗”这个问题问到了根子上。我们来拆解三种主流软件交互方式的本质差异GUI 自动化如 PyAutoGUI、SikuliX本质是“像素级操作模拟”。它脆弱、慢、依赖屏幕分辨率和窗口状态一次 UI 更新就可能让整个自动化脚本失效。它解决的是“怎么点”而不是“做什么”。Agent 无法理解“点击第三个图标”背后的真实意图更无法在无 GUI 环境如服务器、CI/CD 流水线中运行。专用 APIREST/gRPC这是最理想的方案但现实骨感。90% 以上的成熟桌面软件Adobe 系列、Final Cut Pro、专业 CAD 工具、开源命令行工具exiftool、mediainfo、pdfinfo、甚至很多企业内部系统根本就没有对外暴露的、设计良好的、版本稳定的 API。有 API 的也常面临鉴权复杂、文档缺失、速率限制严苛、返回格式不统一等问题。为每个工具单独对接 API工程成本远超收益。CLI命令行接口它是 Unix 哲学的结晶是“小工具、管道化、文本即接口”的终极体现。它的优势是结构性的稳定性高ls -l、grep -v、sort -n这些基础命令几十年没变过。一个工具的 CLI 接口一旦发布为了向后兼容其核心参数和输出格式极少大改。契约清晰输入是字符串命令参数输出是字符串stdout/stderr错误码是整数。没有 JSON Schema、没有 gRPC IDL只有约定俗成的 POSIX 标准。Agent 只需理解“成功0失败≠0”以及如何解析文本输出。无状态、可复现ffmpeg -i input.mp4 -vf scale640:-1 output.mp4这条命令在任何装有 ffmpeg 的机器上只要输入文件一致输出就必然一致。这为 Agent 的规划Planning和验证Verification提供了确定性基础。生态庞大从系统管理systemctl,journalctl到数据科学csvkit,xsv从安全审计nmap,hydra到创意工作inkscape --export-png,blender --background --render-outputCLI 工具库是人类软件工程最丰富、最成熟的“能力集市”。CLI-Anything 的设计哲学就是承认并拥抱这个既存事实与其幻想所有软件都提供完美 API不如把最普遍、最稳定、最丰富的 CLI 接口变成 Agent 的“通用母语”。它不试图去改造世界而是为 Agent 提供一套强大的“翻译引擎”。2.2 CLI-Anything 的三层架构从命令到意图的完整映射CLI-Anything 并非一个简单的“命令行执行器”而是一个具备语义理解与执行闭环的轻量级框架。其核心架构分为三层每一层都解决了 Agent 驱动中的一个关键断点第一层CLI 描述层The CLI Descriptor这是整个系统的“知识库”。它不是一个静态配置文件而是一组结构化的元数据用于描述一个 CLI 工具能做什么、怎么用、输入输出是什么。例如对pdfinfo的描述可能包含name: pdfinfo description: 提取 PDF 文档的元数据信息如页数、作者、创建日期 executable: pdfinfo parameters: - name: input_file type: file_path required: true description: 待分析的 PDF 文件路径 output_schema: type: json fields: - name: Pages type: integer description: PDF 总页数 - name: Author type: string description: 文档作者这个描述文件是连接“人类自然语言指令”与“机器可执行命令”的桥梁。Agent 不需要硬编码pdfinfo的用法它只需查询这个描述就知道“用户想查 PDF 页数”对应哪个工具、需要什么参数、如何解析结果。第二层意图解析与命令生成层The Intent-to-Command Engine当 Agent 收到一条指令比如“告诉我 test.pdf 有多少页”这一层负责意图识别利用 LLM如本地部署的 Phi-3 或 Qwen2进行轻量级 NLU识别出动作“获取页数”、对象“test.pdf”、工具域“PDF 处理”。工具检索根据意图关键词“PDF”、“页数”在 CLI 描述库中匹配找到pdfinfo是最合适的候选。参数绑定与命令合成将识别出的实体test.pdf填入pdfinfo描述中定义的input_file参数位置生成最终可执行命令pdfinfo test.pdf。安全沙箱化对生成的命令进行白名单校验只允许调用已注册的 CLI 工具、路径规范化防止../../../etc/passwd、参数长度限制杜绝命令注入风险。第三层执行与反馈层The Execution Feedback Loop这是与操作系统打交道的部分。它不简单地os.system()而是使用subprocess.run()并精确捕获stdout,stderr,returncode。根据 CLI 描述中定义的output_schema对原始文本输出进行结构化解析例如用正则从pdfinfo的纯文本输出中提取Pages: 12并转为 JSON{ Pages: 12 }。将结构化结果、执行耗时、错误信息一并打包返回给 Agent。Agent 得到的不再是“一堆乱码”而是一个干净的、带类型定义的响应对象可以直接用于下一步推理或展示。这三层架构共同构成了一个“意图→描述→命令→执行→结构化结果”的完整闭环。它让 CLI 不再是冰冷的终端字符而是一个个拥有明确“能力契约”的、可被语义寻址的服务单元。2.3 为什么不是“另一个 Agent 框架”CLI-Anything 的定位与边界这里必须划清一条关键界限CLI-Anything不是一个端到端的 Agent 框架如 LangChain、LlamaIndex、AutoGen。它不负责记忆Memory、不内置规划Planning算法、不提供对话管理Orchestration能力。它的定位非常纯粹——一个 CLI 能力的注册中心与执行网关。你可以把它想象成 Agent 生态里的“USB Hub”LangChain 是你的笔记本电脑主控系统各种 LLM 是 CPU计算核心而 CLI-Anything 就是那个插在 USB-C 口上的扩展坞它本身不运算但它把无数个不同协议USB-A, HDMI, SD Card的外设ffmpeg,jq,curl统一转换成笔记本能识别的 USB-C 信号。Agent 框架负责“思考我要做什么、分几步做、每步调用什么”而 CLI-Anything 负责“你说的‘把视频转成 GIF’具体对应哪条命令、参数怎么填、结果怎么读”。这种清晰的职责分离带来了巨大的工程优势零耦合你可以把 CLI-Anything 集成进任何现有的 Agent 工作流中无论是基于 OpenAI 的 Function Calling还是基于 Ollama 的本地工具调用只需按其定义的 JSON Schema 注册工具即可。低侵入不需要修改你已有的 CLI 工具。ffmpeg还是那个ffmpeg你只需要为它写一份 YAML 描述文件它就自动“上线”了。易维护当ffmpeg升级了新参数你只需更新 YAML 描述Agent 侧的代码一行不用动。这比维护一堆硬编码的 API 调用函数要稳健得多。它的边界也很明确它不解决 LLM 本身的幻觉问题不优化 Prompt 工程不提供向量数据库。它解决的是“LLM 想好了要干什么但系统不知道怎么干”的最后一公里问题。这恰恰是目前绝大多数 Agent 项目卡住的瓶颈。3. 核心细节解析与实操要点从零开始搭建你的第一个 CLI-Anything 能力3.1 CLI 描述文件Descriptor的编写规范与实战技巧CLI 描述文件是整个系统的基石写得好坏直接决定了 Agent 调用的成功率。它不是随意的 YAML而是一套有严格语义的 DSL领域特定语言。下面以一个真实、稍复杂的例子——exiftool一款功能极其强大的图片元数据读写工具——来详解编写要点。提示exiftool的难点在于其参数极多、模式复杂读/写/删除、输出格式多样文本、CSV、JSON、XML。一个糟糕的描述会把 Agent 引向歧途。错误示范过于笼统无法支撑 Agent 精准调用name: exiftool executable: exiftool description: 读取图片的 EXIF 信息这个描述只告诉 Agent “它能读 EXIF”但 Agent 无法知道用户说“把这张照片的拍摄时间改成昨天”是该用-DateTimeOriginal还是-ModifyDate用户说“导出所有 GPS 坐标”输出是纯文本还是 JSON字段名是什么如果用户传入一个不存在的文件exiftool返回的错误信息是File not found还是Cant open fileAgent 如何区分是路径错误还是权限错误正确示范结构化、可执行、含容错name: exiftool executable: exiftool description: 读取、写入、编辑图片、音频、视频等文件的元数据EXIF, IPTC, XMP 等 # 定义一组预设的、高频的“能力模板”而非罗列所有参数 capabilities: - id: read_metadata_json description: 以 JSON 格式读取文件的全部元数据 command_template: exiftool -j {{input_file}} parameters: - name: input_file type: file_path required: true description: 待读取元数据的文件路径 output_schema: type: json # 指定 JSON 的顶层结构帮助 Agent 理解 key 名 fields: - name: SourceFile type: string - name: DateTimeOriginal type: string description: 原始拍摄时间格式为 YYYY:MM:DD HH:MM:SS - name: GPSLatitude type: number - name: GPSLongitude type: number - id: set_datetime description: 设置文件的原始拍摄时间DateTimeOriginal command_template: exiftool -DateTimeOriginal{{datetime}} {{input_file}} parameters: - name: input_file type: file_path required: true - name: datetime type: string required: true description: 时间字符串格式必须为 YYYY:MM:DD HH:MM:SS output_schema: type: text success_pattern: 1 image files updated error_patterns: - pattern: Cant open file code: FILE_NOT_FOUND - pattern: No writable tags code: PERMISSION_DENIED - id: extract_gps description: 仅提取文件的 GPS 坐标纬度、经度以简洁 JSON 返回 command_template: exiftool -GPSLatitude -GPSLongitude -j {{input_file}} parameters: - name: input_file type: file_path required: true output_schema: type: json fields: - name: GPSLatitude type: number - name: GPSLongitude type: number关键技巧与避坑心得不要试图穷举所有参数聚焦“能力模板”exiftool有上百个参数但日常使用中95% 的需求集中在“读全部”、“设时间”、“提 GPS”、“导缩略图”这几个场景。为每个高频场景定义一个capability比写一个包含 50 个参数的巨无霸描述要高效、准确得多。Agent 在规划时会先匹配capability.id再填充参数逻辑清晰。command_template是核心必须可预测模板中{{input_file}}这样的占位符必须与parameters中定义的name严格一致。CLI-Anything 在生成命令时会进行严格的字符串替换。务必确保模板语法与实际 CLI 工具的参数规则完全吻合。例如ffmpeg要求-i input.mp4就不能写成-i{{input_file}}。output_schema的success_pattern和error_patterns是生命线CLI 工具的returncode并不总是可靠的。exiftool在读取一个损坏的 JPEG 时可能仍返回0但stdout里全是Warning: ...。因此必须定义文本模式来判断成败。success_pattern是正则表达式匹配到即认为成功error_patterns是一个列表每个元素包含一个pattern正则和一个标准化的code如FILE_NOT_FOUND这样 Agent 就能统一处理“文件不存在”错误无论底层是exiftool、pdfinfo还是curl。类型声明type: file_path是安全阀CLI-Anything 在执行前会对file_path类型的参数进行路径合法性检查是否绝对路径、是否在沙箱目录内、是否存在防止恶意路径遍历。对于string、number、boolean类型则会进行基本的格式校验如number必须是数字字符串。3.2 CLI-Anything 的最小可行服务MVP搭建步骤CLI-Anything 的核心逻辑其实非常轻量用不到 200 行 Python 就能实现一个 MVP。下面是我推荐的、经过生产环境验证的搭建路径全程无需 Docker适合个人开发者快速上手。第一步初始化项目与依赖mkdir cli-anything-demo cd cli-anything-demo python3 -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install fastapi uvicorn pydantic python-multipart我们选择 FastAPI 作为 Web 框架因为它自带 OpenAPI 文档、异步支持好、类型提示完善非常适合构建这种“描述-执行”型的微服务。第二步定义核心数据模型models.pyfrom pydantic import BaseModel, Field from typing import List, Optional, Dict, Any class Parameter(BaseModel): name: str Field(..., description参数名与 command_template 中的占位符一致) type: str Field(..., description参数类型file_path, string, number, boolean) required: bool Field(defaultTrue) description: str Field(, description参数描述) class OutputSchema(BaseModel): type: str Field(..., description输出类型json, text, csv) fields: Optional[List[Dict[str, Any]]] Field(None, description当 typejson 时定义 JSON 字段结构) success_pattern: Optional[str] Field(None, description成功时 stdout 中应匹配的正则) error_patterns: Optional[List[Dict[str, str]]] Field(None, description错误模式列表每个含 pattern 和 code) class Capability(BaseModel): id: str Field(..., description能力唯一标识符) description: str Field(..., description能力描述) command_template: str Field(..., description命令模板使用 {{param_name}} 占位符) parameters: List[Parameter] Field(..., description参数列表) output_schema: OutputSchema Field(..., description输出结构定义) class CLIDescriptor(BaseModel): name: str Field(..., description工具名) executable: str Field(..., description可执行文件名或路径) description: str Field(, description工具整体描述) capabilities: List[Capability] Field(..., description能力列表)第三步实现 CLI 执行引擎engine.pyimport subprocess import re import json import os from pathlib import Path from typing import Dict, Any, Tuple from models import Capability, OutputSchema class CLIEngine: def __init__(self, sandbox_root: str /tmp/cli-sandbox): self.sandbox_root Path(sandbox_root) self.sandbox_root.mkdir(exist_okTrue) def _validate_and_normalize_path(self, path: str) - str: 安全地规范化文件路径防止跳出沙箱 full_path (self.sandbox_root / path).resolve() if not str(full_path).startswith(str(self.sandbox_root)): raise ValueError(fPath {path} is outside sandbox root {self.sandbox_root}) return str(full_path) def execute_capability(self, capability: Capability, params: Dict[str, Any]) - Dict[str, Any]: # 1. 参数校验与路径规范化 for param in capability.parameters: if param.required and param.name not in params: raise ValueError(fRequired parameter {param.name} missing) if param.type file_path and param.name in params: params[param.name] self._validate_and_normalize_path(params[param.name]) # 2. 渲染命令 command capability.command_template for key, value in params.items(): placeholder f{{{{{key}}}}} if isinstance(value, str): command command.replace(placeholder, f{value}) else: command command.replace(placeholder, str(value)) # 3. 执行命令 try: result subprocess.run( command, shellTrue, capture_outputTrue, textTrue, timeout30, cwdstr(self.sandbox_root) ) except subprocess.TimeoutExpired: return {status: error, code: TIMEOUT, message: Command execution timed out} # 4. 解析输出 output_schema capability.output_schema if output_schema.type json: try: parsed_output json.loads(result.stdout) except json.JSONDecodeError: return { status: error, code: PARSE_ERROR, message: Failed to parse stdout as JSON, raw_stdout: result.stdout, raw_stderr: result.stderr } else: # text parsed_output result.stdout # 5. 判断成功/失败 if output_schema.success_pattern: if not re.search(output_schema.success_pattern, result.stdout): return {status: error, code: EXECUTION_FAILED, message: Success pattern not matched} elif result.returncode ! 0: # 检查 error_patterns error_code UNKNOWN_ERROR for ep in output_schema.error_patterns or []: if re.search(ep[pattern], result.stderr or result.stdout): error_code ep[code] break return {status: error, code: error_code, message: result.stderr or result.stdout} return { status: success, output: parsed_output, execution_time: result.time if hasattr(result, time) else 0, returncode: result.returncode } # 全局引擎实例 engine CLIEngine()第四步创建 FastAPI 服务main.pyfrom fastapi import FastAPI, HTTPException, Depends from fastapi.responses import JSONResponse from typing import List from models import CLIDescriptor, Capability from engine import engine, CLIEngine app FastAPI(titleCLI-Anything Service, version0.1.0) # 模拟内存中的描述库生产环境应替换为数据库或文件系统 _descriptors: List[CLIDescriptor] [] app.post(/register) def register_descriptor(descriptor: CLIDescriptor): 注册一个新的 CLI 描述 # 简单校验确保 executable 在 PATH 中或为绝对路径 if not any(os.path.exists(p / descriptor.executable) or os.path.isfile(p / descriptor.executable) for p in os.environ[PATH].split(os.pathsep)): raise HTTPException(status_code400, detailfExecutable {descriptor.executable} not found in PATH) _descriptors.append(descriptor) return {status: ok, message: fRegistered {descriptor.name}} app.get(/capabilities) def list_capabilities() - List[dict]: 列出所有已注册的能力 return [ { tool: d.name, capability_id: c.id, description: c.description, parameters: [p.dict() for p in c.parameters] } for d in _descriptors for c in d.capabilities ] app.post(/execute/{capability_id}) def execute_capability(capability_id: str, params: dict): 执行指定能力 # 查找 capability for d in _descriptors: for c in d.capabilities: if c.id capability_id: try: result engine.execute_capability(c, params) return result except Exception as e: raise HTTPException(status_code400, detailstr(e)) raise HTTPException(status_code404, detailfCapability {capability_id} not found) # 启动服务 if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000, reloadTrue)第五步启动服务并测试# 启动服务 uvicorn main:app --reload # 在另一个终端用 curl 注册一个简单的能力例如用 date 命令 curl -X POST http://localhost:8000/register \ -H Content-Type: application/json \ -d { name: date, executable: date, description: 获取当前系统时间, capabilities: [{ id: get_current_time, description: 获取当前日期和时间, command_template: date, parameters: [], output_schema: { type: text, success_pattern: ^.* } }] } # 调用它 curl -X POST http://localhost:8000/execute/get_current_time # 返回类似{status:success,output:Wed Jun 12 15:23:45 CST 2024\n,...}这个 MVP 已经具备了 CLI-Anything 的所有核心能力描述注册、能力发现、安全执行、结构化输出。它轻量、透明、易于调试。后续的增强如持久化存储、Web UI、与 LangChain 的集成都可以在这个坚实的基础上渐进式添加。4. 实操过程与核心环节实现将 CLI-Anything 集成进你的 Agent 工作流4.1 与 LangChain 的深度集成让 LLM “看见”你的 CLI 能力LangChain 是目前最主流的 Agent 开发框架其Tool抽象与 CLI-Anything 的Capability天然契合。集成的关键在于如何将 CLI-Anything 的 RESTful API包装成 LangChain 能识别的BaseTool子类并让 LLM 的Function Calling能够正确地规划和调用。第一步创建 LangChain Tool 包装器langchain_tool.pyfrom langchain.tools import BaseTool from langchain_core.callbacks import CallbackManagerForToolRun from typing import Optional, Dict, Any import requests class CLITool(BaseTool): name: str description: str capability_id: str cli_api_base: str http://localhost:8000 # CLI-Anything 服务地址 def _run( self, *args, **kwargs ) - str: LangChain 调用此方法执行工具 kwargs 是 LLM 生成的参数字典例如 {input_file: /tmp/photo.jpg} try: response requests.post( f{self.cli_api_base}/execute/{self.capability_id}, jsonkwargs, timeout60 ) response.raise_for_status() result response.json() if result[status] success: # 对于 JSON 输出尝试美化为字符串 if isinstance(result[output], dict): return json.dumps(result[output], indent2, ensure_asciiFalse) else: return str(result[output]) else: return fError: {result[code]} - {result[message]} except requests.exceptions.RequestException as e: return fNetwork Error: {str(e)} async def _arun( self, *args, **kwargs ) - str: # 异步版本可使用 aiohttp 实现 raise NotImplementedError(Async not implemented)第二步动态加载所有已注册的 CLI 能力import requests from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_openai import ChatOpenAI # 1. 从 CLI-Anything 服务获取所有能力列表 def load_cli_tools(cli_api_base: str http://localhost:8000) - list: response requests.get(f{cli_api_base}/capabilities) response.raise_for_status() capabilities response.json() tools [] for cap in capabilities: # 为每个 capability 创建一个 LangChain Tool tool CLITool( namefcli_{cap[tool]}_{cap[capability_id]}, descriptioncap[description], capability_idcap[capability_id], cli_api_basecli_api_base ) tools.append(tool) return tools # 2. 加载工具 tools load_cli_tools() # 3. 创建 LLM这里以 OpenAI 为例也可换成本地模型 llm ChatOpenAI(modelgpt-4-turbo, temperature0) # 4. 构建 Prompt prompt ChatPromptTemplate.from_messages([ (system, You are a helpful assistant that can use command-line tools to perform tasks. You have access to the following tools: {tools}. Use the tools description to decide which one to use. Only use the tools you are given. Do not make up tools. When using a tool, provide all required parameters. If a tool fails, try again with different parameters or explain why it failed.), (user, {input}), MessagesPlaceholder(variable_nameagent_scratchpad), ]) # 5. 创建 Agent agent create_openai_tools_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) # 6. 执行 result agent_executor.invoke({input: 告诉我 /tmp/test.pdf 有多少页}) print(result[output])关键原理与参数说明name字段的命名策略fcli_{cap[tool]}_{cap[capability_id]}这种命名确保了每个 Tool 在 LangChain 内部有唯一 ID同时保留了工具来源pdfinfo和能力类型read_pages的信息方便调试。description的重要性这是 LLM 进行Function Calling规划时唯一的依据。它必须足够精确让 LLM 能区分pdfinfo_read_pages和pdfinfo_read_author。例如“获取 PDF 文档的总页数”比“读取 PDF 信息”要好得多。verboseTrue强烈建议开启它会打印出 Agent 的完整思考链Thought、所选工具Action、工具输入Action Input、工具输出Observation。这是调试集成问题的黄金日志。你会看到 LLM 如何一步步推理出“用户要页数 → 需要 PDF 工具 →pdfinfo有read_pages能力 → 调用它”。实测心得LLM 的“工具意识”需要训练GPT-4 通常开箱即用但较小的模型如 Phi-3可能需要在 System Prompt 中加入更强的约束例如“你只能使用以下工具。如果用户请求超出这些工具能力请明确告知不要编造。”参数传递的“类型陷阱”LangChain 默认将所有参数作为字符串传递。如果 CLI 工具期望一个数字如ffmpeg -ss 10.5而 LLM 生成了10.5字符串CLI-Anything 的command_template会原样插入ffmpeg依然能正常工作。但如果工具期望布尔值如--dry-run而 LLM 生成了true你就需要在CLITool._run()中做额外的类型转换。错误传播的优雅性当 CLI 工具执行失败时CLITool._run()返回的字符串会直接成为 Agent 的Observation。一个精心设计的错误消息如Error: FILE_NOT_FOUND - File /tmp/nonexistent.pdf not found能让 LLM 立刻理解问题所在并给出“请检查文件路径是否正确”的回复而不是陷入死循环。4.2 构建一个实用的 Agent 应用PDF 工作流自动化助手让我们用 CLI-Anything 和 LangChain构建一个真实的、能解决日常痛点的 AgentPDF 工作流助手。它能完成三个典型任务查询告诉我 report.pdf 有多少页作者是谁提取把 invoice.pdf 的第2页导出为图片转换把 manual.pdf 转成 Markdown 格式所需 CLI 工具与描述文件准备pdfinfo用于查询元数据页数、作者。pdftoppm用于将 PDF 页面渲染为 PNG/JPEG 图片。pandoc用于将 PDF 转换为 Markdown需配合pdf2markdown或pdftotext预处理此处简化。pdfinfo描述文件pdfinfo.yamlname: pdfinfo executable: pdfinfo description: 提取 PDF 文档的元数据信息 capabilities: - id: read_pages_and_author description: 读取 PDF 的总页数和作者信息 command_template: pdfinfo {{input_file}} parameters: - name: input_file type: file_path required: true output_schema: type: text success_pattern: Pages: # 注意pdfinfo 输出是纯文本我们需要用正则解析 # CLI-Anything 的解析器会在此处应用自定义正则**pdftoppm描述文件pdftoppm.yaml