为了想清楚 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
文章来自于微信公众号 “碳基不蒸馏”，作者 “碳基不蒸馏”