夜雨聆风一次零代码变更的版本升级，却修掉了一个可能让「踢人」变成「留人」的致命隐患。 在 Agent 时代，"改文档"本身就是改产品。
一、这可能是你见过最"反直觉"的版本更新
打开腾讯会议 MCP Skill v1.0.13，对比前一个版本 v1.0.12，很多人第一反应会是失望：
工具数量：27 个，一个没多
核心脚本tencent_meeting.py：一个字节没改
主控文件SKILL.md：MD5 完全一致
API 参考文档：从 1151 行砍到 713 行，少了整整 438 行
功能没加，文档还变薄了——这版本更新了个啥？分明是偷工减料啊！
如果你曾经做过 AI Agent 开发，就会深深地懂得对于 Skill 这类产品，文档不是说明书，文档就是源代码。模型读到什么，就会做什么。一句写反的参数说明，等价于线上一个逻辑取反的 Bug。
而 v1.0.13，恰恰修掉了这样一个 Bug。
二、版本概述：到底动了哪里
我们对两个版本做了逐文件哈希比对，结果非常干净：
SKILL.md | ||
scripts/tencent_meeting.py | ||
references/error_dictionary.md | ||
references/feedback_rules.md | ||
references/privacy_policy.md | ||
references/version_management.md | ||
config.json | v1.0.12v1.0.13 | |
references/api_references.md |
结论先行：v1.0.13 是一次纯知识库（Knowledge Base）优化版本。服务端接口地址baseUrl未变，27 个业务工具的能力边界未变，升级不存在任何兼容性风险。
所有的价值，都浓缩在api_references.md这一个文件的四处改动里。
三、主要功能变化：四处改动，两处是硬修复
🔴 改动一：修正 allow_rejoin 语义写反（最高优先级）
这是本次更新最值得升级的理由，没有之一。
meeting_control_kick（踢出会议成员）是一个典型的破坏性操作，其中allow_rejoin参数决定被踢的人还能不能再进来。我们看两个版本的说明：
v1.0.12：
- allow_rejoin 默认true（不允许重新加入），必须向用户明确确认取值v1.0.13（修正后）：
- allow_rejoin 传false（不允许重新加入）；传true表示允许被踢者重新加入。必须向用户明确确认取值true在英文里明明是"允许重新加入"（allow rejoin = true），旧文档却标注成"不允许重新加入"。更糟的是，旧版所有 4 个代码示例清一色写着"allow_rejoin": true——一个读文档的 AI Agent，很可能得出这样的错误认知：
"用户说要把这个人踢出去别让他再进来 → 文档说 true 是不允许重新加入 → 那我传 true。"
实际结果：这个人被踢出去了，然后转头就能重新进会。用户以为问题解决了，其实没有。而且这类失败是"静默"的——接口返回成功，谁也不会立刻发现。
v1.0.13 把语义彻底摆正，并且明确了"传false才是不允许重新加入"。如果你的 Agent 会用到会中控制能力，这一条就足够构成立即升级的理由。
🔴 改动二：修复目录锚点断链
旧版本api_references.md的标题编号存在明显的序号错乱：
17. search_transcripts ← 17 号18. get_smart_minutes ← 18 号17. apply_record_permission_prepare ← ⚠️ 又一个 17 号18. apply_record_permission_commit ← ⚠️ 又一个 18 号
序号 17、18 各自出现了两次。与之对应的，目录里的锚点链接也跟着错：
- [搜索会议列表](#11-search_meetings--搜索会议列表)- [查询录制列表](#11-get_records_list--查询录制列表) ← ⚠️ 同样是#11
而get_records_list的实际标题是
12.，这个目录链接指向了一个不存在的锚点，点击直接失效。
v1.0.13 的解法很干脆——把序号全删了：
schedule_meeting — 创建会议update_meeting — 修改会议
锚点相应变成#schedule_meeting--创建会议。这一改动带来三个好处：
✅锚点唯一且稳定，不会再有重复和断链
✅锚点即工具名，模型定位工具文档更直接
✅未来增删工具无需重排全表序号，从根源上杜绝了这类错误复发
🟢 改动三：示例瘦身，转向"单一事实来源"
这是 438 行缩减的主要来源。
旧版对每个工具都堆砌了大量 bash 调用示例，比如get_meeting这种只有一个参数的工具，也要占掉 10 行：
python3 scripts/tencent_meeting.py tools/call '{ "name": "get_meeting", "arguments": { "meeting_id": "xxx" }}'新版统一替换为一句话：
参数以 MCP schema 为准（
tools/list）。
看着"信息量变少了"，实则是一次架构层面的正确取舍——遵循SSOT（Single Source of Truth，单一事实来源）原则：
被简化的工具包括get_meeting、get_meeting_by_code、get_meeting_invitees、get_waiting_room、get_record_addresses、get_transcripts_paragraphs、search_transcripts、contact_lookup_by_phone/_by_email、meeting_invitees_add/_remove等十余个。
关键在于：删掉的都是"模型本来就能从 schema 拿到"的信息，留下的都是"schema 里没有、只能靠文档传递"的知识。这才是这次瘦身的精髓。
🟢 改动四：补上 schema 表达不了的关键约束
省下来的篇幅，全部投入到了高价值约束说明上。新版新增了一批用>引用块标注的硬性规则：
①search_meetings— 明确检索字段与上限
q_fields取值：subject（主题，分词匹配）/creator（创建人昵称，模糊匹配）/note（备注，模糊匹配）/all（所有字段）。page_size上限 30。
②get_records_list— 三种查询模式互斥（新增）
三种查询模式互斥：
start_time + end_time（时间跨度 ≤ 31 天，可翻页）/meeting_id（无需时间）/meeting_code（无需时间）。同一次调用只使用其中一种。
这是一条 JSON Schema根本无法表达的业务约束。旧版只能靠三段示例让模型自己"悟"，新版直接把规则写死——≤ 31 天的时间跨度限制更是踩坑高发区。
③search_records— 揭示 snippet 返回行为差异（新增）
q_fields取值分为两类，snippet 返回行为不同：
返回 snippet： transcript_content（转写原文）/smart_minutes（智能纪要）/timeline（时间轴）不返回 snippet： subject（主题）/creator（创建人昵称）/all（所有字段）
这条极其实用。用户问"帮我找找上周会议里提到预算的那段话"，模型必须知道只有搜转写原文才会返回命中片段，否则搜完subject拿到一堆没有上下文的标题，还得再发一轮请求。
④get_transcripts_details— 点破类型陷阱（新增）
pid为字符串型起始段落号（首页传"0"），limit为数字型。
一个是字符串"0"，一个是数字 —— 同一个接口里两种类型，不写清楚必然报参数错误。
⑤get_smart_minutes— 补齐可选参数（新增）
可选
lang（默认default原文，可传en等指定翻译语言）与pwd（录制文件访问密码，仅当录制设置了密码时需要）。
⑥ 分页范式全局统一
旧版每个支持分页的工具都要贴一段"翻页查询"示例，新版统一压缩成一行心法：
分页接续：首次不传
page_token；响应has_more=true时，将next_page_token回填继续翻页
一次讲透，处处适用。
四、增强特性详解：从"给模型看的说明书"到"给模型用的决策表"
把四处改动串起来看，v1.0.13 传递出一个清晰的设计思路转变：
v1.0.12 思路：尽可能多地提供示例，让模型照葫芦画瓢↓v1.0.13 思路：示例交给 schema，文档只负责讲清「schema 讲不清的事」
什么是 schema 讲不清的事？
get_records_list | ||
page_size ≤ 30、踢人总数 ≤ 20 | ||
allow_rejoin | ||
instanceid 把成员分派到 users/sip_users/pstn_users |
这份文档正在从「API 说明书」进化成「Agent 决策表」。它不再教模型"怎么拼参数"（那是 schema 的活儿），而是告诉模型"什么时候该用哪个、什么情况会翻车"。
对于 Skill 开发者，这里有一条可以直接抄走的经验：
判断一段文档该不该留，标准只有一个——模型能否从
tools/list自己拿到？能拿到的，删掉；拿不到的，加粗写清楚。
五、升级建议：谁该升，急不急
✅ 强烈建议立即升级
用到会中控制（踢人）能力的团队——allow_rejoin语义修复直接关系到操作正确性，这是安全级别的修复
重度使用录制检索、转写搜索的团队—— 新增的q_fields/ snippet 行为说明能显著减少无效调用和来回试错
对 token 成本敏感的场景—— 文档瘦身 38%，每次会话都在省钱
🆗 可从容升级
只用基础排会、查会议详情的轻量用户：核心能力毫无变化，但既然是零风险，顺手升了更省心
⚠️ 风险评估：零风险
baseUrl 一致） | |
换句话说，这是一次纯收益、无成本的升级。
六、升级指引：三步搞定
腾讯会议 MCP Skill 内置了完整的版本管理机制，你几乎不需要手动操作。
方式一：跟着提示走（推荐）
服务端会校验请求头中的X-Skill-Version。当检测到你的版本落后时，会随业务响应一起返回更新提示（注意：只提示，不拦截业务请求，不影响正常使用）。
收到提示后，Agent 会向你展示四个选项：
懒人方案：直接选「以后自动更新」，一劳永逸。
方式二：主动检查
直接让你的 Agent 调用check_skill_version工具，即可查询当前版本状态并获取安装地址。
方式三：确认是否升级成功
打开 Skill 安装目录下的config.json，确认版本号：
{"name":"tencent-meeting-mcp","version":"v1.0.13","baseUrl":"https://mcp.meeting.tencent.com/mcp/wemeet-open/v1"}
看到v1.0.13就说明已经到位了。
💡 小提示：安装完成后建议开启一个新会话，确保新版文档被完整加载进上下文。
七、结语：Agent 时代，文档就是产品的一部分
传统软件里，我们习惯把文档当成代码的附属品——代码是主角，文档是配角，写错了顶多让其他开发者骂两句。
但在 AI Agent 的世界里，这个关系被彻底颠覆了：
模型不去读源码，而是直接读你的文档。文档写错一个词，模型的行为就错一整条链路。
腾讯会议 MCP v1.0.13 没有加一个新工具、没有改一行脚本，但它把一个写反的allow_rejoin掰正了，把一堆断掉的锚点接上了，把 schema 讲不清的业务约束补齐了，还顺手把上下文瘦身了 38%。
这不是一次"没什么内容"的版本，这是一次真正意义上的质量修复。
如果你正在做 MCP Skill 或者任何形式的 Agent 能力封装，v1.0.13 的这次重构值得反复品味——它示范了一件事：
与其教模型一百个正确的例子，不如告诉它十个会翻车的地方。
📌 一句话总结
v1.0.13 = 零代码变更 + 修正 1 个高危语义错误 + 修复目录断链 + 补齐 6 类关键约束 + 文档瘦身 38%，零风险，建议直接升。
本文基于 v1.0.12 与 v1.0.13 安装目录的逐文件哈希比对与全量 diff 分析撰写，所有结论均来自实际文件内容。