为了想清楚 Agent 时代怎么发社交平台，我做了 ArcSocial

为了想清楚 Agent 时代怎么发社交平台，我做了 ArcSocial

ArcSocial 不是为了让 AI 替我写文章，而是为了把人的判断、Agent 的协作和平台发布流程组织成可追溯、可维护的工作区。

从开始发公众号的第一天起，我就在想一件事：

如果未来很多内容工作都会发生在人和 Agent 的协作里，那么发社交平台这件事到底应该怎么组织？

后来，我把这套实践整理成了一个开源工作区，叫 ArcSocial。

它面向的不是“让 AI 替我写文章”，而是人和 Agent 一起完成社交内容生产、平台适配、发布准备和过程复盘。

01 人主导，Agent 协作

在这个过程中，我越来越清楚一件事：Agent 参与内容生产，并不意味着人把写作外包给 AI。

对我来说，选题、角度、判断和最终取舍仍然在人这里。

Agent 更像一个协作对象。它可以帮我整理材料、展开结构、生成版本、检查遗漏、适配平台。但一篇文章要不要写、怎么写、哪些表达不成立、哪些地方必须重写，最后还是我来判断。

有时候我不满意，也会直接自己写一段，再让 Agent 做整理和适配。

所以 ArcSocial 要解决的不是“让 AI 替我写文章”，而是把这种人主导、Agent 协作的过程组织起来。

02 核心是几个 skill

ArcSocial 不是一个 Web/App 服务，也不需要启动常驻后台。它更像一个开源的 agent-native 社交内容工作区。

你把它拉下来，在项目根目录里和 Agent 对话。ArcSocial 负责提供一套工作流和文件边界，让 Agent 知道自己现在该做什么。

ArcSocial 的核心其实是 .agents/skills 里的几个 skill。它们不是普通文档，而是给 Agent 看的工作规则。

现在主要有四个：

• arcsocial-intro：负责新用户入口。它会说明 ArcSocial 是什么、当前支持哪些平台、怎么初始化 workspace/，以及用户应该怎样开始和 Agent 对话。

• social-publishing-workflow：负责完整发布流程编排。它会判断当前内容处在哪个阶段：只是一个想法、已经有标准草稿、已经有平台稿，还是要进入预览和发布准备。

• social-writing：负责写作层。它会保留原始输入，生成标准草稿，再在需要时生成不同平台的适配稿。

• wechat-draft：负责公众号发布准备。它会从公众号平台稿生成本地预览、发布报告、Wenyan-ready Markdown，并在确认后写入公众号草稿箱。

这几个 skill 组合起来，才是 ArcSocial 的核心能力。它们让 Agent 不只是“帮忙写一段”，而是知道自己处在流程的哪一步。

什么时候记录原始输入，什么时候写标准草稿，什么时候适配公众号，什么时候只生成本地预览，什么时候必须停下来等人确认。

ArcSocial 的核心不是一个界面，而是一套能被 Agent 稳定执行的工作规则。

03 人工调整也进入流程

这里有一个细节很关键：ArcSocial 不是追求把人工调整消灭掉，而是把人工调整放进流程里。人可以继续改选题、改结构、改表达，Agent 则负责把这些修改放回正确的层级，再继续完成平台适配和发布准备。

它的使用方式也很简单。你不需要先记住所有目录，可以直接对 Agent 说：

用 ArcSocial 帮我把这个想法整理成一篇公众号文章。

或者：

继续完善这篇标准草稿，准备发公众号。

Agent 会按这些 skill 的约定，把原始输入、标准草稿、公众号稿和发布准备产物放到对应位置。

ArcSocial 不是替你做判断，而是让人和 Agent 的协作过程有明确路径。

04 一篇文章不应该只有最终稿

ArcSocial 里，一篇文章通常会分成几层：

• 原始输入：保留最开始的想法、口述、材料或补充。

• 标准草稿：平台无关的主版本，承载核心观点和论证结构。

• 平台稿：面向公众号、X、LinkedIn、小红书、知乎等平台的适配版本。

• 发布产物：本地预览、Wenyan 输入、发布报告和非敏感结果记录。

这看起来比直接写一个 Markdown 麻烦，但它解决的是一个真实问题：

平台稿不应该成为唯一事实来源。

公众号稿为了阅读体验，可能会调整标题、段落节奏、摘要和图片位置。其他平台也会有自己的表达方式。如果所有内容都混在一个文件里，过一段时间就很难知道：这篇文章真正想表达的核心观点是什么？哪些是平台表达？哪些是发布层处理？

所以 ArcSocial 保留标准草稿，再从标准草稿生成平台稿。

这不是仪式感，而是为了可追溯。

当 Agent 参与长期协作时，过程可追溯会比以前更重要。

05 公众号是第一个完整 adapter

目前 ArcSocial 里完成度最高的平台，是微信公众号。

它可以从 workspace/platforms/wechat/ 读取公众号平台稿，生成几类发布准备产物：

• 本地完整预览。

• 发布检查报告。

• Wenyan-ready Markdown。

• 可选封面和正文图片引用。

• 非敏感发布结果记录。

在你确认后，它可以通过 wenyan-mcp 写入公众号草稿箱。

我没有选择重新实现公众号底层能力，而是接入了开源项目 wenyan-mcp。ArcSocial 负责上层工作流：从想法到草稿，从草稿到平台稿，从平台稿到发布准备，以及文件边界和确认门禁。

Wenyan 负责更接近公众号草稿箱的渲染、图片上传和草稿创建。

这个分工也代表 ArcSocial 的定位：它不是要吞掉所有平台能力，而是把“人和 Agent 协作发社交平台”这条链路组织起来。

公众号 adapter 解决的是从平台稿到草稿箱之前的最后一段路。

06 发布层会继承最近的风格

还有一个我很需要的能力：它会自动参考最近的公众号文章风格。

比如生成预览时，wechat-draft 会查找最近成功发布或最近准备过的公众号稿，把它作为排版风格参考。然后在发布层处理标题样式、段落节奏、本地图片路径、列表安全转换和预览字段展示。

这个过程不会覆盖人工源稿。标准草稿仍然在 workspace/content/drafts/，公众号平台稿仍然在 workspace/platforms/wechat/，自动排版和安全处理只发生在 workspace/publishing/wechat/ 下面的生成产物里。

发布报告也会把这些事情说清楚：这次参考了哪篇文章的风格、内容变更范围是什么、封面和摘要是否齐全、正文图片是否可用、有没有需要人工处理的风险。

这对我来说很重要。人工调过的风格可以自然延续，Agent 自动化又不会反过来污染源文件。它更像是在发布层接住人工经验，而不是替人重写文章。

发布层不是重写文章，而是把已经形成的人工风格稳定延续下去。

07 邀请一起维护

这篇文章本身也是用 ArcSocial 生成和维护的。更准确地说，我之前发公众号时，已经把草稿、平台稿、图片、预览和发布产物都放进了这个工作区。

ArcSocial 不是一个先想象出来、再去找使用场景的工具。它是从我自己的发布实践里一点点长出来的。

GitHub 在这里：

https://github.com/feitianchengzi/arcsocial[1]

接下来我希望继续开源维护它。它现在还不完整，但方向是清楚的：做一个面向 Agent 协作的社交内容工作区。

我尤其希望有人一起补两类东西：

• 平台 adapter：把 X、LinkedIn、小红书、知乎、即刻、Medium 等平台，从“只能生成平台稿”推进到“可以检查、预览、准备发布”。

• 实践反馈：告诉我这套流程在哪些地方太重、太轻、太绕，或者不符合真实发布习惯。

我越来越觉得，AI 时代很多工具不会先以完整 App 的形态出现。它们可能先是一组 skills、一套文件约定、一个本地脚本、一个平台 adapter、一个能被 Agent 稳定调用的工作区。ArcSocial 就是这种形态的一个小尝试。

它不是为了证明“AI 可以写文章”。对我来说，更重要的问题是：

当人和 Agent 一起做长期内容生产和社交平台发布时，我们怎样让这个过程可控、可追溯、可维护，并且能被更多人一起改进？

如果你正在做类似的事情，欢迎一起来试。

引用链接

[1]https://github.com/feitianchengzi/arcsocial

文章来自于微信公众号 “碳基不蒸馏”，作者 “碳基不蒸馏”