AI Agent 发布前的多维安全检查清单

在 AI Agent 向社交媒体发布内容之前，它应当证明来源、账号、渠道配置、审批、媒体素材和发布时间均准确无误。提交之后，它必须区分“请求已被接受”和“帖子已确认上线”。如果结果不确定，应进行调查，而不是自动重试。

这份单页模板适用于通过 Agent、Web Console 或 API 操作的人员，并不绑定任何特定工具。Groniz Connectors 可以处理 OAuth、各平台格式适配、定时发布，以及向 32 个以上网络投递内容，但不同客户端提供的调用路径不同，各服务提供商支持的能力也不尽相同。如需了解这份清单背后的完整生命周期，请参阅 AI Agent 社交媒体发布流程。

可复制的单页发布清单

将下面的内容块粘贴到 runbook、工单、Pull Request 或 Agent 指令中。每个目标渠道都应单独使用一份清单。除非书面策略另有规定，否则只要有一项未勾选，就必须停止本次运行。

## Agent-to-channel publishing run

Run ID:
Operator or agent:
Started at:
Source owner:
Destination:

### 1. Source evidence

- [ ] Record the canonical source URL, file, or version.
- [ ] Record its owner and last-confirmed timestamp.
- [ ] Extract the claims, names, dates, links, and required action that the post must preserve.
- [ ] Confirm the source is current, public or cleared for use, and free of secrets or embargoed details.

### 2. Client and publishing path

- [ ] Name the client or operator surface being used.
- [ ] Select one supported path for that client: Skill, CLI, MCP, Console, or REST API.
- [ ] Confirm authentication works without copying credentials into the draft or log.
- [ ] Record the path chosen; do not assume another client supports the same route.

### 3. Account and integration

- [ ] Discover the available integrations.
- [ ] Resolve the exact network, account, Page, profile, community, or channel.
- [ ] Record the integration reference and a human-readable account label.
- [ ] Confirm the connection is active and belongs to the intended publisher.

### 4. Live integration settings

- [ ] Retrieve or inspect the current settings required by this integration.
- [ ] Identify required fields and supported post, media, and scheduling options.
- [ ] Resolve every required setting before approval and submission.
- [ ] Stop if the live requirements conflict with the intended post.

### 5. Channel format

- [ ] Create a destination-specific draft rather than assuming one payload fits every network.
- [ ] Check the text, links, mentions, structure, and optional fields against the live requirements.
- [ ] Confirm the post suits the selected community and publishing context.
- [ ] Preview the complete destination-specific payload when the route allows it.

### 6. Facts and voice

- [ ] Match every concrete claim, name, date, price, quotation, and link to the source evidence.
- [ ] Remove unsupported implications and mark unresolved facts for a person to decide.
- [ ] Check the draft against the account’s approved voice guidance.
- [ ] Confirm that compression or formatting has not changed the meaning.

### 7. Media

- [ ] Confirm rights, consent, and destination compatibility for every asset.
- [ ] Upload each asset through the supported Groniz media workflow.
- [ ] Store the exact Groniz reference returned by the upload.
- [ ] Attach the returned reference, not a local path or arbitrary external URL.
- [ ] Confirm asset order, captions, and destination-specific media settings.

### 8. Approval

- [ ] Present the final text, links, destination, account, media, mode, and timing together.
- [ ] Record an explicit approve, revise, or reject decision and the reviewer.
- [ ] Bind approval to this exact content version and publishing context.
- [ ] Return for approval if content, destination, account, media, or timing changes.

### 9. Timezone and timestamp

- [ ] Choose publish-now or scheduled delivery.
- [ ] For a schedule, record the intended local time, named timezone, and exact timestamp with offset.
- [ ] Check date boundaries and daylight-saving interpretation where relevant.
- [ ] Confirm the stored schedule matches the approved human-readable time.

### 10. Submission

- [ ] Submit once through the selected path.
- [ ] Record the submission timestamp, response, and returned reference when available.
- [ ] Classify the result as rejected, accepted, scheduled, published, or unknown.
- [ ] Treat acceptance or scheduling as a workflow state, not final publication proof.

### 11. Verification

- [ ] Check the known delivery or scheduled-post state through the supported workflow.
- [ ] Confirm the intended account, content, links, media, and time.
- [ ] Check the public destination when a public result is available.
- [ ] Record the public reference or other evidence and the verification timestamp.
- [ ] Reconcile an unknown outcome before any retry.

### 12. Failure log

- [ ] Record the failed or uncertain 

每个目标渠道使用一份清单

多渠道营销活动可以共享同一套事实核心，但各项检查必须按目标渠道拆分。每份清单都需要包含各自的 integration、payload、配置、媒体素材处理方式、审批上下文、时间戳和验证结果。

这样可以避免将局部成功记录成全渠道成功。某个服务提供商接受的媒体素材组合，可能会在另一个服务提供商处失败；不同目标渠道能够提供的定时发布证据也可能不同。Groniz 提供了统一的发布层，但它并不会让所有服务提供商具备完全相同的能力。多平台媒体上传指南更详细地解释了上传结果与 reference 之间的边界。

让审批准确描述实际发送内容

审批应回答一个具体问题：是否允许将这份确切的内容连同这些素材，在这个时间发送到这个账号？如果审核者只能看到文本，就无法发现公司 Page 选错、图片已经过时，或者时间戳被按照错误的时区解析等问题。

审批记录应保存在操作方自己的工作流中，并绑定到稳定的草稿版本或内容 reference。不要声称 Groniz 提供了团队审批队列或审计日志；这些控制措施应由操作方自行定义。当不同风险等级需要不同审核者或不同过期规则时，可以使用人工审批策略模板。

将请求接受、内容发布和结果验证分开

提交操作只能告诉你请求是被接受还是被拒绝，却未必能够说明服务提供商是否已按预期将帖子公开发布。定时任务记录只能证明工作已经进入队列，不能证明结果已经上线并通过验证。

如果请求超时，或者调用方的连接中断，其结果应被视为未知，而不是自动判定为失败。在再次尝试之前，应检查当前可用状态，并查看预期的目标渠道。如果证据仍然模糊不清，应暂停本次运行并交由操作人员处理，以免产生重复内容。发布失败恢复工作流针对这种情况提供了一棵决策树和一份更完整的事件日志。

将清单嵌入发布流水线

清单只是发布系统的一部分。应通过可追溯的来源资料包为它提供输入，将相关证据与本次运行记录一同保存，并根据每项结果决定工作流的下一个状态。验证失败应退回准备阶段；实质性编辑则应重新进入审批阶段。请求被接受后进入验证阶段；结果存在歧义时进入核对流程。

每一步都可以由人工完成，也可以让 AI Agent 处理常规检查，并将异常情况升级给人工。在 AI 内容分发流水线中，流水线负责推动工作向前流转，而清单负责定义 Agent 与渠道交界处必须满足的条件。

如需通过客户端支持的调用路径连接 AI Agent，请选择相应的 Groniz Agent 配置方案。

对于后续处理，你可以考虑屏蔽此人和／或举报滥用行为。