Agent通过SSH接入的BBS为何再度登场
本文探讨了人类用Web、Agent用SSH与MCP访问同一功能的BBS案例，分析了复用既有工具的设计对落地成本的启示。
商业人类与Agent如何共用同一个论坛
最近读到的一篇BBS服务介绍里，出现了用一行SSH命令接入的场景。SSH是一种通过加密连接访问远程计算机的方式。用户不再是在Web浏览器中点击登录按钮，而是在终端中接入并使用文字菜单。
BBS是过去人们留言和互传文件的电子公告牌系统。如今涌现出一些项目，试图将这种古老的形式改造成不仅人类、AI Agent也能参与的空间。
我关注的并不是那种复古界面，而是用一行SSH命令进入的接入方式。既可以让Agent去解析方便人类使用的界面，也可以让Agent直接调用所需的功能。站在产品运营者的立场上，有必要对这两种方式的搭建成本与运营负担进行权衡。
同时提供Web界面与SSH·MCP
GitHub上开源的ruvnet/AgentBBS就是一个具体例子。根据项目说明，其设计让人类通过Web应用、Agent通过SSH或MCP来使用同一个论坛、市场以及游戏与评价空间。
MCP是规定AI应用程序连接外部工具和数据方式的规范。如果将阅读或发帖功能作为MCP工具提供，Agent就无需在Web界面上寻找按钮位置，可以直接调用该功能。
该项目中值得关注的架构是共享的数据相同，接入的方式多元。人类在Web端阅读的帖子，Agent也可以通过其他接入方式阅读。既不需要强求人类使用终端，也不需要只给Agent提供Web界面。
协作空间与接入规范也需要区分看待。MCP本身并不是论坛，但可以通过MCP来提供多用户共享的论坛功能。AgentBBS正是以这种方式将二者结合起来。如果将它们简单割裂为“MCP只供单个Agent使用，BBS供多人使用”，就会误解其架构本质。
仅凭开源项目的设计，并不能断定一项服务能否成功。但作为一个思考如何将现有功能分别提供给人类和Agent的案例，它非常引人深思。
解析界面在每一步骤都有成本
操作计算机的Agent可以通过观察屏幕、定位按钮并执行点击或输入。其优势在于能够操控没有单独API的程序。在难以更换既有软件的环境中，这是一项重要的备选方案。
但这一过程伴随着成本。必须截取屏幕、由模型解析状态、执行动作并确认结果。如果未出现预期的界面，就必须重新读取或尝试其他路径。随着任务流程拉长，这些步骤会不断累积。
人类解析屏幕同样需要花费时间和认知负荷。在Agent一侧，这种负荷还会体现为模型调用成本与执行延迟。如果只看图像处理成本，可能会漏算整体花销。误操作后恢复耗费的时间、人类介入的次数，都需要一并纳入考量。
相反，如果API或命令行工具能以预定格式返回所需信息，就可以省去寻找按钮的过程。例如在查询订单状态时，可以直接获取订单编号和状态，而无需逐页浏览界面。
不过，并非所有呈现为文字的都是相同的交互界面。有些终端菜单需要跟踪光标位置和屏幕刷新，而有些工具则能像JSON一样以规范结构返回请求结果。比起简单地归类为“用文本替代图像”，更应考察Agent解析状态和结果的难易程度。
基准测试无法直接断定接入方式的优劣
使用界面的Agent的进展，可以在OSWorld等评测中得到印证。但绝不能将不同版本和不同任务当作同一场考试来横向对比。
OSWorld 2.0评估108项长周期任务。其中包含多项人类耗时超过一小时的任务，且需要连续处理分散在多个程序中的信息。它会分别展示完成任务的比例以及任务内部达成要求的得分率。
例如在公开榜单中，Claude Opus 4.8在500步上限及绑定工具调用的配置下，记录了20.6%的完成率和54.8%的得分率。这意味着虽然满足了部分要求，但许多任务并未坚持到最终完成。不能仅凭这一条件下的结果，就笼统概括为实际业务成功率只有五分之一。
评估终端环境的Terminal-Bench 2.0同样需要谨慎看待。在2026年的公开排行榜上，出现了超过80%的成绩，因此无法预先为终端方式划定某个上限。
同样使用Claude Opus 4.6，搭配Claude Code报告的结果为58.0%，而搭配Meta-Harness则为76.4%。这个例子表明，Agent使用工具和延续任务的运行配置会对结果产生直接影响。两个结果的差距很难单凭模型性能或输入格式来解释。
OSWorld与Terminal-Bench的任务与运行环境截然不同，无法将两项得分摆在一起断言界面与终端孰优孰劣。归根结底，必须在产品的实际业务场景下分别执行这两种方式，以相同的完成标准和成本进行对比。
开放既有功能同样需要开发与运营
在这一案例中，我关注的成本是从零构建接入功能的成本。如果已经拥有API或命令行工具，将其连接到Agent可能比重新实现界面操作更加简单。开发者也可以复用自己熟悉的规范和工具。
然而，沿用既有规范并不意味着产品侧的工作就此消失。依然需要核验访问者身份、划分读写权限，并在请求错误时返回异常。还需要处理请求重发时的幂等性，防止重复扣费或重复发货。
如果服务使用SSH密钥，就会涉及密钥的生成、保管与轮换流程。如果是MCP，则必须定义所用工具的输入与输出，并配置访问权限。还需要确认用户环境中是否已安装必要的客户端。如果假定所有人都在安装和使用，就会对落地周期产生误判。
因此，与其相信“几周就能打通”的泛化周期，我认为不如先确认当前产品中已具备什么。拥有规范API的产品，与所有处理逻辑都纠缠在界面里的产品，所需的工程量截然不同。
| 比较项目 | 使用界面操作时 | 提供API·命令行·MCP功能时 |
|---|---|---|
| 准入条件 | Agent必须能访问所需界面和功能 | 产品必须定义可调用的功能与返回的结果 |
| 执行过程 | 需要解析界面并确认操作结果 | 需要确认请求·响应与状态变更 |
| 变更应对 | 受到界面布局和流程变更的影响 | 需要管理输入·输出规范及版本变更 |
| 权限管理 | 控制界面上允许的操作与数据范围 | 控制可调用的功能与数据范围 |
| 成本评估 | 衡量调用量、延迟、重试与人类介入 | 综合衡量构建·维护与执行·恢复成本 |
有些可视化成果只能通过界面确认，而像数据查询这类功能则更适合直接调用。在同一款产品中并用这两种方式，或许才是合理的做法。
Oswarld视角
在创建Notion韩国社区的那段日子里，我学到了一个道理：比起把功能做得多么出色，能否让人们在已有的工具中使用这项功能往往更为关键。同一项功能，如果嵌入到熟悉的工具中就会有人用；若要让人重新打开一个单独的程序，往往就会无人问津。
在制定GTM战略时，我反复目睹了这种模式。与其耗费力气宣传新界面，不如让客户在现有的工作场景中直接使用功能，这更有利于产品落地。我认为，撇开功能本身的质量不谈，这主要是因为用户需要付出新的学习成本，以及改变工作习惯的心理负担。
在Agent接入方面也可以提出类似的问题：当前使用的Agent已经能够操控哪些工具？能否以这种方式提供产品的既有功能？虽然不必执着于老旧的规范，但在打造全新连接方式之前，有必要先清点可复用的资产。
在咨询现场谈及这些时，有时会听到反驳：我们的产品核心在于视觉体验。这话也没错。像查看和评审设计成果这类工作，界面确实至关重要。但在同一款产品中，检索、状态查询、导出等功能完全可以在没有界面的情况下处理。这些功能是可以单独拆分出来的。
我不认为BBS本身的复兴就是所有产品的答案。我关注的是复用熟悉的接入方式、让人类与Agent访问同一数据的设计思路。仅凭两三个小项目的涌现，无法断言整个市场都选择了这一方向，但它们确实展示了值得权衡的备选方案。
如果你正在打造产品，不妨从一个高频功能开始对比。记录下通过界面操作与直接调用来完成同一次查询或导出时的完成率、耗时、重试次数和人类介入成本。再加上接口开发与维护成本，就能更容易判断哪种方式适合自家产品。
我认为，决定以何种路径提供既有功能，本身就是GTM的一部分。 因为这直接关系到能否缩短客户与Agent真正上手前的距离。
💬 您的产品中，有哪些功能无需界面也能处理？如果率先向Agent开放，您会挑选哪一项？
参考资料与延伸阅读
- ruvnet/AgentBBS：通过Web·SSH·MCP访问同一空间的项目架构
- MCP官方架构说明：应用程序与服务器、工具·数据连接架构
- Snorkel AI, OSWorld 2.0：长周期任务的完成率·得分率与运行条件
- Terminal-Bench 2.0：各模型与Agent配置评测结果
