周末我一直在兴致勃勃地开发一个AI编程命令行界面（CLI），这要归功于我脑海中突然冒出的一个想法。下图是它的启动界面。我把它命名为“DDUDU DDUDU”，灵感来源于我哼唱这首歌的时候。 众所周知，模型运行的框架与模型本身的性能同样重要。即使是同一个模型，运行在不同的框架上，结果也会大相径庭。我希望专注于设计方面，并进一步完善它。最初，我使用现有的工具，通过添加插件（例如OMO/OMC）来实现，但后来我觉得从零开始构建一个可能更有意思。我考虑过基于树莓派那种开放式定制区域的理念来构建，但我也想尝试自己设计用户界面来学习。由于设计是这个概念最重要的方面，我最终决定从头开始研究并构建它。 我最近在使用 OpenCode 和 OMO 的过程中获得了非常棒的体验，因此我想深入剖析它们的优势所在，并从零开始将它们整合到我的项目中。目前我已经订阅了许多服务（Claude、Codex、Gemini），所以我打算复用现有的本地凭据，并在此基础上添加我所需的上下文管理和工具组合。虽然称之为“从零开始”可能有些夸张，因为它是一个基于现有服务的基础架构和设计知识库构建的自定义项目（甚至生产环境的工作也是使用 Codex 完成的）。然而，我之所以启动这个项目，是因为我知道自己需要亲身体验，才能更好地理解如何构建这些组件。 这些都是现有的功能，你们中的许多人可能已经很熟悉了，但由于我是从零开始构建的，所以我必须考虑所有这些因素。总结如下： [1] 模型调用和路由。正如您可能从经验中了解到的，每个提供商都有其自身的优势。我尝试通过将模式划分为任务来构建路由：一个用于需要复杂决策的稳健编排模型，一个用于简单迭代执行的快速模型，以及另一个用于设计和设计决策的模型。 [2] 工具配置。在研究各种编码代理时，我发现了各种各样的工具组合。其范围从文件 I/O 和 shell 执行等基本操作，到代码库搜索、符号导航以及将任务委派给其他代理等。我们将逐一检查每个工具，并分析其必要性。我们还会不断调整内置功能的数量以及移除 MCP 等扩展的功能。 [3] 上下文管理。这涉及到在有限的上下文窗口中仅填充当前所需的信息。虽然包含整个对话看似可行，但积累不必要的上下文实际上会降低性能。我一直对上下文压缩特别感兴趣，思考何时压缩以及如何压缩，以及如何确保用户流程在压缩后仍然保持完整。 [4] 会话和状态维护。虽然人类自然会继续执行之前的任务，但从模型的角度来看，每一次操作都是一个全新的请求。我们需要一个流程，允许我们恢复或分支会话、总结长时间的会话，并将其移至下一个任务。委托的任务可以使用 Git 工作树进行隔离，以避免干扰主任务；长时间运行的任务可以移至后台，以避免阻塞主流程。这也是我们正在解决这些问题的地方。 [5] 验证和恢复。我并没有试图一次性编写出正确的代码，而是专注于创建一个完整的循环，在代码编写完成后对其进行验证，修复任何错误，并在必要时将其传递给另一个代理，如果验证通过，则将其应用到实际的工作区。我还在尝试一种工作流，将验证结果保存在内存中，以便在遇到类似任务时可以重用。 [6] 内存。我正在尝试一种结构，它允许针对当前会话的工作上下文、从过去会话中吸取的经验教训、代码库的结构知识以及重复的规则和流程设置不同的保留期限和存储方法。目前我还没有找到最佳方案，仍在尝试各种组合。 [7] 权限和信任边界。问题在于应该赋予代理多大的自主权。完全允许所有操作很危险，而每次都请求权限又会降低其速度。我正在开发一种结构，允许对每个工具进行细粒度的权限/确认/拒绝，并允许整体权限级别逐步过渡。（不过说实话，这与人工智能推荐的方法并没有显著差异。） [8] 用户界面/用户体验。我需要能够一目了然地看到代理当前正在执行的操作、后台任务的状态以及外部工具连接的状态。我最初使用 Ink 开发了 TUI，但它过于臃肿，所以我改用了基于 Rust 的 Ratatui。输入法和易用性方面的选择非常明智。（这让我意识到 Opencode 的优势不仅在于其设计，还在于其 OpenTUI 的卓越品质。）我个人非常喜欢 TUI，并且对终端的简洁设计和易读性有着近乎痴迷的追求。因此，我致力于通过颜色和布局，使信息尽可能快速便捷地呈现。这方面我投入的时间最多，因为它既满足了功能需求，也符合我的个人偏好。 除此之外，整个系统的数据结构、斜杠命令和通知显示方式也在不断发展，这令人兴奋。我仍在努力改进一些基本功能，一旦取得比现有框架更好的成果，我会分享更多信息。 我的目标是在现有框架的基础上进行增强，并构建一个比树莓派更优秀的模块化框架，让每个人都能轻松创建自己的命令行工具。 github.com/subinium/ddududdudu