SocialHub.AI
新增功能 · 按工作区逐步推出

人工智能治理:反思与审批

Flash 将每个 AI 发起的操作置于每个操作授权装置之后 - auto、review 或 forbidden - 在 AI 活动和审批控制台中为每个工作区配置。对于 MCP 上的 AI 客户端,这意味着两件事:您可以发现业务对象以及在行动之前允许您执行的操作,并且您的写入调用返回结构化结果 - 已执行、等待人工批准或因机器可读原因而被拒绝。

本指南涵盖了自省工具、审查机制下的写入语义以及审批生命周期。它基于相同的受管控机制构建。 MCP 服务器文档已记录在内 MCP 集成指南有关业务概览,请参阅…… AI治理与审批产品页面. 设备路由是逐步启用的——以下行为将随着受控操作逐步部署到您的工作区而生效。

业务-object 内省 (范围 introspection:read)

三个读取工具让 AI 客户端在接触业务之前就能了解其结构:哪些对象存在(包括工作区自身的自定义字段和自定义对象)、每个属性的含义、对象之间的关系以及哪些操作可执行——包括它们的前提条件和当前状态。一个行为良好的代理会首先调用这些工具,并且只提出状态实际允许的操作。

list_objects读取

发现键的工作区中可用的业务对象:会员、订单、优惠券、活动、门店、产品、细分、标签——以及工作区定义的任何自定义对象。返回每个 object 的键、标签和一行含义说明。先打电话了解情况,再阅读或采取行动。

参数: (none)
describe_object读取

一个 object 的完整结构:包括其属性(含工作区的自定义字段)及其类型和业务含义,以及与其他对象的关系(例如,订单属于某个成员;优惠券可以发放给某个成员)。PII 字段仅作为元数据返回——名称、类型、语义和 PII 标志——绝不返回其值。

参数: object
list_actions读取

AI 客户端可以执行的操作,以及每个操作的前提条件和当前授权机制(自动/审核/禁止),均由工作区配置。按 object 筛选,仅查看与其相关的操作。此筛选结果正是治理层将强制执行的内容——利用此筛选结果可避免提出会被拒绝的操作。

参数: object?

PII 仅包含元数据,这是设计使然。 自省功能描述了包含个人信息(名称、类型、含义以及 pii 标志)但从不返回其值的字段。读取实际成员数据需要通过成员读取工具及其各自的权限范围。

示例:描述一个 object,然后检查齿轮。

请求/响应结构的描述性示例(简略版 - 实际响应会列出所有字段和操作):

// describe_object { "object": "member" }
{
  "object": "member",
  "label": "Member",
  "meaning": "A loyalty program member owned by this workspace.",
  "fields": [
    { "name": "email",            "type": "string",  "pii": true,
      "meaning": "Contact email. PII: metadata only — values are never returned here." },
    { "name": "tier",             "type": "string",  "pii": false,
      "meaning": "Current loyalty tier." },
    { "name": "membership_no",    "type": "string",  "pii": false, "custom": true,
      "meaning": "Workspace-defined custom field." }
  ],
  "relationships": [
    { "to": "order",  "kind": "has_many",  "meaning": "Orders placed by this member." },
    { "to": "coupon", "kind": "has_many",  "meaning": "Coupons issued to this member." },
    { "to": "tag",    "kind": "has_many",  "meaning": "Tags currently applied to this member." }
  ]
}
// list_actions { "object": "member" }
{
  "actions": [
    { "action": "issue_coupon",     "gear": "review",
      "preconditions": ["member has consent", "coupon pool has stock"] },
    { "action": "earn_points",      "gear": "auto",
      "preconditions": ["amount within the workspace cap"] },
    { "action": "assign_tag",       "gear": "auto",
      "preconditions": ["tag exists and is active"] },
    { "action": "add_member_note",  "gear": "auto",
      "preconditions": ["note passes server-side sanitation"] },
    { "action": "send_campaign",    "gear": "review", "locked": true,
      "preconditions": ["sending can never be auto — a human always approves"] }
  ]
}

您看到的 gear 是将会强制执行的齿轮——工作区会在控制台中为每个操作配置它,并且每个操作的断路器可以随时将操作降级到 review(它只会自动降级;只有人工才能恢复)。请使用 list_actions 重新检查,而不是为长时间会话缓存齿轮。

审查齿轮下的写入工具:待定/拒绝

当一个 MCP 写入工具的目标是执行一个齿轮为的操作 review调用确实 不感兴趣 执行副作用。它会返回一个结构化结果:要么提案已排队等待人工审批(pending或者直接被拒绝(refused)具有机器可读性 reason_code 和 suggested_action.

// proposed — waiting for a human
{
  "status": "pending",
  "proposal_id": "prop_9f2c…",
  "action": "issue_coupon",
  "expires_at": "2026-07-10T00:00:00Z",  // 7 days
  "message": "Queued for human approval in
              AI Activity & Approvals."
}
// refused — with a reason and a next step
{
  "status": "refused",
  "action": "issue_coupon",
  "reason_code": "recently_rejected",
  "suggested_action": "A human rejected this
    proposal recently. Do not re-propose;
    consider a different action or ask the
    operator."
}
reason_code含义您的代理商应该做什么
gear_forbidden此操作的齿轮图标已设置为禁止在此工作区中使用(或者此操作永远无法自动执行——例如发送——并且是以需要自动执行的方式调用的)。不要重试。揭露拒绝;继续。 suggested_action (通常是另一种操作,或者“请人帮忙换挡”)。
recently_rejected最近有人拒绝了同一目标用户的相同提案——平台不会重新提交。尊重人的决定。不要重新提议或改写;遵照执行。 suggested_action.

每个拒绝都带有一个这种形状的 reason_code 加上一个 suggested_action — 将上面的代码视为要分支的代码,并将该字段视为可扩展的。拒绝对您来说是一个硬性界限,而不是重试的错误:永远不要重新措辞提案以跳过拒绝。

审批生命周期

pending 提案只能以一种方式解决:approved、rejected 或 expired。用户在 AI 活动与审批控制台中对其进行操作(按操作类型进行单次或批量操作);每日摘要邮件会显示待处理事项。

状态它是如何发生的然后
pending在审查操作的设备时调用了写入工具 - 该提案已排队等候人工批准。已批准 · 已拒绝 · 已过期
approved经人工审核。执行前,平台会重新验证人工智能的判断依据;如果判断不再成立(例如,客户已再次购买),则不会执行该操作。终端(结果记录在决策日志中;可单独撤销)
rejected有人拒绝了该提案,可以选择附上备注。同样的提案随后又被拒绝了。 recently_rejected 如果重新提交。终端
expired7 天内未做出决定——提案将自动过期,且不会执行任何操作。终端

幂等性保证

  • 一次批准,一次执行。批准提案只会执行一次操作;重复批准会重放已存储的结果,不会产生任何其他副作用。
  • 重新提交不会重复。 同一提案在待处理期间再次调用写入工具会返回相同的 pending 结果和 proposal_id——不会将第二张卡片加入队列。
  • 审批重新验证,执行是有条件的。 在审批时,平台会重新检查 AI 所述理由是否仍然成立;如果不再有后续操作(例如,客户已再次购买),则不会执行任何操作——记录的是结果而非操作本身。
  • 所有内容均经过审核,且可单独撤销。 提案、决策、授权路径(auto 或指定人员)、执行和结果均记录在决策日志中,其中单个条目均可撤销。

服务器是边界。 齿轮、重新验证、过期和每次操作的熔断机制均在Flash端强制执行——绝不依赖代理的推理或其客户端确认。无论客户端请求什么,发送类型的操作都不能自动运行。

透明度图元和玻璃盒模型库存

同样的“透明盒子”原则——所有自动化决策均被记录并可解释,个人数据与模型上下文隔离——不仅限于受控操作:还延伸至流量优化实验、出站 LLM 提示,以及为整个产品提供排名、预测和检测功能的传统机器学习模型库。

A/B流量自动优化:决策日志

周期性营销活动(自动化流程和用户旅程)可以选择启用随时间自动优化流量功能,该功能会根据观察到的点击效果,在不同的实验版本之间重新分配投放权重。每次重新分配都可审计:

  • 仅追加决策日志。 每小时重新计算一次,写入一条记录,其中包含应用的权重和易于理解的理由。记录永远不会被重写——日志完整记录了流量变化的原因。
  • 配置的拆分永远不会发生变化。您的实验的配置拆分作为基准保持不变;优化的权重会被计算并记录下来。
  • 探索底线:10%。 任何变体的权重都不会低于 10%,因此每个变体都能持续获得流量,并且任何逆转都可检测。
  • 平均分配,直到每个变体的交付量达到 ≥100。 权重将保持在配置的分配比例,直到每个变体的交付量至少达到约 100 次——不会在数据稀疏时重新分配权重,并且此机制永远不会宣布任何统计意义上的“赢家”。

供应商接缝处的 LLM PII 屏蔽

在任何提示离开 Flash 并发送给外部 LLM 提供商之前,会员的个人标识符都会被屏蔽——此操作在提供商连接处进行,因此所有 AI 功能都会经过此连接:

  • 确定性化名。 电子邮件地址、电话号码和类似卡片的数字序列将被替换为稳定的替代标记。相同的标识符始终映射到相同的化名,因此模型对同一提示的推理保持一致。
  • 掩码适用于每个 AI 功能发出的每个出站提示——无需启用,也无法从产品中关闭。
  • 仅掩码,绝不取消掩码。 输出边界处的映射是单向的:模型输出永远不会被重写以恢复真实标识符,因此原始 PII 无法通过 LLM 响应进行往返传输。

为什么这在今天至关重要。 Flash 的 AI 提示基于聚合数据和活动数据构建,而非个人记录——这种掩蔽机制是随着 AI 功能扩展而始终有效的强制性保证,而非对漏洞的修补。

玻璃盒式库存模型

产品中的每项预测或统计能力都采用经典的确定性模型:不使用黑盒评分或随机采样,相同数据始终得到相同模型。每项能力都有明确的可靠性门槛:未达到门槛时,不输出结果,而不是猜测;每项评分都附带可用于复算的数据。当前能力清单如下:

模型权力诚信验证
两种模型提升(两种确定性逻辑拟合)SoClaw 赢回工作清单排名 — 风险价值 × 提升,根据该计划自己的始终坚持的 RCT 进行训练仅激活过去 ≥200 个成熟处理行、≥50 个保留行和 ≥20 个转换,两者拟合收敛 - 低于此值,排名将回落到纯粹的风险价值。消极提升(请勿打扰)的成员会沉沦;每个任务都存储其分数快照。
每个会员的购买间 Gamma 值(基于关键时刻的方法)个人资料中的预计下次购买日期 + “预计下次购买剩余天数”细分条件(负值表示已过期)需要至少 3 个观察到的缺口(即至少 4 次购买)以及基于节奏规律性的变异系数阈值(≤1.5)——不规律的购买者将获得 NULL 值,绝不会获得虚构的日期。超过预期日期将作为真实的逾期信号发出。
基于团队的 L2 正则化逻辑回归点击倾向 (0–100),每晚根据团队自己过去 90 天的发送情况进行调整仅点击标签(从不打开 - Apple MPP 使它们膨胀);防泄漏事先点击功能;按固定时间表进行确定性全批次梯度下降。适合门≥500次发送/≥30次点击/≥50名会员;会员需要≥3次最近发送才能评分。
余弦归一化项-kNN在推荐界面上进行“还购买了”产品配对。co_count / √(买家(A) × 买家(B)) 纠正了受欢迎程度偏差;配对需要 ≥2 个共同买家才能实现;原始共同购买计数与分数一起存储,作为可检查的证据。
关联规则(支持度/置信度/提升度)交叉销售建议,每晚从商家自己的订单行中挖掘规则需要 ≥3 个同时发生的订单且置信度 ≥5%;每条规则都会存储其所依据的原始订单计数,因此任何数字都可以手动重新计算。会员资料界面会排除已拥有的商品,并且仅对活跃买家显示。
稳健统计异常值(中位数/平均绝对偏差)这 behavior_outlier 积分欺诈检测器稳健的 z ≥ 6 加上绝对下限(≥10 次收益交易;跳过 50 名活跃成员以下的团队);按月分组每个成员去重;仅冻结——它会开启审核,但永远不会自行作废。
Kaplan-Meier + Cox 比例风险(Nelder-Mead 部分似然)按月注册群组划分的留存率+“留存率与什么相关”面板视图上的打印定义:流失用户 = 90 天未购买,排除从未购买过的用户,30 人以下的队列隐藏和公开。Cox 拟合需要观察到 ≥30 次流失事件,且最多使用 3 个协变量;相关性标记为“相关性”,而非“因果关系”。
霍尔特-温特斯模型(每周季节性,固定常量)仪表板上未来 14 天的收入展望固定平滑常数——没有针对每个团队的调整表面;读取与其他屏幕相同的认证收入指标;虚线+误差带,并打印其美元基准;完全隐藏在 4 周的历史记录下;标记为预测,而不是承诺。

这些模型都不会独立运作:它们会进行排名、评分和标记,所有涉及资金流动或与会员联系的行为仍然会经过上述受控机制的处理。

有关每个模型的完整工程细节(方法、输入、输出列、诚实门和消费面),请参阅预测模型参考。