最近和朋友聊起 Rust 版 Chat2DB，聊着聊着，话题从“要不要做可视化页面”，变成了另一个问题：
今天设计一款软件，我们应该优先考虑人怎么使用，还是 Agent 怎么使用？
朋友有一个很自然的判断：作为一款软件，总得有个前端展示一下。尤其涉及数据库接入、连接配置和权限管理，没有页面，好像总觉得产品还没做完整。
我能理解这种感觉。过去我们判断一款软件是否完整，往往会看它有没有一套完整的界面：能不能登录、能不能配置、能不能操作、能不能看到结果。
但现在，我越来越倾向于重新排列这个顺序。
先把服务能力做好，让 Agent 用得舒服。面向人的界面，可以先提供一个轻量的壳，再围绕真实需求慢慢补充。
我们需要的，究竟是什么？
这次讨论有一个很具体的背景。
我们的运营团队和增长实习生，经常需要查询数据、开展分析。如果直接给他们数据库账号，即使账号被配置为只读，账号分发、权限变更、访问范围和使用记录，也仍然需要管理。
而他们真正想做的，通常也不是“使用数据库客户端”。
他们想知道的是：最近的注册转化为什么下降了？某个渠道带来的用户留存怎么样？一次活动到底有没有效果？
过去，为了回答这些问题，人需要打开工具、找到表、理解字段、编写查询，再把结果整理成结论。
现在，这个过程有机会由 Agent 协助完成。人的主要工作逐渐变成表达问题、补充背景，以及判断结果是否可信。
在这种工作方式下，Chat2DB 最有价值的部分，就未必是 SQL 编辑器、结果表格和数据库管理页面了。
它可以成为数据库与 Agent 之间的一层服务：负责连接数据库、提供结构信息、执行查询，并在整个过程中落实身份、权限和审计。
产品的中心，也就从“给人一个操作数据库的地方”，转向了“让数据能够被安全、可靠地使用”。
Chat2DB 可以成为人、Agent 与数据库之间稳定的服务层。
Agent 优先，不只是加一个 MCP 接口
如果只是给现有软件套上一层 MCP 接口，我觉得还谈不上 Agent 优先。
真正的变化，是把原来藏在页面和操作流程里的能力，整理成可以独立调用的服务。
比如，Agent 需要知道有哪些表、字段是什么意思、数据之间有什么关系。只有表名和列名，往往不足以支持业务分析，还需要指标口径、使用说明和必要的业务背景。
Agent 发起查询时，服务需要明确知道：它在代表谁操作，这个人属于哪个团队，可以访问哪些数据，这次请求是否在授权范围内。
执行成功后，服务要返回清楚的结果；执行失败后，也要说明是权限不足、请求不支持，还是数据库暂时不可用。
这些事情，原来可能依赖人阅读页面提示、理解报错，再自己调整操作。Agent 要稳定地使用软件，就需要软件把这些信息表达得更明确。
所以，Agent 优先首先是一种服务设计方式。MCP 可以是入口，但产品的核心仍然是入口后面的能力是否完整、边界是否清楚、行为是否可预期。
权限不能建立在“Agent 会听话”上
讨论中，我们聊到了一个问题：
如果底层连接使用的是高权限数据库账号，只在应用层配置“只能执行 SELECT”，是否就能保证不会产生修改数据的行为？
比如，一条看起来用于查询的语句，调用了一个具有副作用的函数，又该怎么处理？
我觉得这个问题的价值，在于提醒我们：权限配置、执行前检查和最终的安全保证，是不同层次的事情。不能因为加了代码检查，就直接把结论说成“百分之百安全”。
LLM 可以帮助理解业务问题、组织请求，但它不应该决定自己有没有权限，也不应该成为权限控制的最后一道防线。
对于这样的产品，真正需要投入的，恰恰是那些不太容易展示在截图里的能力：
谁在访问数据，Agent 代表的是谁；权限如何分配，何时生效；员工离职或岗位调整后，授权如何收回；出现问题时，能否还原当时访问了什么、执行了什么。
这些能力决定了企业敢不敢把真实的数据访问交给它。
漂亮的查询页面能帮助演示产品，可靠的治理体系才能支撑日常使用。
权限在执行边界落实，访问记录覆盖允许与拒绝的请求。
前端可以有，但不必承载整个产品
我并不觉得以后软件就不需要页面了。
管理员需要配置连接、管理授权和查看审计记录。业务人员需要确认分析结果，有时也需要查看图表，或者对一个敏感操作作出确认。
这些都是明确的人类交互需求，值得做好。
但它们不一定需要长成一个功能庞大的数据库桌面客户端，更不一定要在服务能力成熟之前就全部完成。
我更偏向讨论里提到的、类似 Dsh 的思路：我们保证底层服务完整、稳定，提供一个能用的前端壳子，上层界面允许用户按自己的场景组织。
同一套服务，运营团队可以接在日常使用的 Agent 里，数据团队可以接进自己的工作台，管理员可以通过一个简单的网页完成配置。
部署方式也可以因此更灵活。产品可以先是一个服务进程，配套一个轻量的 Web 管理入口。是否需要桌面端、是否需要云端页面，再由实际的部署和使用场景决定。
这里有一个前提：所谓“壳子”，不能意味着把未完成的产品交给用户。
默认界面仍然应该让用户完成基本的接入、配置和排错。开放定制，是为了容纳不同需求，而不是要求每个用户都先开发一套前端。
界面可以按场景组合，底层能力与权限规则保持一致。
当界面越来越容易生成，产品应该沉淀什么？
过去，标准软件通常会把所有人带进同一套界面，再不断增加功能，满足不同角色的需要。
最后，产品很容易变成一个庞大的操作系统：导航越来越长，设置越来越多，每个团队却只使用其中一小部分。
如果 Agent 能调用稳定的服务能力，而界面也更容易按需求生成，那么我们就有机会换一种组织方式。
把身份、权限、业务规则和执行能力沉淀在服务层；把人与软件交互的方式，留给具体场景。
当然，界面可以灵活变化，授权边界不能跟着变化。无论请求来自官方页面、用户自建工作台，还是某个 Agent，都应该受到同一套服务规则约束。
这也是我认为这条路线有价值的地方：用户可以更换入口，产品仍然提供一致、可靠的能力。
软件的价值，不必全部体现在它自己的页面里。
Rust 重写的机会，是重新决定产品的重心
回到 Chat2DB。
如果 Rust 版只是把 Java 版的接口、功能和页面重新实现一次，它当然可能带来工程上的收益，但这些收益本身，还不足以构成新的产品方向。
更值得借这次重写想清楚的是：未来谁会高频调用 Chat2DB？它替用户承担的核心责任是什么？
如果答案越来越接近 Agent，以及 Agent 背后的运营、增长和数据分析团队，那么研发优先级就应该发生变化。
先让服务可独立部署、可稳定调用；让 Agent 获得足够的数据库语义；把身份、权限和审计贯穿整个访问过程；再提供完成基本管理任务的页面。
至于复杂的编辑器、丰富的可视化，以及完整的桌面端体验，可以随着真实需求逐步投入。
我倾向于把这种选择概括为：服务 Agent 优先，人保留理解、配置和控制系统的入口。
我们仍然是在为人设计软件。只是当人开始把更多操作交给 Agent，软件就没有必要要求每一步都回到自己的页面上完成。
对 Chat2DB 来说，我更期待它成为一个可以放心接入的数据库服务：底层能力完整稳定，上层既能接 Agent，也能接不同的界面。
页面可以是一个壳。真正需要做厚的，是这个壳背后的能力和信任。