我受够了代理限制，所以我构建了 AgInTiFlow

我受够了那些围绕严肃代理工作而设置的刻薄又吝啬的限制。

这句话多少有点情绪化，但这确实是最真实的起点。我一直在使用现有的编码代理，也喜欢它们的很多部分。Codex、Claude Code、Gemini CLI、Copilot 以及其他工具都推动了这个领域的发展。但当我尝试把代理真正用于实际项目时，我不断遇到同一个现实问题：界面很强大，但工作流依然让人觉得被框得太死。

有时限制来自成本。有时来自上下文。有时是会话事后无法被清晰检查。有时是网页界面与终端脱节。有时是某次工具运行悄悄失败，或者生成了一个我要费力去找的产物。有时代理只是说了一句“done”，但工作其实根本没有被验证。

于是我开始构建我自己的代理工作空间：AgInTiFlow。

• GitHub：https://github.com/lazyingart/AgInTiFlow
• npm：https://www.npmjs.com/package/@lazyingart/agintiflow
• 网站：https://flow.lazying.art

安装：

npm install -g @lazyingart/agintiflow
aginti

启动本地 Web UI：

aginti web --port 3210

AgInTiFlow 的目标并不只是成为另一个聊天框。它是一个本地的 Web + CLI 代理工作空间，从真实的项目文件夹出发，并让整个工作过程保持可检查性。

图 1. AgInTiFlow 从终端启动，位于项目文件夹内部，并且从一开始就能看到浏览器、shell、文件、Docker、网页搜索和 scout 支持。

问题不只是智能

当前这一代模型已经足够有用。缺失的部分往往不是原始智能，而是工作的纪律性。

当我让代理开发软件、写论文、搭建网站、制作 LaTeX 报告、检查代码库、生成图像或管理 Git 工作流时，我要的不只是文字输出。我想要的是一个理解项目文件夹并且能够留下证据的系统。

对于严肃工作，代理需要能回答这样一些问题：

• 我现在在哪个目录里工作？
• 哪些文件被改动了？
• 是哪条命令失败了？
• 生成的 PDF、APK、图像或截图在哪里？
• 是哪个会话生成了这个产物？
• 我明天还能继续这个会话吗？
• 我能否在浏览器里检查同一份工作？
• 代理真的验证过结果了吗？

大多数代理工作流仍然让其中一些问题变得比应有的更难回答。

AgInTiFlow 试图把这些能力变成一等公民。

CLI 用于工作，Web 用于检查

终端依然是启动技术工作的最快场所。代码仓库在那里，Git 在那里，开发者也早已习惯在命令和路径中思考。

但终端并不适合所有事情。PDF 预览、生成的图像、很长的运行日志、模型选择器、画布产物或者截图，在浏览器中都会更容易检查。

因此，AgInTiFlow 在同一个项目状态之上提供了两个界面：

• aginti 用于交互式 CLI。
• aginti web 用于本地 Web 应用。

图 2. 公开网站展示了这个产品想要呈现的形态：终端优先、Web 同步，并附着在同一份本地工作之上。

目标不是用 Web 应用取代终端，也不是用终端取代 Web 应用。目标是让每种界面都去做自己最擅长的事。

CLI 用于快速交互。Web 应用用于可见性：会话、运行日志、产物、文件、截图、PDF、图像、设置和项目状态。

图 3. 本地 Web UI 可以继续选定的对话、显示项目控制项、暴露路由设置，并让运行输出在聊天旁边保持可见。在这个截图中，会话生成了一张熊猫图片，并在助手回复和运行时输出中记录了该产物路径。

廉价模型改变了架构

我现在构建这个系统的原因之一是 DeepSeek。

当模型调用很昂贵时，代理系统往往会变得保守。每一次路由、检查、重试、总结和 scout 都足够花钱，于是你就会开始围绕稀缺性来做设计。

DeepSeek V4 改变了这个方程。它足够强，也足够便宜，让我可以用不同的方式设计代理：

• 使用 DeepSeek V4 Flash 进行快速路由、短任务、shell 任务和基础规划。
• 使用 DeepSeek V4 Pro 处理更困难的编码、调试、研究、写作和架构任务。
• 保留 OpenAI/Codex 风格模型，作为有用时可调用的备用或包装路由。
• 保留 Venice、Qwen、mock mode 和辅助图像提供方，以处理特定提供方相关的工作。

图 4. 模型层是基于角色的：路由模型、主模型、备用/包装模型以及辅助模型，各自承担不同工作，而不是一个含糊不清的下拉框。

这很重要，因为一个好的本地代理不应该依赖某一种模型身份。有些任务需要速度。有些需要上下文。有些需要工具纪律。有些需要不同的策略配置。有些需要图像生成。有些需要廉价的 scout 模型，在主模型行动前先检查代码库的某个角落。

AgInTiFlow 把模型选择视为工作流设计的一部分。

本地会话应该是持久的

真实项目不会只活在一个提示词里。

它有文件系统、Git 状态、生成的输出、命令日志、截图、会话历史、环境说明，有时还会有浏览器或模拟器。如果代理失去了这些，它就失去了工作本身。

AgInTiFlow 正在朝着一种中心化会话模型演进：

• 规范会话存放在 ~/.agintiflow/sessions/<session-id>/ 下。
• 项目文件夹可以在 .aginti-sessions/ 下保留轻量级指针。
• 产物归属于会话。
• 项目路径、标题、创建时间和模型角色都会被跟踪。
• aginti resume 可以重新连接到之前的工作。

这是一个很小的设计选择，却有很大的影响。用户不应该还得记住哪个临时目录或浏览器标签页里藏着有用输出。会话本身应该知道。

产物才是真相

代理太喜欢说“done”了。

我希望 AgInTiFlow 更加以产物为中心。如果它构建了什么，就应该有一个可见的输出。如果它编辑了代码，就应该有一个 diff。如果它声称测试通过，就应该有命令结果。如果它生成了 PDF、截图、图像或应用，这个产物就应该能从会话中访问到。

图 5. 本地 Web 应用可以检查同一项目会话中生成的 PDF、图像和画布输出等产物。

这也是为什么 Web UI 很重要。终端转录并不足以覆盖所有类型的工作。当任务会产生视觉产物时，检查界面也应该是可视化的。

Supervisor-Student 循环

我关注的另一个设计是监督机制。

大多数代理都以单一循环运行：读取提示词、规划、调用工具、回答。对于小任务这没问题，但更大的任务需要第二种智能：一个监控者，持续追问这项工作是否真的在朝着完成前进。

在 AgInTiFlow 中，我正在试验一种轻量级的 supervisor-student 模式。

student 循环负责主要工作：

• 检查文件
• 规划
• 编辑
• 运行命令
• 生成产物
• 总结

supervisor 循环负责观察失败模式：

• 重复的命令错误
• 缺失的环境工具
• 薄弱的验证
• 错误的模型路由
• 糟糕的文件名或隐藏的输出
• 没有证据的总结
• 任务在真正目标完成前就停止

supervisor 不应该对每一步都事无巨细地干预。它只应在必要时打断，然后改进技能、工具集、提示词或路由策略，让 student 继续前进。

重点不只是监督某一个任务。重点是在每次任务后改进代理本身。如果 AgInTiFlow 在 Android、LaTeX、Git、Python 打包、网站部署或系统维护上失败了，修复方案应该能够被复用。

图 6. 一个受监督的 Android 任务构建了一个 Kotlin/Jetpack Compose 小费分摊应用，运行了测试，将其安装到模拟器中，捕获了证据，并提交了结果。

这正是我关心的循环类型：不是抽象意义上的“写代码”，而是构建、测试、安装、检查、截图并提交。

AAPS：Prompt is code, artifact is truth

AgInTiFlow 也连接到我正在构建的另一个更大的项目：AAPS：

• npm：https://www.npmjs.com/package/@lazyingart/aaps

AAPS 的全称是 Autonomous Agentic Pipeline Script。它的理念很简单：

Prompt is code, artifact is truth.

换句话说，一个严肃的代理工作流不应该只是一段很长的指令。它应该是一条具名的流水线，带有输入、输出、路由、验证、恢复和产物。

例如，一个大型工作流可能包括：

• 检查项目
• 选择方法
• 运行命令
• 验证输出
• 从已知失败中恢复
• 撰写报告
• 发布产物

这种结构对于长时间运行的工作很重要。一本书、一篇论文、一个应用、一个网站、一次数据分析或一条研究流水线，不应该依赖模型在一个上下文窗口里记住每一步。

AgInTiFlow 是本地代理工作空间。AAPS 是复杂工作流的显式支撑框架。我把它们看作同一方向的两面：让自主工作更可检查、可恢复、可验证。

它现在能做什么

AgInTiFlow 仍在演进中，但它已经支持一组很有用的本地工作流：

• 交互式 CLI 会话
• 本地 Web UI
• 文件列表、读取、搜索、写入和补丁
• shell 执行
• Docker 工作空间模式
• 网页搜索
• scout 风格的上下文收集
• 在 DeepSeek、OpenAI、Venice、Qwen 和 mock mode 之间进行模型路由
• 辅助图像生成路由
• 项目会话与恢复
• 画布、PDF、图像和产物检查
• 面向 coding、writing、research、GitHub、LaTeX、Android、websites、maintenance 等场景的配置化工作

图 7. AgInTiFlow 通过 npm 分发，因此可以在本地机器上快速安装。

我仍在改进的部分

这个项目还没有完成。我仍在改进：

• 会话和产物存储
• 模型选择器
• CLI 渲染
• Web 布局
• Git 和 GitHub 工作流
• 特定配置档案的行为
• 长时间运行的监督
• 系统维护技能
• 文档
• 多语言支持
• 各个配置档案的自测项目

但我认为方向是对的。

下一个真正有用的代理界面，不会只是一个更聪明的聊天框。它会是一个能够承载上下文、检查证据、安全运行工具、在模型之间路由，并从中断处继续的工作空间。

这就是我希望 AgInTiFlow 最终成为的样子。

结语

我开始做 AgInTiFlow，是因为我厌倦了把真正的工作硬塞进脆弱的代理会话和吝啬的限制里。

我想要的是本地化的东西。是能从项目文件夹运行起来的东西。是能积极使用廉价模型、在需要时升级、展示产物、恢复会话，并让浏览器和终端共享同一份工作的东西。

它还很年轻，但已经足够有用了，以至于我正在用它来构建它自己。

可以在这里试试：

• GitHub：https://github.com/lazyingart/AgInTiFlow
• npm：https://www.npmjs.com/package/@lazyingart/agintiflow
• AAPS：https://www.npmjs.com/package/@lazyingart/aaps

npm install -g @lazyingart/agintiflow
aginti

这个产品理念很简单：

代理应该流经你的工作，但工作本身应当始终属于你，保留在本地，可检查，也可验证。