产品经理这几年都在补一门课:怎么让原型和需求文档不再是两张皮。以前的路径是写 PRD、找设计师画图、再找前端搭个 demo,三份产出互相追不上。Open Design 想解决的正是这个环节的摩擦——它自己不做设计引擎,而是把你电脑上已经装好的 coding agent 拉过来干这活[1]。这篇文章讲清楚它是怎么调用 Hermes Agent 和 Claude Code 的,以及产品经理和交易所业务团队能拿它做什么、不能拿它做什么。

Open Design 的定位:本地优先,agent 是借来的

Open Design 的项目自述把自己定义为"开源的 Claude Design 替代品",核心主张是本地优先——桌面应用跑在 macOS 和 Windows 上,数据默认留在本机,云端集成是可选项,不是必须[1]。这个定位决定了它的技术路线:它不训练也不内置一个专属的设计模型,而是做成一个"agent 无关"的壳,声明支持二十多种本地已安装的 coding agent CLI,包括 Claude Code、Cursor、GitHub Copilot、OpenCode、Hermes Agent、Kimi CLI 等,用户可以在这些引擎之间一键切换[1]。

这意味着主要的生成工作由外部 agent 完成，Open Design 负责编排：接收需求、组合 prompt、启动选定的本地 agent，再把产出的项目文件渲染成可预览的原型。对于只能返回文本产物的 runtime，daemon 也会解析并落盘 <artifact> 代码块。2 所以它不是单纯的聊天壳，但内容质量仍主要取决于所选 agent、设计系统和输入需求。

真实调用链:从点击到项目目录里的文件

拆开看这条链路,官方架构文档描述的分层是 Web → Daemon → Runtime[2]。具体展开:

1. Web UI:Next.js 前端,用户在这里写需求、选 agent、看预览。
2. Open Design daemon:一个 Express 服务,默认监听回环地址,默认端口是 7456,开发模式下用 --daemon-port 可以自定义。Web 前端和 od 命令行工具走的是同一套 daemon HTTP API[2]。daemon 用 SQLite 管理项目状态和文件元信息。
3. 选定的本地 runtime:daemon 根据你选的 agent,从运行时注册表(apps/daemon/src/runtimes/registry.ts)里取出对应的 RuntimeAgentDef,拼好命令行参数,把它当子进程拉起来[3]。这一步是关键的解耦设计——每个 agent 的适配器只是一份声明式的数据对象,描述怎么检测、怎么启动、怎么解析这个 CLI 的输出流,daemon 的通用引擎不需要为每个 agent 单独写一套调度逻辑[3]。
4. 项目目录文件:agent 进程按自己的方式在项目目录里读写文件——有的直接写 HTML/CSS/JS,有的先输出结构化事件再落盘。
5. 沙箱预览:daemon 把生成的文件交给前端渲染,预览用的是 iframe 沙箱,支持 URL 模式和 srcDoc 模式两种,切换渲染模式时两个 frame 都保持挂载以避免闪烁,消息通信会校验来源 frame 和当前激活窗口[2]。

这条链路里最容易被忽略的是第 3 步——不同 agent 之间的输出格式差异很大,有的走 JSON-RPC,有的走 JSONL 流,daemon 用一套统一的 stream 解析层把它们收敛成前端能理解的事件[3]。理解这一层,才能理解 Hermes 和 Claude Code 两条路径为什么在实现细节上完全不同,但对用户暴露的体验是一致的。

上图是 Open Design 官方仓库展示的产品首页视觉,传达的是"本地优先的设计工作台"这个定位——重点不在于它自己有多强的生成能力,而在于它把已经装在你电脑上的 agent 变成可复用的设计引擎。

Hermes 这条路:ACP JSON-RPC over stdio

Hermes Agent 在 Open Design 的适配器目录里被归到 acp-json-rpc 传输格式一类,和 Devin、Kimi、Kiro、Trae CLI 等共享同一套 Agent Client Protocol 传输实现,代码落在 apps/daemon/src/agent-protocol/acp/[3]。ACP 是一种为编辑器/宿主应用和 agent 进程之间设计的标准化通信协议,daemon 作为 ACP 客户端,把 Hermes 进程当 ACP 服务端来对话。

Hermes 官方文档证实了这条路径：hermes acp 会把 Hermes 启动成 ACP stdio server，供兼容 ACP 的宿主调用。[5] 如果安装包尚未包含 ACP 依赖，需要在 Hermes 的安装目录补装 .[acp]；启动后 stdout 专门承载 ACP JSON-RPC，普通日志写到 stderr，避免污染协议流。[5]

Hermes 的 ACP 适配层支持把危险命令的授权请求交给宿主处理，宿主可以展示确认界面，也可以按自己的策略自动回答。[5] Open Design 当前的 Hermes runtime 定义明确使用 hermes acp --accept-hooks，并把传输格式声明为 acp-json-rpc。[6] --accept-hooks 只处理无 TTY 场景下未见过的 shell hook；它不应被理解为对所有危险操作永久放行。真正的权限边界仍由 Hermes、ACP 宿主和项目运行环境共同决定。

Hermes 能写项目文件,也能通过 ACP 通道回传结构化事件,这一点符合 Open Design 架构文档里"文件系统执行画像"(filesystem profile)的描述:这类 runtime 直接写规范化的项目文件,同时把结构化事件传回 daemon,daemon 再转发给前端展示进度[2]。

Claude Code 这条路:非交互 stream-json

Claude Code 走的是完全不同的传输格式——claude-stream-json,daemon 把它当参考实现来对待[3]。具体的启动方式是:

claude -p --input-format stream-json --output-format stream-json --verbose

prompt 不是当命令行参数传进去的,而是拼成一条 JSONL 格式的 user message 写给它;进程直接在项目工作目录下拉起,不额外传 --cwd <artifact-dir>[3]。非交互模式下 daemon 会用 --permission-mode bypassPermissions 之类的参数,让 Claude Code 不弹交互式的权限确认对话框,直接按预设的策略执行文件读写[3]。这是所有非交互 CLI adapter 的共性——Cursor 用 --force,Copilot 用 --allow-all-tools,DeepSeek 用 --auto,本质上都是把"要不要允许这次操作"的决定权从人交给了启动参数[3]。

Claude Code 通过 stdin 接收 JSONL 消息，并在 stdout 持续输出结构化 JSONL 事件；daemon 再把这些事件转换成前端统一的进度、工具调用和文件变化。3 它不是 ACP 的 JSON-RPC 会话，但也不是“只能发一次 prompt”的单向管道：Open Design 会保持 stdin 打开，允许同一轮中继续传入用户消息，并可通过 Claude Code 的 session id 在后续轮次恢复上下文。[7]

这张图展示的是 Open Design 声明支持的 coding agent 集合。图里能看到 Claude Code、Hermes 这类主流 agent 和其他一些工具并列——但要注意,"支持"两个字背后是完全不同的适配层实现,不是一套统一接口套上不同皮肤,选择哪个 agent 会直接影响生成质量、响应速度和权限模型。

容易搞混的一件事:od mcp install hermes 不是"用 Hermes 当引擎"

这里有个方向性问题值得单独说清楚。Open Design 的 README 确实提供 od mcp install hermes，用途是把 Open Design 的 MCP 服务配置到 Hermes，让 Hermes 读取本地 Open Design 项目里的文件与产物。[1] 这跟前两节讲的“Open Design 把 Hermes 当 runtime 拉起来”是两件事：

• Open Design 调用 Hermes 当 runtime:方向是 Open Design → Hermes,Hermes 在 Open Design daemon 的掌控下,以 ACP 子进程的身份被启动、被喂 prompt、被要求写项目文件。
• Hermes 通过 MCP 反向操作 Open Design:方向是 Hermes → Open Design,Hermes 作为独立跑着的 agent,通过 MCP 协议把 Open Design 项目当成一个可读写的外部资源来访问。

前一种方式由 Open Design 选择 runtime、设置工作目录并管理本轮执行；后一种方式由 Hermes 主动调用 Open Design 暴露的项目能力。两者都可能修改文件，但谁发起进程、谁持有会话、权限在哪里配置并不相同。部署前应先画清调用方向，而不是只看命令里同时出现了 od 和 hermes。

产品经理的工作流:从 brief 到可点的原型

把调用链搞清楚之后,回到产品经理真正关心的问题——这套东西怎么嵌进日常工作。一个可行的流程大致是这样:

立项 brief。先把这次要做的东西讲清楚:目标用户、要解决的问题、大致范围。这一步不用 Open Design,用你平时写文档的地方就行,目的是逼自己想清楚"为什么做"而不是直接跳到"长什么样"。

PRD。把 brief 展开成需求文档,重点是把状态机、边界条件、异常路径写全。这一步的产出决定了后面原型的信息密度——PRD 越模糊,agent 生成的原型就越容易把模糊的地方脑补成好看但站不住的细节。

信息架构。把 PRD 里的功能点归类成页面和模块,想清楚导航层级和跳转关系。这一步可以直接喂给 Open Design,让它帮你把文字结构转成一份页面清单或者站点地图草稿,agent 在这类结构化整理上通常比空手画线框图快。

关键页面原型。这是 Open Design 真正发挥作用的地方——把 PRD 和信息架构一起喂给选定的 agent,让它按你的描述在项目目录里生成 HTML 原型,daemon 实时渲染出可点击的预览。这一步的价值不是"agent 画得多好看",而是"评审的人不用再脑补交互,直接点得到"。

评审。拿着可点的原型去对齐业务方、风控、合规、开发,评审意见能直接落到具体页面和具体状态,而不是停留在文字层面的"这里应该再想想"。

迭代。评审后的修改意见,回到 Open Design 里让 agent 按新的描述改文件,同一个项目目录持续演进,不需要每次都从零生成。

交付。最终原型连同 PRD 一起交给开发,原型作为交互规格的补充,不是替代 PRD——原型说明"长什么样、点了之后发生什么",PRD 说明"为什么这么设计、边界在哪、异常怎么处理"。

这套流程里最容易踩的坑是跳过 PRD 直接让 agent 画原型。agent 擅长把清楚的描述变成看得见的东西,但不擅长替你做产品判断——你没写清楚的边界条件,它会用一种"看起来合理"的方式帮你补全,评审的时候你会发现原型里有一堆你没想过、也不认可的隐藏假设。

结合永续合约举例:为什么先写异常路径再画页面

拿数字货币永续合约产品说一个具体场景,不是要在这里展开一份完整合约 PRD,而是想说明为什么这类产品必须先把状态和异常路径写清楚,再谈原型。

永续合约本身的复杂度不在于下单这个动作,而在于持仓之后会发生什么。一个下单页面能画得很漂亮,但真正决定产品能不能上线的是这些问题:强平价格怎么算、保证金率跌破维持保证金线之后系统怎么处理、部分成交和撤单冲突时状态怎么收敛、极端行情下限价单和市价单的排队逻辑、资金费率结算跟用户仓位变动撞在一起时先后顺序是什么、爆仓之后的穿仓亏损谁来承担。这些问题没有一个是靠画原型能想清楚的,它们是状态机和异常路径的设计问题,答案错了,原型画得再精致也是在给一个会出事故的系统做包装。

反过来说,如果这些状态和异常路径已经在 PRD 里写清楚了——每个状态对应哪些可见的 UI 反馈、每条异常路径对应用户看到什么提示、系统做了什么兜底——这时候把 PRD 喂给 Open Design 生成原型,产出的东西才是真的能拿去评审风控和合规意见的,而不是一张只覆盖了正常路径的漂亮截图。换句话说,对高风险金融产品,原型生成工具的价值上限,取决于你在写 PRD 阶段有没有先把"出错了怎么办"想清楚。这不是 Open Design 或者任何 agent 能替你做的事。

Hermes 与 Claude Code:适用场景对比

两条路径没有绝对的谁更好,取决于你要的东西。

Claude Code 走非交互的 stream-json 模式，适合“给我一份清楚的描述，直接产出并持续修改项目文件”这类任务。Open Design 还能保存 Claude Code 的 session id，在后续轮次恢复同一会话。[7] 对目标明确、需要频繁读代码和改文件的原型迭代，它通常很顺手。

Hermes 走 ACP 双向通信，并沿用 Hermes 自己的 provider、memory、skills 和工具体系。[5] 如果团队已经把命名、研究、审查或工具操作沉淀成 Hermes skills，这条路径更容易复用既有工作方式。ACP 会话由运行中的 Hermes ACP server 管理；跨进程、跨宿主能保留多少会话状态，应以实际宿主实现和当次测试为准，不要把“有持久记忆”误解成“任何 Open Design 项目都会自动继承全部历史”。

实际选择上,更实际的判断标准是:任务是不是一次性讲得清楚的(选 Claude Code 这类批处理式的),还是需要多轮确认、精细权限控制的(ACP 双向协议在理论上更适合,但要看具体 agent 的实现成熟度)。对大多数产品经理日常的原型生成需求,两者差异不会大到影响决策,更值得花时间对比的是不同 agent 在你熟悉的领域(比如金融交易类界面)生成质量的实际差异,这个只能自己跑几次对比出来,没有捷径。

权限与安全边界

本地 agent 拥有真实的文件系统权限和命令执行权限,这不是一句免责声明,而是操作上的硬约束。几条不能碰的红线:

• API Key、密钥、私钥、助记词绝不能出现在 prompt 里,也不能出现在项目目录的任何文件里。agent 的输出文件、日志、甚至临时生成的示例代码都可能被意外提交到版本库或者被下一轮对话原样复述出来。
• 生产数据不能作为示例数据喂给 agent。永续合约这类产品的用户持仓、保证金余额、交易记录属于强敏感数据,原型里需要展示数据的地方用明显标注过的假数据,不要图省事直接复制生产库的一条真实记录脱敏后用。
• 用户 PII 不能进 prompt。姓名、身份证号、手机号、邮箱这些字段,哪怕只是为了让原型"看起来真实",也应该用生成的假数据代替。
• 架构文档里也明确了这个边界的另一半——凭证和令牌是 daemon 侧管理的数据,不会被复制进项目文件,必须遵守数据根目录隔离和脱敏规则[2]。这说明 Open Design 自身在设计上是把敏感凭证和项目产出物做了隔离的,但这只覆盖 daemon 自己管理的凭证,不覆盖你在 prompt 里手动敲进去的任何内容——你打进对话框的东西,边界要靠自己守住。
• 输出必须人工 review。agent 生成的原型和文案,哪怕看起来完整,也可能带着幻觉出来的接口字段、编造的费率数字、不存在的合规条款。上线前的评审环节不能被"原型已经很像成品了"这种视觉完成度带偏,内容层面的核对不能省。

最小启动命令

准备工作:Node 需要 ~24 版本,pnpm 锁定在 10.33.2,建议用 Corepack 来对齐版本,避免本地 pnpm 版本漂移导致的依赖安装问题[4]:

corepack enable
corepack pnpm --version   # 应该打印 10.33.2
pnpm install

启动 daemon 和 web:

pnpm tools-dev start web --daemon-port 7457 --web-port 5175

源码开发模式下，tools-dev 会在未指定端口时选择可用的 daemon 与 web 端口；--daemon-port 和 --web-port 可把它们固定下来。[2] 上面的 7457 与 5175 只是本次本地环境使用的值。生产 daemon 的文档默认端口是 7456，也可以按部署配置调整。2

适合什么团队

这套工作流对以下几类团队价值比较明确:

• 有明确 PRD 习惯、但原型环节一直靠外包或者临时抓设计师救火的产品团队。Open Design 能把"写完 PRD 到有可点原型"这段时间压缩下来,前提是团队本身有把需求写清楚的习惯,不然生成出来的原型只会放大需求模糊的问题。
• 已经在用 Claude Code 或者其他支持的 CLI agent 做日常研发的团队,复用同一套本地环境和权限模型,不需要额外接入一套新的设计系统或者云端账号体系。
• 希望项目文件和工作区留在本机的团队。本地优先可以减少把项目资产交给另一套设计云平台，但所选 agent 背后的模型服务仍可能把 prompt 发往云端；交易所团队不能把“本地文件”误当成“所有数据都不出机器”。

不太适合的场景:团队没有稳定的 PRD 写作习惯、指望靠原型生成工具倒逼需求澄清;或者需要高度定制化的视觉设计交付(品牌视觉规范复杂、需要专业设计师精修的场景),agent 生成的原型更适合做交互验证和评审沟通,不是最终视觉交付物。

这是官方仓库产品导览里的原型工作台截图,展示的是生成出的原型和预览面板并排展示的实际界面。评审的时候直接对着这个界面走一遍交互,比对着静态设计稿口头描述效率高很多——但截图里看到的完成度,不代表内容和数据都经过了核实,这一层判断还是要回到人工评审。

开始前检查清单

• PRD 是不是已经写清楚了主要状态和异常路径,而不是只有正常流程
• 本机是不是已经装好了要用的 coding agent(Claude Code、Hermes 或其他),并且能独立跑通一次简单任务
• Node 版本是不是 24.x,pnpm 是不是通过 Corepack 锁定在 10.33.2
• daemon 端口和 web 端口是否和本机其他服务冲突,需要的话提前定好自定义端口
• 要喂给 agent 的示例数据是不是已经替换成了假数据,没有生产数据、没有真实用户 PII
• prompt 和项目目录文件里有没有混入 API Key、私钥、助记词等敏感信息
• 评审环节是不是已经安排了人工核对内容,而不是只看原型的视觉完成度
• 如果要用 Hermes 的 ACP 路径,是不是已经确认过本机 Hermes 装好了 acp 可选依赖(uv pip install -e '.[acp]')

Sources

[1] https://github.com/nexu-io/open-design — Open Design
[2] https://github.com/nexu-io/open-design/blob/main/docs/architecture.md — Open Design Architecture
[3] https://github.com/nexu-io/open-design/blob/main/docs/agent-adapters.md — Open Design Agent Adapters
[4] https://github.com/nexu-io/open-design/blob/main/QUICKSTART.md — Open Design Quickstart
[5] https://hermes-agent.nousresearch.com/docs/user-guide/features/acp — Hermes ACP Host Integration
[6] https://github.com/nexu-io/open-design/blob/main/apps/daemon/src/runtimes/defs/hermes.ts — Open Design Hermes Runtime Definition
[7] https://github.com/nexu-io/open-design/blob/main/apps/daemon/src/runtimes/defs/claude.ts — Open Design Claude Runtime Definition