MateClaw 1.8.0 把重点放到了“写材料”场景：同一套个人 AI 操作系统不仅能管理知识、记忆和工具，还开始面向公众号、小红书等内容渠道组织写作流程。这个变化值得关注，因为真正可用的内容 Agent 不能只生成一段文字，它还要完成资料检索、结构规划、渠道改写、人工审批和操作审计。
MateClaw 采用 Java 与 Vue 3 构建，底层基于 Spring AI Alibaba。其能力组合包括 Agent 编排、LLM Wiki 知识引擎、记忆生命周期、工具与技能运行时、MCP/ACP、审批审计，以及 Web、钉钉、飞书、企业微信、Telegram、Discord、Slack 等多渠道接入。1.8.0 的写作能力，可以看作这些基础设施在内容生产场景中的一次汇合。
写公众号和小红书，不只是换一个提示词
同一份材料投放到不同平台时，真正需要变化的是内容结构和表达策略。
公众号文章通常需要完整论证：标题明确，开头交代问题，中间展开背景、方法和案例，结尾给出行动建议。小红书内容则更强调快速进入主题、短段落、清晰列表和适合移动端浏览的节奏。简单地要求模型“把文章改成小红书风格”，容易得到语言表面不同、信息结构却没有变化的结果。
更稳妥的 Agent 流程可以拆成几个状态：
- 从 LLM Wiki 或其他知识源检索事实与历史材料。
- 根据写作目标生成内容提纲。
- 产出一份保留完整事实的母稿。
- 分别生成公众号版和小红书版。
- 执行事实、敏感词、篇幅和格式检查。
- 进入人工审批，批准后再交给渠道工具处理。
这正是 StateGraph 运行时适合解决的问题。ReAct 可以让 Agent 根据中间结果决定是否继续检索或调用工具；Plan-and-Execute 则适合先形成任务计划，再按步骤产出和校验内容。二者结合后，写作不再是一次模型调用，而是一个具有状态、分支和失败处理能力的工作流。
知识、记忆与工具分别解决什么问题
LLM Wiki 知识引擎适合保存相对稳定、可追溯的事实，例如产品说明、技术文档、品牌术语和历史文章。写稿时应优先从这些材料中提取依据，降低模型凭空补充数据或案例的风险。
记忆生命周期解决的是另一类问题：用户偏好的标题长度、禁用词、常用语气、审核人的修改习惯，都可能跨任务复用。但记忆不能无限累积。过期偏好、一次性活动信息和未经确认的修改意见应设置有效期或审核状态，否则 Agent 会把旧规则带进新文章。
工具、技能、MCP 和 ACP 运行时则把文本生成连接到外部系统。例如，一个技能可以负责读取选题库，另一个工具执行格式检查，MCP 服务提供企业知识检索，渠道适配器负责把审批后的内容送到对应入口。审批与审计必须处于发布动作之前，这不仅能减少误发，也能保留“谁生成、引用了什么、谁批准、调用了哪个工具”的记录。
可以这样实践：把一份母稿改造成双渠道内容
下面是一个可直接改造的工作流配置示例。由于摘要没有给出 MateClaw 1.8.0 的实际配置格式和接口名称，示例使用通用 YAML 描述 StateGraph，字段需要按项目真实 API 调整。重点是保留节点边界、审批关卡和渠道隔离。
workflow:
id: dual-channel-content
input:
required:
- topic
- audience
- source_scope
state:
draft: null
wechat_article: null
xiaohongshu_post: null
review_status: pending
nodes:
- id: retrieve_sources
type: knowledge_search
engine: llm-wiki
arguments:
query: "{{ input.topic }}"
scope: "{{ input.source_scope }}"
- id: plan
type: agent
strategy: plan-and-execute
prompt: |
根据检索材料制定写作计划。
受众：{{ input.audience }}
只使用材料中可以确认的事实；缺失数据标记为“待确认”。
- id: write_master_draft
type: agent
strategy: react
prompt: |
按写作计划生成母稿，保留事实出处标识。
不要编造数字、客户名称或产品能力。
- id: adapt_wechat
type: agent
prompt: |
将母稿改写为公众号文章：保留完整论证、二级标题和结论。
- id: adapt_xiaohongshu
type: agent
prompt: |
将母稿改写为适合移动端阅读的短内容。
使用短段落和清晰列表，不添加母稿中不存在的体验结论。
- id: content_check
type: skill
skill: factual-and-policy-check
on_failure: write_master_draft
- id: human_approval
type: approval
reviewers:
- content-owner
reject_to: write_master_draft
- id: dispatch
type: tool
run_if: "{{ state.review_status == 'approved' }}"
arguments:
wechat: "{{ state.wechat_article }}"
xiaohongshu: "{{ state.xiaohongshu_post }}"
edges:
- retrieve_sources -> plan
- plan -> write_master_draft
- write_master_draft -> adapt_wechat
- write_master_draft -> adapt_xiaohongshu
- adapt_wechat -> content_check
- adapt_xiaohongshu -> content_check
- content_check -> human_approval
- human_approval -> dispatch
实际接入时，建议把“生成”和“发布”设置成两个不同权限域。写作 Agent 可以生成草稿并提交审批，但只有发布工具持有渠道凭据，而且该工具只接受已批准的任务 ID。即使提示词被污染或模型误判，Agent 也不能绕过审批直接发送内容。
渠道改写的提示词也应使用结构化输入。下面的模板可以放进技能配置或提示词仓库：
角色：企业内容编辑
任务：基于母稿生成 {{ channel }} 版本
目标受众：{{ audience }}
硬性约束：
1. 不增加母稿之外的数字、案例、承诺和产品能力。
2. 对无法确认的信息输出“[待确认：具体问题]”。
3. 保留 source_id，便于审核人员回查。
4. 只输出 JSON，不执行发布操作。
输出结构：
{
"title": "",
"summary": "",
"body_markdown": "",
"source_ids": [],
"review_notes": []
}
结构化结果比自由文本更容易进入 Vue 3 审核界面：标题、正文、引用和风险提示可以分别展示，也方便后端保存版本差异和审批意见。
上线前需要守住的边界
接入内容团队时，不要一开始就开放全自动发布。更合理的推进方式是先运行“检索、生成、人工复制”模式，验证事实准确率和渠道适配质量；随后接入审批流与审计日志；只有在权限隔离、幂等控制、失败重试和凭据管理完善后，再考虑自动分发。
上线检查可以集中在六个问题上：知识材料是否有来源和更新时间；长期记忆能否删除或过期；两个渠道是否使用独立模板；审批是否无法被 Agent 跳过；发布工具是否具备最小权限；审计记录能否还原每一次模型和工具调用。
MateClaw 1.8.0 的价值不只在于“能写公众号和小红书”，而在于它尝试把内容写作放进完整的 Agent 运行环境。对于已经使用 Java、Spring Boot 和企业协作工具的团队，这条路线降低了知识检索、流程编排、人工审核与多渠道交付之间的集成成本。代价则是系统复杂度明显高于单次提示词调用，因此权限、评测、可观测性和失败恢复应与写作能力同时建设。