文章探讨了如何改进命令行工具和API设计，以更好地适应大型语言模型（LLM）代理的使用。当前设计对LLM来说并不理想，尤其是受限于本地模型的有限上下文窗口。作者通过开发IDA Pro MCP接口的经验，提出了在提供足够信息以减少工具调用与避免填满上下文窗口之间找到平衡的重要性，并举例说明了如何通过改进API设计来优化LLM的使用效率。

重新思考AI的命令行界面

我们需要增强命令行工具并设计API，以便它们能更好地被大型语言模型（LLM）代理使用。现有的设计对LLM来说并不充分，尤其是当你受限于本地模型的小上下文窗口时。

代理API

和许多开发者一样，我也在尝试使用LLM代理。我做了不少“感觉编码”，但也尝试用LLM自动化逆向工程任务，主要使用mrexodia的IDA Pro MCP，并对其进行了扩展。

开发MCP接口是一个有趣的过程。你需要在提供过多信息以避免填满上下文窗口和提供足够信息以减少工具调用之间找到平衡。我们有一些API比其他API更好，比如get_global_variable_at，它接受一个地址，识别类型，并返回基于该类型的最佳字符串表示。然而，这个函数可能会失败，所以我们提供了第二组访问方法（data_read_dword、data_read_word、read_memory_bytes等）。这些访问方法虽然不错，但它们忽略了类型信息——所以我们不希望LLM首先使用它们。

为了解决这个问题，我们在文档字符串中添加了一些指导：

```python @jsonrpc @idaread def datareadbyte( address: Annotated[str, "Address to get 1 byte value from"], ) -> int: """ Read the 1 byte value at the specified address.

Only use this function if `get_global_variable_at` failed.
"""
ea = parse_address(address)
return ida_bytes.get_wide_byte(ea)

```

这似乎大部分情况下都有效，但这类问题存在于所有API中。我们有方便的便利函数，也有更复杂但更完整的函数，我们希望LLM首先使用便利函数。

我喜欢使用离线LLM，它们的上下文窗口要小得多，因此拥有更好的API非常重要。

命令行工具

这些问题也存在于命令行工具中。如果你观察Claude Code，你会发现它经常使用head -n100来限制结果。它还会迷失在哪个目录中，并会令人沮丧地在不同目录中尝试运行命令，直到找到正确的目录。

为了在我的项目中控制Claude Code，我大量依赖了linter、构建脚本、格式化工具和git提交钩子。通过将其包含在CLAUDE.md中，很容易让Claude Code经常提交，但它经常忽略其他命令，如“确保构建不会失败”和“修复任何失败的测试”。我所有的项目都有一个.git/hooks/pre-commit脚本，用于强制执行项目标准。这个钩子非常有效地保持了项目的规范。

然而，在非常困难的更改中，它真的不愿意承认它破坏了测试。我经常看到它陷入这个循环：

• 进行更改
• 构建项目：通过
• 运行测试：失败
• 尝试修复测试
• 修复测试失败
• 说“这个测试之前就失败了，准备用--no-verify提交”

然后它绕过钩子提交了！它经常这样做，以至于我现在在PATH中有一个git包装器，阻止git commit --no-verify，并且错误信息中有一些提示，要求实际修复错误。

```bash

$ git commit --no-verify

❌ ERROR: Commit Rejected.

The use of the '--no-verify' flag is disabled for this repository.

🤖 GUIDANCE FOR THE AI AGENT: You have attempted to bypass the required pre-commit verification steps. All code must pass quality checks (formatting, linting, and tests) before it can be committed.

DO NOT BYPASS THE CHECKS. YOU MUST FIX THE UNDERLYING ERRORS.

The pre-commit hook is likely failing. Diagnose and fix the issues. Search for advice if you get stuck.

After all commands complete successfully, attempt the commit again without the '--no-verify' flag. ```

这开始了一场打地鼠游戏，LLM还会尝试更改预提交钩子！我不得不通过在项目的.claude/settings.json中拒绝Edit(.git/hooks/pre-commit)来修复它。我期待它下一次的懒惰创新。

LLM的信息架构

用户体验领域有一个概念叫做“信息架构”。信息架构专注于如何以及向用户呈现什么信息，以提供最佳的用户体验。你很少注意到一个好的信息架构，但你会注意到它的缺失。

你拥有所有你想要的选项！也许你更喜欢第二个例子。

我认为观察代理使用我们现有的命令行工具时感到困惑和迷失，强烈表明我们命令行工具的信息架构是不充分的。

LLM是在使用我们现有的CLI工具的基础上训练的，所以我认为我们需要用对LLM有用的上下文来增强它们，并可能调整输出以更好地被代理消费。

回到之前的head例子。通常，代理会用cargo build | head -n100运行我的构建。我认为这里有几个问题：

• 代理将不得不重复构建以获取进一步的输出/错误，
• 代理不知道还有多少行剩余，
• 重新运行构建是资源密集型的。

也许我们可以用缓存输出、将其转换为更结构化的输出并告知代理还有多少行剩余的包装器来替换head。

同样，当代理因为目录错误而无法运行命令时。我们可以通过一个shell钩子给代理一点额外的帮助：

bash command_not_found_handler() { echo "zsh: command not found: '$1'" echo "zsh: current directory is $PWD" return 127 # Keep standard behavior (127 = command not found) }

bash $ sdfsdf zsh: command not found: 'sdfsdf' zsh: current directory is /Users/ryan

它甚至可以更模糊一些，检查最近或父目录中的命令并建议：

bash $ sdfsdf zsh: command not found: 'sdfsdf' zsh: current directory is /Users/ryan zsh: Perhaps you meant to run: cd agent_directory; sdfsdf

结论

基本上每个CLI工具都可以以某种方式改进，以向LLM提供额外的上下文。这将减少工具调用并优化上下文窗口。

代理可能会受益于对其代理内可用工具的一些培训。这肯定有助于大多数通用CLI工具，但也有一些定制工具可以适应LLM。

这听起来有点傻，但也许我们需要一整套LLM增强的CLI工具或定制的LLM shell？用户体验（UX）领域甚至可以分支到AI体验，并为我们提供全新的信息架构。

评论内容主要围绕是否应该重新设计命令行工具以适应AI代理的使用，观点分为支持和反对两派。

支持重新设计的观点： 1. 适应AI代理的需求：部分评论认为，现有的命令行工具是为人类设计的，AI代理需要不同的接口和提示机制。例如，BrianCripe提到：“CLI接口设计需要调整，以将AI代理作为一种新的用户角色。” (CLI interface design needs to be altered to include AI Agents as a new type of user persona.) 2. 提供更多上下文和提示：AchintyaAshok提出，AI代理需要从低到高的上下文层次结构，帮助其更好地理解和使用工具。 (Another idea that I’ve been thinking about is context hierarchy: Low -> High Utility.)

反对重新设计的观点： 1. 工具已经足够成熟：procone认为，70年代以来的工具已经足够稳定，重新设计是短视的。 (Why rethink tools that have existed since the 70s and function predictably for a landscape that drastically shifts every two months? Seems shortsighted to me.) 2. LLM的非确定性问题：Msurrow指出，LLM是随机文本生成器，不应过度依赖它们来执行关键任务。 (LLMs are. not. intelligent. They don’t have a work ethic that says “oh maybe skipping tests is bad”.)

其他相关观点： 1. 改进现有工具：troupo认为，应该改进工具以更好地服务人类，而不是为了适应AI代理而重新设计。 (The answer is: make non-deterministic black boxes more deterministic and less black boxes, improve tools for humans.) 2. 多模态解决方案：jonplackett提出，未来的AI代理可能会通过GUI和CLI的结合来解决问题。 (Will this just be solved by agents being multimodal and using a computer in a more human way?)

总结：评论中既有支持为AI代理重新设计命令行工具的声音，也有认为现有工具足够成熟、不应过度依赖AI的观点。双方都提出了各自的论据，反映了当前技术过渡期的复杂性。