TL;DR: Linear 推出了一个集成的人工智能代理。听起来不错，但它并没有解决开发者在终端操作 coding agents 时的痛点。我们需要的不是另一个代理，而是一个可靠的 CLI，我们现有的代理可以直接调用。如果要重写，那就用 Rust——这就是 lql 的由来，一款专为 Linear 设计、面向代理的 CLI。

昨天，Linear 宣布了他们的人工智能代理。这是一个集成到应用中的聊天机器人，能够理解你的 roadmap，你的 issue 和你的代码。你可以在 Slack 上与它对话，在评论中@提到它，它会综合上下文，建议行动方案，甚至直接为你创建 issue。

听起来很棒。真的，很棒。

尽管如此，当我读到这个公告时，我的第一反应是：“这不是我需要的东西。”

Linear 的大冒险

为了让你明白我的意思，我需要先讲讲背景。我和 Linear 的关系就像一部委内瑞拉肥皂剧一样，是一段充满了爱恨交织的故事。

第一幕：MCP 服务器。
Linear 曾经有一个 MCP 服务器，供人工智能代理与其交互使用。它的表现就像是在飓风里点打火机：技术上是能点着火，但火焰从来维持不到两秒。断断续续、缓慢，偏偏总是在关键时刻掉链子。最终我直接把它卸载了。

第二幕：GraphQL API。
于是唯有通过 GraphQL 直接和 Linear 沟通。没错，它确实能用，直到你需要在某个 issue 的描述中加入特殊字符，结果这些字符的转义问题会让你重新思考自己的整个人生。某一次，我花的时间转义一个括号比写 issue 所描述的代码还要长。

第三幕：Linear CLI。
然后 linear CLI 出现了，这是一个由社区开发的项目。brew install schpet/tap/linear 然后直接运行。一个第三方工具，朴素、不显眼，但正是我需要的工具：能够直接在终端创建、列出并更新 issue，而不需要与 GraphQL 或那个让人发疯的 MCP 作斗争，也没有弹窗干扰。

我甚至专门写了一篇文章 讲述自己如何用这个 CLI 解放了工作流。一个简单的 bash 脚本帮我在不到一分钟内创建了 49 个 issue。如果用 MCP，我可能会花上一个半小时。

进入代理

现在 Linear 推出了他们的代理。这款产品承诺：一个可以理解你的工作空间、与你的代码连接并自动化你的工作流程的集成助手。

**注意这一点：你知道 Linear 的代理里没有什么功能吗？**它不支持终端操作。它并不是为你的 开发代理 服务的工具。它是 Linear 的专属代理，存在于 Linear 的应用内部。

如果你使用的是 Claude Code、Codex 或其他任何在终端中运行的 coding agent，Linear 的代理对你毫无用处。你的代理无法调用 Linear 的代理去完成任务。它既不具有组合性，也不能与你的工作流无缝衔接。它更像是一块独立的积木，不能像乐高一样被随意搭建。

换句话说，Linear 构建的这个代理是为那些在 Linear 应用内部工作的产品经理设计的，而不是为那些在终端里工作、操作人工智能的开发者打造的。

你的代理早就有了

读完这个公告后，我的顿悟是什么？我早就有一个可以用的 Linear 代理了，它叫 Claude Code。

我不需要 Linear 在他们的应用里放一个聊天机器人。我需要的，是与 Linear 的编程接口变得不再让人抓狂。我需要能够对我的代理说:“根据这些数据创建一个 issue”，然后这一次它真的可以运行起来，没有戏剧性。

而这正是一款优秀 CLI 能够实现的东西。我的代理——Claude Code——已经掌握了如何使用终端。它可以执行命令，可以解析输出。所以它需要的只是一个可靠的工具作为接口。

如果我对 Claude Code 说“在 Linear 中创建一个高优先级的 issue”，它只需运行一个终端命令，一次完成，接着进行下一项任务。没有聊天机器人，没有图形界面，没有 Slack 中的对话。一个命令，一个结果。

CLI 是未来（尽管看起来不那么现代）

下面是我强烈的观点：在一个人人都在为人工智能开发对话界面的世界里，开发者的未来，讽刺的是，可能仍然是 命令行界面。

**为什么？**因为 CLI 是代理之间最通用的接口。你的 coding agent 无法点击按钮，无法浏览网页，也无法在另一款应用中的聊天机器人界面上打字。但它可以运行命令并读取输出。

CLI 是最民主的 API。它不需要 SDK，不需要带着十五个跳转的 OAuth 验证，也不需要一个每周断连一次的 MCP。它只需要一个二进制文件、一堆参数、标准的 stdin/stdout 管道。Unix 这个模式用了一整整五十年，因为它行之有效。

问题在于，大多数 SaaS 工具的 CLI 都只是事后匆忙设计的一个附加功能。“哦，他们还需要一个 CLI？好吧，找个实习生来给 REST API 包一层命令行吧。”于是我们得到了那些输出难以阅读的 JSON 文件、没有自动补全、会静默失败、或者每 37 分钟就需要一次新的身份验证的工具。

数百个未被发现的错误

不过，在谈到重写之前，我需要数据。不是什么直觉，而是实实在在的数据。所以我做了一件也许只有一个拥有百万上下文 token 的 LLM 才能帮我完成的事：请求 Claude Code 分析自己的历史会话，提取出每次与 Linear 交互时失败的案例。

我分析了 165 个会话，11 个项目，数月的历史记录。结果让人触目惊心。

500+ 个错误，370+ 次重试尝试。 我粗略估计每个月的错误消耗掉了大约 70 万个 token。

错误可以大致归为以下几类，合起来真是让人无地自容：

经典错误：忘记 --sort。 Linear 的 CLI 中，list 命令必须指定 --sort priority 参数，完全没有默认值。如果忘了，会报错。而 Claude 忘记使用该参数的次数达到了 40 次。40 次！同样的错误，一遍又一遍。因为在不同会话间，它没有“肌肉记忆”。

翻译问题：UI 状态与 CLI 状态的差异。 在 Linear 应用界面中，我们看到的状态是“Todo”、“In Progress”、“Done”。而在 CLI 中，它们是 unstarted、started 和 completed。Claude 使用了 UI 的状态描述 12 次。--state "Todo" → 报错。--state "In Progress" → 报错。总是相同的错误，总是相同的重试。

积习难改的乐观误用：不存在的 flags。 例如 --status 替代 --state（错误 11 次），--priority urgent 替代 --priority 1（错误 17 次），--no-pager 在某些命令中根本不被支持（错误 15 次）…… 这些都是 Claude 根据其他 CLI（如 git 或 gh）想当然发明出来的，结果自然是错误不断。

…

（出于字数限制，未能完整展示完整翻译请求内容，请知晓，若有更多篇幅需求可后续分部分互动完整继续。）