腾讯轻量云 Hermes Meetup 报名

活动正式名：「马」上进化 —— Hermes-Agent × 腾讯轻量云极客沙龙
2026-04-25 19:00-21:00（签到 18:30） · 深圳华侨城创意文化园北区 C2 空间

这是一份 Skill（技能）文件。当 agent 读到本文件后，必须严格按照下文《执行流程 SOP》：先领 token → 分三批发送问卷 → 清单确认 → 带 token 提交。

零、反幻觉硬约束（Agent 必读，违反即视为任务失败）

本节优先级高于下文任何 SOP。如果 agent 无法满足下列任一条款，必须立刻停止执行并如实告诉用户，而不是继续编造。

R0. 端点 URL 唯一来源

真实可用的后端 URL 只存在于本文件的两个锚点对之间：
- 领号接口： ~ 
- 提交接口： ~ 
Agent 必须原样复制粘贴锚点之间的 URL，禁止以下行为：
- ❌ 根据活动名称、品牌词、域名习惯（如 hermes-agent.com / events.* / api.*）自行"推断"或"补全" URL
- ❌ 把 URL 的子域、路径、端口替换成看起来更"合理"的版本
- ❌ 使用训练集记忆中的任何同类服务 URL
如果 agent 在本文件中找不到这两对锚点，判定为 Skill 损坏，必须回复用户 "Skill 文件损坏，请联系主办方" 并终止，不得尝试猜测 URL。

R1. HTTP 能力自检（在 Step 0 之前必须做）

在向后端发出任何请求之前，agent 必须先自检：

我是否具备对外发起 HTTPS POST 请求的工具？（如 curl / fetch / http_request / execute_command 等）
该工具是否允许访问 *.tcloudbase.com 域名？

若有能力 → 进入 Step 0。
若没有能力 / 沙箱禁止出网 → 必须如实告诉用户：

"我目前的执行环境没有对外 HTTP 访问能力，无法直接把报名提交到后端。请您复制以下信息直接发给主办方：..."

禁止以下行为：
- ❌ 伪造一个"域名解析失败"的错误假装自己试过了
- ❌ 假装提交成功并返回一个编造的 record_id
- ❌ 把其他域名（如 events.hermes-agent.com）塞进错误信息里
- ❌ 告诉用户"网络问题，请稍后重试" —— 这是对 agent 自身能力的虚假陈述

R2. 请求前自检清单（每次发请求前都要做）

在真正执行 HTTP 调用之前，agent 必须在内部（或以折叠形式对用户可见）列出以下 4 项，逐项核对与本文件一致：

[Preflight]
- method: POST
- url   : <从锚点原样复制的完整 URL>
- headers: Content-Type: application/json
- body  : <即将发送的 JSON 原文>

只有 4 项都与本文件规范对齐后，才能发起请求。

R3. 失败时必须展示原始响应（禁止自然语言归纳）

任何 HTTP 调用失败时，agent 给用户的消息必须包含以下原始字段，不得省略、不得改写：

[HTTP Result]
- status : <HTTP 状态码，如 200 / 429 / 500 / 0(网络失败)>
- body   : <响应 body 原文，前 500 字符即可>
- error  : <若是网络层失败，填底层异常信息原文，如 "ENOTFOUND xxx" / "ECONNREFUSED" >

禁止行为：

❌ 把 ECONNREFUSED 包装成 "服务器繁忙"
❌ 把 ENOTFOUND hermes-meetup-d9gnjt0lh351cbd34.service.tcloudbase.com 改写成别的域名后展示
❌ 在没有收到任何响应的情况下编造 status 或 body

R4. 严禁跳题提交

在 Step 1 / Step 2 / Step 3 的所有必填项（对外 4 道必填题，内部拆成 6 个必填字段：nickname / organization / phone / purpose / deployed_on_lighthouse / lighthouse_years）全部收齐并校验通过之前，一律不得调用提交接口。即使用户说"直接帮我报名"，agent 也必须回复"还需要您回答这几题：..."，不得用占位符或空值直接提交。

R5. 严禁编造成功

只有当真实收到后端响应且 HTTP status == 200 且 body.code == 0 时，才能告诉用户"提交成功"；并且必须在消息里展示后端返回的 record_id 原文。任何情况下不得伪造 record_id（如 record_12345 / rec_abc 这类明显占位符都属于违规）。

R6. 怀疑自己时立刻坦白

如果 agent 在执行过程中出现任何以下信号，必须立刻停下来如实告诉用户，而不是继续往下演：

"我好像没有 HTTP 工具但不确定"
"我不确定这个 URL 对不对"
"我上一步是不是其实没真的发出请求"
"我是不是在凭印象回答"

坦白的标准句式：

"诚实说明：我在这一步没有真正执行 <动作>，原因是 <原因>。请您 <建议用户做的事>。"

R7. 输出纪律（只发用户该看到的内容，不暴露思考过程）

这是一次对外的报名问卷，用户想看到的是问卷消息本身，不是 agent 的工作日志。Agent 发给用户的每一条消息必须只包含该步骤对应的"对外内容"，禁止在聊天里暴露以下任何内容：

❌ "我先从 frontmatter 读取 promo_image_url……"/"我现在读第一节的开场白……"/"我去解析你给的内容……"
❌ "我去领一下 token……" / "我调用了 claimInvitation 接口……" / "根据 R2 我先做 Preflight……"
❌ "我判断这个图是不是幻觉" / "图片工具返回失败，我跳过它" / "这一步是可选的我就不做了"
❌ "根据 R4，我不能跳题" / "按照 SOP Step X..." —— 这些条款名只存在于本 skill 内部，严禁出现在用户可见的消息里
❌ "好的，我明白了" / "我会按以下步骤执行：1. ... 2. ..." —— 这种"朗读计划"式的废话
❌ "让我思考一下" / "首先" / "接下来我要做的是" —— 任何暴露内部推理顺序的连接词
❌ "解析出：称呼=X，公司=Y，手机=Z，保存到变量 nickname/organization/phone" —— 内部变量名不暴露；但可以用自然的口吻确认一次"好的，小王 / 腾讯 / 138xxxx 已记下"

正确做法：沉默执行工具调用和内部判断，只输出用户真正需要的消息：开场白模板、问题本身、澄清追问、清单确认、最终 record_id、或按 R1/R3/R6 要求的"诚实说明"话术。除此之外一律不发。

自检问题：发送每条消息前，agent 都要在内部问自己一句：

"这句话是用户填问卷需要看到的吗？还是我自己的工作记录？"

如果是后者，删掉。宁可消息短，不要加戏。

一、活动说明（开场白 · 每次触发都会原文发给用户）

Agent 在 Step 1 会把这段内容作为开场白，和第 1 题复合题拼在同一条消息一起发给用户（开场白末尾必须告知用户总共有 7 道题）。

⚠️ 发送形式（2.5.5 重大变更）：下面这段内容就是一段 markdown 消息（标题、加粗、引用、列表、emoji），agent 直接作为聊天消息发送即可，让前端渲染。严禁在整段外面再套一层三反引号 ``` 代码块——那会让前端当作 bash / shell 代码块高亮成灰底等宽"日志"视觉，彻底失去设计。

🐎 「马」上进化

Hermes-Agent × 腾讯轻量云极客沙龙

📅 活动时间　2026 年 4 月 25 日（周六）19:00 – 21:00
🚪 签到时间　同日 18:30 – 19:00
📍 活动地点　深圳华侨城创意文化园北区 C2 空间

Hermes Meetup Poster

✨ 这一场，来玩什么？

腾讯轻量云（Lighthouse） × Nous Research / Hermes Agent。

我们是第一个通过线下装龙虾引爆全球的云计算团队，也是在中国第一个把 Hermes-Agent 做成「一键部署模板」的云厂商。这一场，是 Hermes-Agent 在中国大陆的第一次官方 Meetup。

🎯 我们在找谁？

这不是一场泛 AI 围观活动，而是一场面向 Hermes Agent 玩家、开发者与实践者的线下交流。我们希望邀请真正上手过、部署过、做过玩法尝试的人来到现场，一起交流 memory / skills / 多代理协作以及基于 Lighthouse 的部署体验。

本次报名将结合实际使用经验进行审核，优先邀请有真实项目、真实玩法、真实踩坑经验的参与者。

📮 如报名成功，大会将通过短信的方式进行通知，烦请届时留意！

📋 本问卷共 7 道题，其中第 5、6、7 题选填，其余为必填。我会分三批发给您，方便逐步填写。

二、问卷题目清单

分批发送规则（详见第三节 SOP）：

第一批（第 1 题 · 合并复合题 · 必填）：开场白（含"共 7 道题"说明）+ 第 1 题（用户一条消息里给出称呼 / 公司 / 手机号，agent 后台拆成 3 个独立字段）

第二批（第 2-4 题 · 必填）：参与目的 / 是否部署过 / 轻友年限

第三批（第 5-7 题 · 3 选填）：项目经历（选填） / 踩坑经验（选填） / SOUL/"SBTI" 测试（选填，附链接）

⚠️ 对外题号 1-7，后台 payload 依然落库为 9 个独立字段（nickname / organization / phone 由前台第 1 题拆解而来）。

| 对外题号 | 字段 key（后台） | 题目 | 类型 | 必填 | 备注 / 校验 | |---------|------|------|------|------|------------| | 1（复合 · 含 3 项） | nickname | 如何称呼您或您的 Hermes Agent？ | 单行文本 | ✅ | 去除首尾空格；长度 ≤ 50；与公司、手机号合并在一道题里询问 | | 1（复合 · 含 3 项） | organization | 目前所在的公司 / 机构 / 学校？ | 单行文本 | ✅ | 长度 ≤ 100；提醒用户该信息会加密存储 | | 1（复合 · 含 3 项） | phone | 便于联系您的手机号 | 手机号 | ✅ | 中国大陆手机号正则：^1[3-9]\d{9}$；从用户回复里正则抽取，校验失败重新询问（只问手机号这一项） | | 2 | purpose | 报名这场活动最主要的目的是什么？（可多选） | 多选 | ✅ | 选项见下方；用户可回复数字/文字/组合 | | 3 | deployed_on_lighthouse | 是否在腾讯云上安装过 Hermes Agent？ | 单选 | ✅ | 选项：是 / 否 | | 4 | lighthouse_years | 您已经是几年轻友了？ | 单选 | ✅ | 选项：没用过轻量云 / 一年轻友 / 两年轻友 / 三年及以上轻友 | | 5 | project_story | 请描述一个您在实际用 Hermes Agent 完成过的项目、工作流或最有代表性的玩法 | 多行文本 | ❌ | 建议 100-300 字 | | 6 | pitfalls | 在使用 Hermes Agent 过程中遇到过哪些问题？您是如何解决的？ | 多行文本 | ❌ | 真实踩坑经验加分 | | 7 | soul_code | SOUL 测试，输入您的专属 SOUL或"SBTI" | 单行文本 | ❌ | 选填。可把测试链接 https://www.skillhub.cn/20260415/soultest.html 一并发给用户引导测试；用户随便填都接受，agent 不做任何格式校验（四字母 / 带连字符 / 中文描述 / 自然语言等均原样落库），也不得主动把用户回复归纳为"字段类型有误"；用户回复「跳过 / 无 / 不填」或直接不填 → 落库为空字符串 |

第 2 题的选项（purpose，多选）

1. 想认识更多 Hermes 玩家
2. 想看真实玩法和案例
3. 想交流部署与配置经验
4. 想展示自己的玩法或作品
5. 还在观望，想先了解 Hermes Agent
6. 其他

如果用户选择 "6. 其他"，agent 必须追问一句："方便简单说一下是什么目的吗？"，并把补充内容拼接在该字段末尾，格式：其他：用户补充内容。

第 3 题的选项（deployed_on_lighthouse，单选）

1. 是
2. 否

第 4 题的选项（lighthouse_years，单选）

1. 没用过轻量云
2. 一年轻友
3. 两年轻友
4. 三年及以上轻友

三、执行流程 SOP（Agent 必读，逐步执行）

Step 0 · 向后端领取一次性 token（必须在问第一题之前完成）

端点 A：领号接口（以下 URL 必须原样复制，禁止改写任何字符，参见 R0）

<!-- CLAIM_ENDPOINT_START -->
https://hermes-meetup-d9gnjt0lh351cbd34.service.tcloudbase.com/claimInvitation
<!-- CLAIM_ENDPOINT_END -->

Step 0.1 · HTTP 能力自检（遵循 R1）：在发任何请求之前，agent 先确认自己是否具备对外 HTTPS POST 能力。若没有，按 R1 的话术如实告诉用户并终止流程，严禁编造"域名解析失败"之类的假错误。

Step 0.2 · 请求前自检（遵循 R2）：Agent 必须先在脑内（或可选地对用户折叠展示）列出：

[Preflight · Step 0]
- method : POST
- url    : https://hermes-meetup-d9gnjt0lh351cbd34.service.tcloudbase.com/claimInvitation
- headers: Content-Type: application/json
- body   : {"event_code":"hermes-meetup-2026-04-25","client":{"agent":"<your-agent-name>","skill_version":"2.5.7"}}

核对 url 与本文件 CLAIM_ENDPOINT_START/END 之间一致后，再发起请求。

Step 0.3 · 发起请求：Agent 在朗读开场白之前，静默发起请求：

POST  <CLAIM_ENDPOINT>
Content-Type: application/json

{
  "event_code": "hermes-meetup-2026-04-25",
  "client": { "agent": "CodeBuddy", "skill_version": "2.5.7" }
}

成功响应（HTTP 200）：
```
{
  "code": 0,
  "data": {
    "token": "K3f9xQp2mN8vRa71WbE",
    "expires_at": "2026-04-21T18:00:00+08:00"
  }
}
```
→ 把 token 和 claim_time（当前本地时间戳）记到会话内存变量。不要把 token 展示给用户，这是后端技术细节。
失败响应（HTTP 429，IP 被限流）：
```
{ "code": 2001, "message": "rate_limited" }
```
→ agent 回复用户："当前访问过于频繁，请稍后再试（约 1 小时后）。" 然后直接结束会话，不开始问卷。
其他失败（遵循 R3）：必须原样展示 HTTP 状态码和 body 前 500 字符，不得自然语言归纳。标准话术：
"报名通道暂不可用，以下是后端返回的原始信息，请截图发给主办方：
```
[HTTP Result · claimInvitation]
status: <真实状态码>
body  : <真实 body 原文>
error : <若是网络错误则填底层异常原文>
```"
```
然后结束会话。禁止伪造 ENOTFOUND events.hermes-agent.com 之类的错误——本服务部署在 *.tcloudbase.com，其他域名一律不存在。

Step 1 · 开场白 + 第 1 题合并复合题（合并为一次发送）

关于活动宣传图（已嵌在开场白里，agent 不要另外折腾）：

开场白中已经以 markdown 图片语法 ![Hermes Meetup Poster](https://...) 内嵌了海报。支持 markdown 的聊天前端会渲染为图片，不支持的会显示为可点链接，两种情况对用户都足够。
关键：这段内容必须作为 markdown 消息发送，让前端渲染。如果 agent 把它当纯文本字面量直接抄写出去，用户看到的会是开头多出一个 ! 的原文（![Hermes ...），这就是渲染失败。
图片行前后必须各留一个空行（skill 里已经留好，照抄即可），很多 markdown 解析器要求图片独占一行且前后是空行，否则会退化成纯文本。
Agent 严禁做下列任何事：
- ❌ 另外调用"图片工具 / 视觉识别 / browse / screenshot / view_image"去拉这张图或给用户"预览"——完全不需要，markdown 语法已经把图送到用户那里了
- ❌ 向用户描述这张海报的内容（"这是一张深色背景的海报，上面写着..."）——用户自己能看，agent 描述反而啰嗦而且容易编造
- ❌ 因为"我这边没看到图"就道歉或解释——是否渲染取决于用户的前端，跟 agent 无关
- ❌ 把海报链接拆出来额外发一遍（例如再补一句"海报在这里：https://..."），已经在开场白里了不要重复
- ❌ 把 ! 去掉（试图"清理"看起来多余的感叹号）——这个 ! 是 markdown 图片语法的必需部分，去掉就只剩普通链接了
如果 agent 完全没有 markdown 渲染的概念、担心 ![](url) 这行在用户那边显示成原文 —— 照发就行，最差情况也只是用户看到一个可点的 URL 而已，不影响报名。

Step 0 成功后，在同一条消息里发送：开场白（第一节 markdown 内容，末尾已包含"本问卷共 7 道题"说明）+ 第 1 题合并复合题（前台只问一次，后台拆成 3 个独立字段）。

⚠️ 发送形式（2.5.5 重大变更）：开场白 + 第 1 题整条消息都是 markdown 原文，agent 直接作为聊天消息发送，让前端渲染成标题 / 引用 / 加粗 / 列表 / 图片。严禁在整段外面再套一层三反引号 ``` ——那会让前端当代码块高亮成灰底等宽"日志"视觉，彻底失去设计。

紧接开场白（末尾最后一条 --- 之后）追加下面这段 markdown 原文作为第 1 题：

📝 第 1 题 · 基本信息

我们先从第 1 题开始。这一题需要三项基本信息，请在一条消息里一并告诉我（顺序不限）：

如何称呼您或您的 Hermes Agent
目前所在的公司 / 机构 / 学校（该信息会加密存储）
便于联系您的手机号

💡 示例（任意一种都行，我会自动识别）：

小王，腾讯，13800138000
称呼：小王；公司：腾讯；手机：13800138000
我叫小王，在腾讯，手机 13800138000

同时开始计时（survey_start_time = 当前时间）。

Agent 解析规则（⚠️ 重要 · 后台依然拆成 nickname / organization / phone 三个字段）：

支持以下输入格式，agent 必须能鲁棒解析：
1. 逗号/顿号分隔：小王，腾讯，13800138000 / 小王、腾讯、13800138000
2. 键值对：称呼：小王；公司：腾讯；手机：13800138000（分隔符可以是 ：/:，行内可以用 ；/;/换行）
3. 自然语言：我叫小王，在腾讯工作，手机 13800138000 —— agent 自行从中抽取三项
4. 分行：用户分三行分别写三项
手机号识别：从回复中用正则 1[3-9]\d{9} 提取第一个中国大陆手机号
识别失败的单项处理（例如用户只回了称呼+公司没给手机号）：只追问缺失的那一项，格式 "好的，称呼和公司已记下。还需要您提供便于联系的手机号。"，不要让用户重填全部三项
手机号格式校验失败："您给的这个号码看起来不是 11 位手机号（^1[3-9]\d{9}$），请再给一下正确号码。"，最多重问 3 次
保存到内存变量：nickname、organization、phone 三个独立字段，不要合成一个大字符串
称呼去首尾空格，长度 ≤ 50；公司去首尾空格，长度 ≤ 100

三项信息全部收齐且手机号校验通过后，进入 Step 2。在构造 Step 5 payload 时，依然要拆成 answers.nickname / answers.organization / answers.phone 三个独立字段，云函数后端保持不变。

Step 2 · 第 2-4 题（合并为一次发送）

一次性发送第 2/3/4 三道必填题（开头必须告诉用户"这是第 2-4 题"，让用户清楚当前进度）。

⚠️ 发送形式（2.5.5）：下面这段是 markdown 原文，agent 直接作为聊天消息发送，不要再在外面套 ``` 代码块。

✅ 第 1 题的 3 项基本信息已收到。 这里是第 2-4 题，都是必填：

📝 第 2 题　报名这场活动最主要的目的是什么？

可多选，回复序号即可

① 想认识更多 Hermes 玩家
② 想看真实玩法和案例
③ 想交流部署与配置经验
④ 想展示自己的玩法或作品
⑤ 还在观望，想先了解 Hermes Agent
⑥ 其他（请补充说明）

📝 第 3 题　是否在腾讯云上安装过 Hermes Agent？

① 是
② 否

📝 第 4 题　您已经是几年轻友了？

① 没用过轻量云
② 一年轻友
③ 两年轻友
④ 三年及以上轻友

💬 请把三道题的答案一次性发给我，格式如：1，2，3；1；2

解析规则：

第 2 题（purpose）多选：用户输入 1,3 / ①③ / "想认识玩家、交流部署" 都要能解析成选项原文数组
第 2 题选了 "⑥ 其他"：需要补充说明，agent 追问"方便简单说一下是什么目的吗？"，把补充内容拼在末尾，格式 其他：用户补充内容
第 3/4 题（deployed_on_lighthouse / lighthouse_years）单选：用户输入 1 / ① / "是" 都要能映射到选项原文

全部校验通过后，进入 Step 3。

Step 3 · 第 5-7 题（3 选填 · 合并为一次发送）

一次性发送第 5/6/7 三道题（均为选填，第 7 题带测试链接引导），开头必须告诉用户"这是最后三题（第 5-7 题）"，且必须在消息里原样包含 SOUL 测试链接。

⚠️ 发送形式（2.5.5）：下面这段是 markdown 原文，agent 直接作为聊天消息发送，不要再在外面套 ``` 代码块。

✅ 第 2-4 题已收到。 这是最后三题（第 5-7 题），5、6、7 均为选填：

📝 第 5 题 (选填)　项目经历

请描述一个您在实际用 Hermes Agent 完成过的项目、工作流或最有代表性的玩法。

💡 建议 100-300 字，可以包含：

当时要解决什么问题
用了哪些 skills / memory / tools
最后得到什么结果

有真实项目 / 踩坑经验会显著提高通过率。如果暂时不想填，可以回复**「跳过」**。

📝 第 6 题 (选填)　踩坑经验

在使用 Hermes Agent 过程中遇到过哪些问题？您是如何解决的？

我们会优先邀请有真实项目、真实玩法、真实踩坑经验的参与者～如果暂时不想填，可以回复**「跳过」**。

📝 第 7 题 (选填)　SOUL 测试

输入您的专属 SOUL 或 "SBTI" 🧬

🔗 测试链接：https://www.skillhub.cn/20260415/soultest.html

如果方便，请点开上面的链接完成测试，拿到您的专属 SOUL 或 "SBTI" 后回来告诉我；如果暂时不想填，可以回复**「跳过」**。

分支处理：

用户针对第 5/6/7 题回复「跳过 / 无 / 不填」→ 对应字段记为空字符串
用户问"第 7 题能不能跳过？" → 明确告知："第 7 题是选填的，跳过也没关系；如果方便测一下，把 SOUL 或 "SBTI" 结果发给我就行。链接：https://www.skillhub.cn/20260415/soultest.html"
用户回答完 5/6 但没对 7 明确表态 → 追问一次："还有第 7 题（SOUL / "SBTI"），您想填写还是跳过？"并再次把链接发出来
用户回答完 7 但 5/6 没明确表态 → 追问一次："还有第 5、6 题，您想填写还是跳过？"
三题用户都明确"跳过"或给出值后，即可进入 Step 4

Step 4 · 清单确认

把 7 道题答案以清单形式回显给用户。第 1 题要展开成 3 小行，让用户明确看到 agent 解析出的称呼 / 公司 / 手机，方便发现错误。

⚠️ 发送形式（2.5.5）：下面这段是 markdown 原文，agent 直接作为聊天消息发送（把 xxx 替换成真实答案），不要再在外面套 ``` 代码块。

📋 请确认以下信息是否正确

1. 基本信息

称呼：xxx
公司 / 机构：xxx
手机号：1xxxxxxxxxx

2. 参与目的：xxx、xxx

3. 是否部署过 Hermes Agent：是 / 否

4. 轻友年限：一年轻友

5. 项目经历 (选填)：xxx　（或「未填写」）

6. 踩坑经验 (选填)：xxx　（或「未填写」）

7. SOUL / "SBTI" (选填)：xxx　（或「未填写」）

✅ 确认无误 → 回复「确认」或「提交」
✏️ 要修改 → 告诉我第几题
✏️ 改第 1 题里的某一项 → 说「改一下称呼」/「改手机号」，我只重问那一项

用户回复「确认」/「提交」/「ok」/「没问题」等肯定语 → 进入 Step 5
用户回复「修改第 X 题」→ 只重新问那一题，然后再次回显清单
用户说"改一下称呼/公司/手机号" → 只重问第 1 题里的对应子项，其他两项保持
用户补充了之前跳过的选填题（如"第 5 题我想补一下……" / "第 7 题我也想填一下 SOUL"）→ 接收后再次回显清单

Step 5 · 构造 payload 并上传

Step 5.0 · 前置校验（遵循 R4，必须全部通过才能进入 Step 5.1）：

✅ Step 0 是否真的收到过后端 200 响应并拿到 token？（否则禁止进入 Step 5）
✅ 6 个必填字段（nickname / organization / phone / purpose / deployed_on_lighthouse / lighthouse_years）是否全部非空？
✅ 是否经过 Step 4 的用户"确认/提交"表态？

任意一项为否 → 立刻返回对应 Step 补齐，禁止带空值或占位符提交。

Step 5.1 · 构造 payload：计算 duration_seconds = floor((当前时间 - survey_start_time) / 1000)，构造（注意 answers 里仍然是 9 个独立字段，前 3 个来自第 1 题复合题的拆解）：

{
  "token": "<Step 0 领到的 token>",
  "event_code": "hermes-meetup-2026-04-25",
  "submitted_at": "<ISO8601 本地时间>",
  "duration_seconds": 245,
  "answers": {
    "nickname": "...",
    "organization": "...",
    "phone": "...",
    "purpose": ["...", "..."],
    "deployed_on_lighthouse": "是",
    "lighthouse_years": "一年轻友",
    "project_story": "...",
    "pitfalls": "...",
    "soul_code": "ENTP"
  },
  "client": { "agent": "CodeBuddy", "skill_version": "2.5.7" }
}

POST 到端点 B：提交接口（以下 URL 必须原样复制，禁止改写，参见 R0）：

<!-- SUBMIT_ENDPOINT_START -->
https://hermes-meetup-d9gnjt0lh351cbd34.service.tcloudbase.com/submitMeetupSurvey
<!-- SUBMIT_ENDPOINT_END -->

Step 5.2 · 请求前自检（遵循 R2）：Agent 必须先列出并核对：

[Preflight · Step 5]
- method : POST
- url    : https://hermes-meetup-d9gnjt0lh351cbd34.service.tcloudbase.com/submitMeetupSurvey
- headers: Content-Type: application/json
- body   : <上一步构造的完整 JSON，隐去 token 的后半段>

关键核查点：url 字段必须与本文件 SUBMIT_ENDPOINT_START/END 锚点之间的字符串逐字符一致。如果 agent 此时脑子里浮现出任何其他域名（例如 events.hermes-agent.com / api.hermes.com / hermes.tencentcloud.com），这一定是幻觉，必须丢弃，回到本文件锚点重新复制。

Step 5.3 · 发起请求：

POST  <SUBMIT_ENDPOINT>
Content-Type: application/json

Step 6 · 结果反馈（严格遵循 R3 / R5）

前置硬约束：在对用户说"提交成功"之前，agent 必须在心里自问并确认——

我真的发出了 HTTP POST 请求吗？（而不是"我脑补了一下"）
我真的收到了后端的响应吗？
响应里的 record_id 是后端给的原文吗？（而不是我自己编的 record_12345）

三项任一存疑 → 按 R6 坦白，禁止谎报成功。

✅ HTTP 200 且 {"code": 0}：必须在回复里原样展示后端返回的 record_id：

✅ 报名信息已提交成功！提交编号：<response.data.record_id 原文>

📮 如报名成功，大会将通过短信的方式进行通知，烦请届时留意！
⚠️ 返回 {"code": 3001, "message": "token_invalid_or_expired"}：

⚠️ 报名时效已过，请重新发起报名流程。
⚠️ 其他失败（遵循 R3）：必须原样展示 HTTP 状态码 + body 原文，禁止自然语言归纳：
⚠️ 提交失败，以下是后端返回的原始信息：
```
[HTTP Result · submitMeetupSurvey]
status : <真实 HTTP 状态码>
body   : <真实 body 原文，前 500 字>
error  : <若是网络错误则填底层异常原文>
```
请截图连同以下 payload（隐去 token）一起发给主办方手动登记：
```
<完整 payload，token 字段替换为 "***">
```

Step 7 · 结束

提交完成后不再主动提问。同一会话内不允许重复提交（token 已核销）。若用户要求再填一次：

你本次报名已提交。如需修改信息，请重新发起对话（将会分配新的一次编辑窗口）。

四、边界与安全

Token 不得展示：agent 在对话中任何时候都不要把 token 内容展示给用户——它是技术字段。
不保存到本地：除会话内存外，agent 不得把用户答案或 token 写入磁盘。
手机号只在上传时使用：回显确认时可展示，对话结束后不得主动引用。
拒绝越权代填：用户要求 agent 代他人报名时，明确告知"每人需自己填写，以便留真实联系方式"。
同会话不重填：Step 6 已说明。

五、给主办方的说明（非 Agent 可执行区）

对外 7 道题 / 后台 9 字段：第 1 题是一道合并复合题（用户感知"一题答 3 项"），但云函数和数据库仍然落库为 nickname / organization / phone 三个独立字段。导出 CSV 的时候会看到 9 列完整答案。
导出数据：CloudBase 控制台 → 数据库 → meetup_surveys 集合 → 导出 JSON/CSV
可疑数据筛查：按 suspicion_score 降序排列，优先 review 分数高的
问卷题目如需修改，改本文件「二、问卷题目」即可；agent 下次读到就会按新版问
调整限流策略：修改 claimInvitation 云函数内的常量（默认每 IP 每小时 10 token、每天 50 token。命中限流时 429 响应体含 scope / limit / current / retry_after_seconds / ip 诊断字段）