doubao-seed-evolving和Grok同时开发Obsidian插件，Grok竟然惜败

AI 时代，最大的好处就是可以无限简化自己的工作流，并且是以最适合自己的方式。（毕竟花的是自己的 token

所以在公众号发文这一方面，我早就把所有环节打通，并封装成了 Agent 友好的 CLI ，使用者只需要写好文章，就可以通知自己的 codex、claude code、Hermes Agent 等等让它调用 CLI 并且追踪整个发布流程。

但 CLI 对于普通用户来说，门槛还是较高，所以我也在尝试多种 GUI 去包装和简化背后的逻辑。

这次我就结合很多人都在用的 Obsidian 来开发一个插件，直接支持在 OB 里发布文章到草稿箱。使用的模型是火山 Agent Plan里的「doubao-seed-evolving」。

这是一个不会更改模型名称，但能力一直在进化的模型。比如你用 deepseek-v4-pro ，当他发布 v5 时，你就需要把模型名改为 deepseek-v5-pro ，但豆包这个模型会一直用这个名字不需要你去替换，而且它的迭代速度很快，按周更新，支持 1M 超长上下文，具备复杂任务编排、长程规划、代码生成与工具调用能力。

我平时是基本不用 doubao 的模型的，但是其他能买到的模型使用强度很高，这次我就拿 Grok 和它做对比，感受一下它是个什么强度。

项目情况

维度	数量	说明
TypeScript 总计	约 2.5 万行	`src/` 下全部 `.ts`
业务代码（不含测试）	约 1.9 万行	91 个源文件
测试代码	约 0.6 万行	30 个测试文件
HTML 模板	约 0.2 万行	封面、长图、海报等渲染模板
CLI 命令数	30 个	工作流 17 + 运维工具 13

核心功能点

模块	行数	含义
命令层 `commands/`	~5,000	用户/Agent 能调用的每个动作
核心编排（状态机、任务、路由等）	~5,200	「下一步该干什么」的大脑
图片渲染 `imgx/`	~3,000	封面、海报、长图生成
微信 HTML 预览/导出 `wechat-preview/`	~2,800	Markdown → 公众号排版
发布通道 `providers/`	~1,700	真正推到微信/博客/CDN
Schema + 适配器	~1,000	配置校验、插件接口

这个 CLI 最大的特点是：会输出下一步建议， Agent 每次都读取并且按建议去继续调用，不需要过多的业务字段描述就能知道自己要做什么。

并且，一个发布任务运行时，会产生一个关联的 json 文件，用字段来完整的记录所有状态，不需要靠人和 Agent 反复对话，因为反复对话会产生很多幻觉，且依赖 Agent 的记忆能力去把控。

基于此设计，就可以实现人工中途接续，多 Agent 协作等能力。

doubao-seed-evolving 分析时也要理解它要实现的插件功能的业务范围，其实只是对接一部分，并且需要搜索如何开发一个 Obsidian 插件。

我会一次性给它全部需求，看它的完成效果如何

编写计划

简单描述一下我需要的功能，希望它开发能直接给我应用到 OB 仓库上，我重启就能用

Markdown

/plan 这是一个我日常在使用的 CLI 工具，主要核心功能是把本地 MD 直接发布到公众号草稿箱里。现在需要你分析它的主要功能，然后帮我写一个 Obsidian 插件能让我在 OB 里使用它。

  1. ob 插件不需要发布到官方自己本地创建一个新的目录，然后软连接到 ob 里就行， ob 仓库使用「content」
  2. 插件需要在右侧出现，一个新的 tab 栏，要显示出当前打开的文件，发布状态，当前设置的平台、账号、一键发布按钮
  3. 插件设置页面需要 1 环境检测，安装 bun、zzhub-pipeline cli 的命令 2. 账号选择 可以设置当前默认的账号 3 其他的你看看还有什么有价值的显示信息
  4. 发布一篇文章后，需要记录并关联，能在面板看到关联的 run_id ，并把按钮显示为「重新发布」
  5. 发布时，状态需要及时回显。
  6. 面板中显示文章名称时，优先使用 title 字段，其次使用文件名

发出指令后自动走了superpower，我的心一凉，token 估计吃不住