人工智能实验

我邀请我的人工智能代理进入 Romergo，但我不知道这是什么，也不知道该怎么称呼它。

应用程序中的大多数人工智能集成都是以可预测的方式设计的。该产品添加了一个 Spark 按钮，向自己的模型发送请求，并在侧边栏中显示响应。

还有另一种常见的选择。应用程序提供 MCP 服务器，用户打开 ChatGPT、Claude 或其他代理并要求其处理应用程序数据。这为代理提供了很好的工具，但对话发生在其他地方。您需要离开编辑器，解释当前打开的内容，切换回来并检查结果。

我厌倦了在聊天和编辑器之间切换，我突然想到一个想法：如果我可以完全避免这种情况怎么办？

我直接将 AI 面板添加到编辑器中，但没有将其连接到 Romergo 托管的模型。相反，用户邀请他们的个人 AI 代理加入开放会话。

代理保留在它已经存在的地方：ChatGPT、Claude、Codex 或其他 MCP 兼容客户端。它保留其模型、订阅、内存、设置和可用工具。 Romergo 仅提供工作区、当前上下文和用于编辑项目的专用工具。

连接后，用户可以直接从Builder写入代理：

• 描述开放的场景；
• 改变本章的音乐；
• 重写突出显示的对话；
• 放置不同的背景；
• 检查转换逻辑；
• 解释为什么场景没有按照我的预期进行。

答案、问题和中间状态将返回到同一面板。该面板不仅显示文本，还显示整个任务周期：已收到命令、分配给代理、正在执行工具、需要确认、作业已完成或发生错误。您不再需要离开编辑器。

它开始于一个实验

我无意发明一个新的协议或提出一个新的产品类别。我想测试一个简单的想法：个人用户代理不仅可以通过 MCP 从外部控制 Romergo，还可以临时加入编辑器内的实时会话？

第一个版本是一个实验。令我惊讶的是，它的效果非常好，我自己也开始使用它。

最短的图可以画成这样：

Personal AI agent  <->  MCP  <->  Romergo Builder

但两个方向的标志都很重要。

典型的 MCP 调用从代理开始：代理决定联系应用程序并调用其工具。在我的实验中，罗默戈也可以启动工作。用户在 Builder 中编写命令，Romergo 将其放置在安全通道中，已连接的代理通过 MCP 接收命令。

然后，代理使用常用的 Romergo 工具读取或修改项目，并通过相同的通道将结果返回给 Builder。

这创建了一个闭环：

1. User -> Builder panel: "Replace the music in this chapter"
2. Builder -> authenticated channel: command + current page + selection
3. Personal agent -> MCP: wait for the next Builder command
4. Agent -> Romergo MCP tools: inspect and edit the project
5. Agent -> MCP channel: status, question, result, or error
6. Builder panel -> User: live response from the personal agent

Romergo 不会在任何这些步骤中运行模型。

同时，我没有改变MCP本身，也没有给它添加真正的服务器推送。从协议的角度来看，所有的调用仍然是由代理发起的。反向方向实现为安全邮箱：Builder 将命令写入通道，代理通过通常的长轮询 MCP 工具等待它。然后，代理使用相同的常用工具调用将事件发回。

双向行为出现在应用程序会话级别，而不是通过新的 MCP 传输。这种区别很重要：当前的实现最好理解为构建在标准 MCP 调用之上的小型会话合约。

座席如何进入会话

生成器创建临时通道代码。用户将简短的启动提示复制到他们的 AI 聊天中，如下所示：

加入我的 Romergo Builder 频道。运行每个新命令一次，将结果或问题发送回 Builder，然后继续等待，直到我明确要求您停止。

然后，代理调用 MCP 工具 romergo_join_builder_channel 并传递代码。这是一次握手：Romergo 检查 OAuth 会话、通道的所有者及其到期日期，然后返回对话状态和最后一个命令光标。

接下来，代理调用 romergo_wait_for_builder_command。这是一个长时间轮询，等待编辑器的下一个命令。如果没有任何消息到达，代理将保存光标并再次开始等待。如果该命令存在，则它包含：

• 说明文字；
• 命令ID；
• 单调序列；
• Builder 中的当前路径；
• 打开的项目、章节和场景的 ID（当它们位于 URL 中时）；
• 编辑器表面类型和上下文捕获时间；
• 用户选择的文本（如果有）。

所有附加的上下文都被标记为不受信任的应用程序内容。这是工作数据，而不是代理控制指令的延续。

该代理使用现有的 Romergo MCP 工具执行任务。例如，它可以读取项目和章节、查找资产、更改场景，然后验证保存的结果。

当它工作时，代理可以调用​​ romergo_report_builder_event 并发送面板：

• status - 短中间状态；
• question - 没有答案的问题，继续下去是不安全的；
• reply — 最终结果；
• error - 错误的清晰描述。

响应绑定到 commandId，并且从最后处理的序列中读取下一个命令。首次发出时，API 会自动将该命令分配给 client_id OAuth 客户端。另一个连接的代理将无法同时执行相同的任务。光标有助于在超时或重新连接后继续，并且特定工具调用的一次性确认受到参数指纹的保护，并且不能重复用于其他操作。

权利属于房间，而不属于提示

连接之前，用户会看到通道设置并选择允许代理执行的操作：读取项目、编辑内容、处理媒体和音频、发布或删除数据。这些设置可以随时通过面板标题中的齿轮打开。

默认情况下，可以读取、编辑和使用媒体，并且用户的直接请求已被视为应用这些操作的权限。发布和删除是单独禁用和启用的。如果需要，用户可以启用更严格的模式并再次确认每个更改，或者仅在发布和删除时要求确认。

这不仅仅是启动提示中的文本。公共服务器包装器在调用修改 MCP 工具之前检查范围。如果启用了附加确认，Builder 会通过“允许一次”和“拒绝”按钮显示确切的操作，而原始调用将继续等待决策。该权限与命令、工具和参数指纹绑定，一旦执行就不再有效。

每个修改工具的启动、完成、错误、阻塞都会自动返回面板。每个最终答案必须包含一个结构化摘要，其中包含状态和结果的具体描述。更改后，代理还会列出更改的实体、执行的检查以及结果链接； Builder 在响应文本的正下方显示此摘要。可以从设置中明确终止该通道；旧代码立即停止工作。

Romergo 中有什么，用户保留什么

我喜欢将这种架构视为关注点分离。

罗默戈提供：

• 编辑器和可视化工作区；
• 当前项目、页面和选择；
• 双向通讯的临时空间；
• 用于读取、修改和检查项目的特定领域工具；
• OAuth、访问权限和会话事件历史记录；
• 用户可以在其中看到问题、进度和结果的界面。

用户代理带来：

• 模型和计算；
• 自己订阅；
• 推理和计划；
• 记忆和个性化（如果由所选代理提供）；
• 其他连接工具；
• 用户熟悉的工作方式。

智能不属于应用程序。该应用程序创建了一个让这种智能可以安全运行的地方。

为什么不做一个常规的内置副驾驶

内置人工智能将更容易解释并且更容易启用。用户按下按钮，应用程序调用所选模型，一切正常。

但随后罗默戈还必须成为人工智能基础设施的运营商：

• 为推理付费或通过计划转嫁成本；
• 为用户选择型号；
• 创建自己的记忆和个性化；
• 重新连接外部服务；
• 存储额外的敏感上下文；
• 不断追赶横向AI产品的能力。

当使用个人代理时，所有这些都已经存在于用户端。 Romergo 并不试图构建另一个 ChatGPT。它为 ChatGPT、Claude 或其他代理提供了专门的工作空间和清晰的工具。

这对于创意编辑来说尤其有趣。同一个代理可以知道用户如何编写对话、他们喜欢什么语气、已经讨论过哪些参考文献以及他们使用哪些外部工具。罗默戈不需要仅仅为了帮助替换一个背景或重新安排一个场景而复制整个系统。

最奇怪的部分：代理人既在外面又在里面

该特工实际上并没有搬到罗默戈。其模型和代理循环继续在原始 AI 客户端中运行。

但从用户的角度来看，代理存在于编辑器内：

• 接收来自内置面板的命令；
• 知道用户在哪个页面；
• 请参阅随附的选择；
• 改变同一个项目；
• 提出问题并向同一小组返回答案；
• 切换页面或重新连接后可以继续通话。

因此，“应用程序内部的人工智能”和“通过 MCP 外部的人工智能”这两个表述在这里并不完全准确。它实际上是外部代理在应用程序会话中的临时存在。

我不是第一个朝这个方向前进的人

实验成功后，我开始寻找类似的方法。

代理客户端协议 允许 Zed 和 JetBrains 等编辑器连接外部编码代理。 Tidewave 将 Claude Code、Codex 和其他 ACP 代理放置在正在运行的 Web 应用程序旁边，并向它们传递浏览器和运行时上下文。 Obsidian Agent Client 在笔记旁边显示 Claude Code、Codex 和 Gemini，并自动附加活动文档和选择。 marimo 为外部代理提供了一个实时笔记本作为共享工作区。

还有更一般的实验。 AG-UI 标准化了用户界面和代理后端之间的双向通信。 WebMCP 建议网页注册可供连接的浏览器或桌面代理使用的工具。 代理应用协议 描述了一种模型，其中应用程序拥有 UI 和领域工具，外部代理拥有推理、历史和通用工具。

也就是说，基本思想已经以多种形式存在。但大多数实现都集中在 IDE、本地编码代理或公司自己部署的代理上。

罗默戈实验对我来说很有趣，因为有一个稍微不同的问题：如果个人用户代理可以进入常规创意应用程序，会发生什么？

不是新型号。不是模型的 API 密钥。不是内置的副驾驶应用程序。人们每天都在使用的代理。

方便只是问题的一半

一旦外部代理可以侦听应用程序命令并更改项目，安全性就不再是可选功能。

出现的问题无法通过一个 OAuth 屏幕来回答：

• 特定房间可以使用哪些页面和实体；
• 哪些行为无需确认即可允许；
• 项目文本可以包含提示注入吗？
• 代理必须如何区分用户命令和不受信任的数据；
• 超时后命令会发生什么情况；
• 如何向用户展示实际的变化，而不仅仅是自信的文本答案；
• 如何撤销会话并证明代理确实停止监听；
• 个人代理的内存和外部连接的哪一部分可以在特定应用程序中使用。

当前版本按用户和时间限制通道，使用 OAuth、服务器范围、一次性确认、原子命令声明和显式生命周期。这仍然是一个实验，但重要的边界现在是执行的一部分，而不仅仅是代理的指导方针。

该怎么称呼它

我还没有最终的头衔。

自带 AI 通常意味着您自己的 API 密钥或模型选择。自带代理更接近，因为用户不仅带来模型，还带来内存、工具和代理循环。然而，BYOA 并没有描述实验的重要部分：应用程序还可以联系代理并与其保持实时会话。

或许这就是：

• 实时代理频道；
• 应用程序代理会话；
• 代理存在层；
• 个人代理桥；
• 双向MCP；
• 或者只是基于现有想法的成功实验。

我不想仅仅为了名字就提出一个新的标准。首先，对我来说更重要的是了解这样的模型在 Romergo 之外是否有用，以及它需要什么边界才能被信任。

应用程序可能不需要原生人工智能

如今，几乎所有产品都试图内置自己的助手。因此，用户拥有许多独立的 AI：一个在编辑器中，另一个在邮件中，第三个在任务系统中。每一种都有其自身的短记忆、其自身的局限性和其自身的价格。

还有另一种可能的模型。

该应用程序提供了工作空间、实时上下文和专用工具。用户带来了他们已经信任的代理。工作时，代理加入应用程序，帮助完成任务，然后与用户一起离开。

我还不知道这是否会成为一个独立的建筑类别。但现在我知道这样的循环是可以组装起来的，而且它实际上是可以使用的。

但我确实知道尝试很有趣。

返回开发博客