人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载导读add_reaction是 IronClawAgent OS标准化消息框架standardized messaging framework中 16 个核心标准操作core standard messaging operation之一属于「写入族」write family它以扩展所连接的账号身份为一条消息添加 emoji 反应。本文以 add_reaction.core.md 为主干结合其 JSON Schema 契约、host 侧权威词汇messaging.rs以及 Slack、Telegram 两大厂商扩展的真实实现与测试完整讲解该操作的语义约束、输入输出格式、厂商 emoji 方言差异、幂等处理与底层调用链。读完本文你将理解为什么message_ref必须来自先前的 send/read、emoji 的「厂商 token」到底指什么以及一个标准消息操作从模型描述到厂商 HTTP 调用之间经历了怎样的契约化过程。一、操作语义原文档核心约束add_reaction.core.md是 IronClaw host 面向模型model-facing的操作描述核心description core全文构成对该操作不可协商的语义定义Add an emoji reaction to a message on this extension, as its connected account.message_refmust be the exact object returned by a prior send or read on this extension — never invent one and never reuse a ref from a different extension.emojiis this vendors emoji token, a name or a unicode character; the addendum documents the exact dialect. Returns themessage_refandemojias confirmation that the reaction was applied.拆解出四条核心语义执行身份反应以「本扩展连接的账号」its connected account身份添加不是以系统管理员或宿主身份message_ref必须真实必须是「本扩展」上先前一次 send 或 read 返回的精确对象既不能凭空编造也不能复用其他扩展返回的 refemoji是厂商 token可以是名称name如thumbsup或 unicode 字符具体方言由该扩展的 vendor addendum附录记载宿主不规定统一写法确认回执成功时返回message_ref与emoji作为「反应已应用」的证明evidence与所有写入族操作的「写入必须带证据」原则一致。这段描述在 host 侧被编译进ADD_REACTION_CONTRACT见 messaging.rsstatic ADD_REACTION_CONTRACT: StandardOpContract StandardOpContract { op: StandardMessagingOp::AddReaction, input_schema: include_str!(../schemas/messaging/add_reaction.input.v1.json), output_schema: include_str!(../schemas/messaging/add_reaction.output.v1.json), output_schema_version: StandardSchemaVersion::V1, superseded_output_schemas: [], description_core: include_str!(../prompts/messaging/add_reaction.core.md), is_write: true, };契约由三部分合成输入 schema、输出 schema 与描述核心description core。扩展只能实现厂商侧机制不能定义或覆盖操作形态——这是标准化消息框架的核心设计ironclaw_host_api是整个系统中约 53 个 workspace crate 依赖的「零内部依赖权威词汇表」见 ironclaw_host_api README它只命名能力不执行任何逻辑。二、输入契约message_ref与emoji输入由 add_reaction.input.v1.json 严格约束JSON Schema draft-07{ $schema: http://json-schema.org/draft-07/schema#, title: Standard messaging add_reaction input, type: object, required: [message_ref, emoji], properties: { message_ref: { type: object, required: [conversation, message_id], properties: { conversation: { type: string, minLength: 1 }, message_id: { type: string, minLength: 1 } }, additionalProperties: false, description: The exact object returned by a prior send or read on this extension. }, emoji: { type: string, minLength: 1, description: The vendors emoji token (name or unicode); the addendum documents the dialect. } }, additionalProperties: false }要点顶层必须且只能有message_ref与emoji两个字段additionalProperties: false拒绝多余字段message_ref是一个两字段对象conversation与message_id两者均为非空字符串minLength: 1message_ref内部同样additionalProperties: false——多带一个thread之类字段也会被拒绝emoji为非空字符串未规定具体格式这正是厂商方言留给 addendum 的弹性空间。宿主在分发dispatch前会用该 canonical schema 校验每个标准操作的输入。测试 canonical_inputs_reject_empty_references_and_pagination_values 直接印证了这一点{message_ref: {conversation: , message_id: }, emoji: thumbsup}会被判定为非法——空字符串引用正是标准化框架要消灭的「静默空值」证据与ts:同类缺陷。三、输出契约确认回执与厂商扩展输出由 add_reaction.output.v1.json 约束{ type: object, required: [message_ref, emoji], properties: { message_ref: { type: object, required: [conversation, message_id], properties: { conversation: { type: string, minLength: 1 }, message_id: { type: string, minLength: 1 } }, additionalProperties: false }, emoji: { type: string, minLength: 1 }, vendor: { type: object } }, additionalProperties: false }message_ref与emoji是必填证据required——「反应已应用」必须有可验证的落点与结果写入族输出 schema 的证据要求由测试 write_output_schemas_require_evidence 统一守卫vendor为可选字段供厂商扩展携带额外元数据如 Slack 的ts等属于标准化框架「让厂商差异留在vendor命名空间内」的常规做法返回的message_ref与输入的结构完全一致从而可以被继续链式使用例如随后调用remove_reaction或get_message。四、为什么message_ref不可编造、不可跨扩展复用这是该操作最容易被忽略的安全语义也是描述核心用「never」强调的硬约束不可编造message_ref是消息在厂商侧的定位依据。编造的 ref 要么命中一条不存在的消息厂商返回错误要么更危险命中一条「碰巧」合法的消息——例如把message_id猜成时间戳格式就可能对不是目标的消息打上反应。标准化框架的立场是地址必须是先前观测的产物而不是模型推测的产物。不可跨扩展复用ref 携带的conversation/message_id是「本扩展」语境下的标识。不同扩展如 Slack 与 Telegram对会话、消息的编码完全不同把 Slack 返回的 ref 传给 Telegram 扩展只会命中不存在或完全不同的消息。Slack 实现中message_id就是厂商的ts如1751970001.000100见 types.rsTelegram 则是另一套 peer/msg_id 语义二者互不通用。该约束在 Slack 扩展的 serde 绑定层有直接测试types.rsadd_reaction缺失message_ref或 ref 缺少message_id都会反序列化失败与 canonical schema 的required完全对齐——保证「schema 校验通过的调用一定能反序列化反之亦然」。五、emoji 方言厂商 token 与规范化差异描述核心将emoji定义为「this vendors emoji token, a name or a unicode character」把精确方言留给各扩展的 addendum。两个已落地的实现展示了两种典型方言Slack 方言api.rs/// Slacks reaction endpoints take thumbsup, never :thumbsup:, and reject /// unicode characters outright — so the wrapping colons the model is likely /// to write are stripped rather than passed through to a guaranteed /// invalid_name. Anything else is left alone for Slack to judge. fn normalize_emoji(emoji: str) - String { emoji.trim().trim_matches(:).trim().to_string() }Slack 的reactions.add只接受不带冒号的名称thumbsup并直接拒绝 unicode 字符因此 Slack 扩展在调用厂商 API 前先做规范化把模型常写的:thumbsup:剥壳成thumbsup避免必然失败的invalid_name若规范化后为空例如只传了::则映射为messaging.unsupported_content输入错误见 api.rs。Telegram 方言writes.rslet emoji input_str(input, emoji)?; let reactions InputReactions::emoticon(emoji); let peer conversation.peer_ref(); let client session.connection().client(); vendor_call(session, OpFamily::Write, || { client.send_reactions(peer, message_id, reactions.clone()) }).await?;Telegram 使用真正的 unicode emoji 字符通过InputReactions::emoticon包装后调用send_reactions与 Slack 相反这里几乎不做格式转换——两种方言恰好印证了「厂商 token」这一抽象的必要性宿主不规定 emoji 的书写方式只规定它必须来自厂商的合法 token 集。六、底层调用链从契约到厂商 API以 Slack 扩展为例完整的add_reaction调用链为模型调用 add_reaction → host 用 canonical input schema 校验参数 → WASM guest 反序列化 SlackUserActionaction add_reaction → api::add_reaction(message_ref, emoji) → normalize_emoji(emoji) // 剥壳冒号 → reaction_payload(...) // conversation→channel, message_id→timestamp, name → POST reactions.addslack_api_call_raw → reaction_write_outcome(..., ALREADY_REACTED) // 幂等折叠 → 返回 AddReactionResult { message_ref, emoji }其中reaction_payload完成从规范 ref 到 Slack 参数的映射api.rsserde_json::to_string(serde_json::json!({ channel: message_ref.conversation, timestamp: message_ref.message_id, name: name, }))message_ref.conversation→ Slackchannelmessage_ref.message_id→ Slacktimestamp即消息tsemoji→ Slackname。返回的AddReactionResulttypes.rs刻意回显规范化后的 emoji使被剥壳的:thumbsup:在回执中以thumbsup呈现模型能看到实际应用的 token。幂等already_reacted不是错误Slack 对「已经加过同一反应」返回already_reacted。若把该码当作错误上报模型会被推向重试一个「无法改变任何状态」的调用。因此 Slack 扩展实现了reaction_write_outcomeapi.rs只要厂商返回的 end-state 码恰好是「请求的终态已成立」就按成功处理其余失败包括另一族的幂等码no_reaction用在reactions.add上仍走封闭错误分类。这是写入族操作「以终态为准」的典型工程取舍。七、写入族地位与错误码分类在 messaging.rs 的封闭枚举中AddReaction与SendMessage、EditMessage、DeleteMessage、RemoveReaction、OpenDm并列为 6 个核心写入操作is_write()返回true。写入地位有两层含义manifest 绑定要求按框架规范spec §6 rule 4写入族操作必须声明external_write读取操作则不受此强制错误分类语义host 侧维护封闭的错误码词汇表StandardMessagingErrorCode共 12 个均以messaging.前缀命名如messaging.unsupported_content、messaging.rate_limited、messaging.permission_denied。厂商错误只映射一次到这些码无法映射的落入messaging.vendor_error兜底。add_reaction可能触达的相关码包括UnknownMessageref 无法解析、PermissionDenied账号无权限、RateLimited可重试等具体语义以 messaging.rs 的枚举注释为准。八、如何绑定standard_op与 addendum渠道扩展若想提供add_reaction不直接实现一个任意命名的工具而是在扩展 manifest 中把自有工具绑定到标准操作standard_op字段参考 slack manifest.toml 与 telegram manifest.toml 中slack.add_reaction → add_reaction、telegram.add_reaction → add_reaction的映射。绑定后操作名、输入输出形态、模型描述核心均由 host 权威定义ironclaw_host_api扩展只补vendor addendum方言说明如 Slack 只接受无冒号名称、Telegram 接受 unicode 字符运行时的操作级输出校验由ironclaw_host_runtime的 op-keyed validator 执行扩展包内的绑定关系会被 first_party_manifest_v3_parity.rs 等组合级测试持续守卫防止绑定与契约漂移。九、测试验证与契约守卫围绕add_reaction的契约性由多层测试兜底层次测试/位置验证点host 契约sixteen_core_ops_have_complete_contracts16 个核心操作契约完整schema 可解析可编译、描述核心非空、is_write与枚举一致host 契约canonical_inputs_reject_empty_references_and_pagination_values空conversation/message_id被拒绝厂商绑定message_addressing_ops_require_a_full_message_refadd_reaction必须携带完整 ref厂商绑定reaction_ops_differ_on_whether_emoji_is_requiredadd_reaction的emoji必填remove_reaction的emoji可选运行时ironclaw_host_runtime标准操作校验op-keyedVALIDATORS分发前按 canonical schema 强制校验输入/输出这些测试共同保证契约文本JSON Schema 描述核心、host 校验器、厂商 serde 绑定三方对「什么是一次合法调用」的理解永远一致。十、小结add_reaction表面上只是「给消息加个表情」实则是 IronClaw 标准化消息框架的一个完整切片模型看到的是一段带强约束的描述核心host 持有的是不可变的 JSON Schema 契约与封闭错误词汇厂商扩展负责把规范地址翻译成各自 API 方言并折叠幂等结果。理解它就理解了整个标准消息框架「扩展实现厂商机制、宿主定义操作形态」的分工原则——从message_ref的真实性约束到emoji的方言弹性再到写入必带证据的回执设计每一处都在为「Agent 以连接账号身份可靠、可审计地执行消息操作」服务。进一步阅读完整的 16 个核心操作描述与 schema 位于 crates/contracts/ironclaw_host_api/prompts/messaging/ 与 crates/contracts/ironclaw_host_api/schemas/messaging/配套的 Slack/Telegram 厂商实现分别位于 crates/extensions/packages/slack/wasm-src/ 与 crates/extensions/packages/telegram/src/linked/。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw 标准消息操作契约深度解析remove_reaction 表情移除的规范、Schema 与跨供应商实现IronClaw 标准消息操作契约深度解析remove_reaction 表情移除的规范、Schema 与跨供应商实现 本文聚焦 IronClaw一款面向隐人工智能AI 应用交互助手AI Agent跨平台直播聚合应用架构设计Dart Simple Live的技术实现深度解析跨平台直播聚合应用架构设计Dart Simple Live的技术实现深度解析 在移动互联网时代直播平台如雨后春笋般涌现用户常常需要在多个平台间切换才能观看人工智能AI 应用交互助手AI AgentHome Assistant Telegram bot set_message_reaction 动作详解为 Telegram 消息自动添加表情回应Home Assistant Telegram bot set_message_reaction 动作详解为 Telegram 消息自动添加表情回应 本篇以文档教程智能家居物联网上一篇磁力搜索终极指南如何用开源工具实现一站式资源聚合下一篇OnmyojiAutoScript模拟器登录OASX界面网络错误解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
