这条要区分「活动 ID」和「作品的 trainingCampId」——展览馆发布作品时接口要的是后者，拿错了会一直报参数错误。1. 展览馆的活动 ID 就是 trainingCampId发布作品走的接口是 POST /open-api-public/v1/gallery/works，表单里除了 workName、introduction、gitUrl，还有一个必填项 trainingCampId。这个值形如 47d6ba99-fca0-4797-947d-a8776f506df1（UUID），不是活动页地址里的数字 ID。2. 三个地方能拿到它- 在工作台点「发布作品」，打开浏览器 F12 → Network，筛 works，看提交请求的表单字段，trainingCampId 就在里面；- 从展览馆的活动页进「发布作品」，页面路由或 URL 的 query 里一般带 camp 或 trainingCampId；- 已经发布过作品的话，编辑作品时同一个字段会回填，直接复制即可。3. 码道（CodeArts）这边取不到的原因码道是 IDE/代码智能体，它没有展览馆的会话态。展览馆要求在登录态下用最小权限 STS 凭证调用接口，而码道进程里既没有浏览器 cookie，也没有 STS token，所以它「取不到活动 ID」是正常的——不是配置问题。正确做法是在浏览器里完成发布，或在码道里用你自己的 AK/SK 换 STS 后再调接口。4. 顺带提醒两个高频报错- GALLERY.PARAM.MISSING / 缺少最小权限 STS 临时凭证：说明没带 STS 三件套（X-Tmp-Ak / X-Tmp-Sk / X-Security-Token），不是 trainingCampId 的问题；- 400 参数错误但其实已经落库：发布接口偶发这个行为，重试前先查同名作品，否则会撞 GALLERY.WORK.DUPLICATE。一句话：活动 ID 指 trainingCampId，从发布页的请求体里抄，别用活动页 URL 里的数字 ID。

昇腾 910B 的监控分三层，先确认哪一层没数据，否则容易在错的地方折腾。第一层：驱动层能不能出数npu-smi info -t health -i 0 # 健康状态npu-smi info watch -i 0 -d 1 # 每秒刷新，看 AICore 利用率如果 npu-smi 报设备找不到或 driver 相关错误，问题在驱动不在监控：检查 davinci、npu_peermem 内核模块是否加载；容器里必须挂 /dev/davinci*、/dev/davinci_manager、/dev/devmm_svm，镜像内 CANN 版本还要与宿主机驱动匹配。第二层：采集层怎么拿数据- 单机排障用 npu-smi 就够，盯 AICore 利用率、HBM 显存、温度、功耗四个指标；- 集群监控用 msnpureport -f 导出运行日志，或部署 npu-exporter 对接 Prometheus。exporter 一般以 DaemonSet 跑在每台昇腾节点上，需要 hostPath 挂 /dev 与 /usr/local/Ascend，否则读不到设备。第三层：看板盯哪几条- AICore 利用率：区分算力瓶颈还是访存瓶颈；- HBM 使用率与分配失败次数：显存泄漏最直接的信号；- 温度与降频：超阈值掉频时表现为训练变慢但吞吐不明显下降；- PCIe/NVLink 带宽：多卡训练常见瓶颈。几个常见误区：1. 把 npu-smi 的显存占用当成进程级数据——它是设备级统计，容器共享时互相干扰；2. 只看 AICore 高就判断是算力瓶颈，实际常是数据加载或 H2D 拷贝卡住；3. 拿 nvidia-smi 的经验套过来，昇腾没有等价的按进程任务级查询，多进程要靠 msnpureport 或框架 profiler 区分。建议先用 npu-smi watch 抓一条真实负载曲线，再决定要不要上 Prometheus。

积分问题基本分三类，按这个顺序查能省掉大部分来回。1. 先看积分明细，不要只看总积分成长中心 → 我的积分旁「积分明细」，会逐条列出"来源 / 类型 / 积分 / 剩余积分 / 时间"。- 明细里有记录但总积分没变：前端缓存，刷新或换无痕窗口再看；- 明细里没有这条：任务没结算，往下查任务卡。2. 再看任务卡状态卡片显示「已完成」才是任务层面认可；显示「去完成」说明平台没把动作计入，常见原因：- 动作做了但没触发结算点（比如只保存了草稿、只报名没提交作品、只发布没勾选声明）；- 任务有周期限制：展览馆发布作品已改为**月度任务**，当月第二次发布不再给分；每日/每周任务有各自的重置时间；- 内容需审核：文章、作品要过审核才结算，审核期间明细里不会出现。3. 最后看延迟结算通常有延迟，从几分钟到几小时都有，跨天任务（比如昨天的 23:59 提交）可能要等日切。判断方法是对照明细里的时间戳，如果同类任务历史记录都是几小时内到账，那这次多半也只是延迟。4. 需要提工单时给什么- 账号（不用给密码）：UID 或账号名；- 任务名称 + 完成时间（精确到分钟）；- 明细截图（含时间戳，证明这条没有记录）；- 如果是作品/文章类：作品链接或文章链接。有这些信息工单基本一次就能定位。缺时间戳的话，客服也只能让你"再等等"。补充一句：任务卡与积分是两套数据，任务卡翻「已完成」但积分没加的情况偶尔会出现，以积分明细为准。

910B 的监控分三层，先确认哪一层没有数据，否则很容易在错的地方折腾。1. 驱动/固件层：npu-smi 能不能出数npu-smi info # 卡列表、温度、功耗、显存占用npu-smi info -t health -i 0 # 健康状态npu-smi info watch -i 0 -d 1 # 每秒刷新，看 AICore 利用率如果 npu-smi 直接报 "call drvMngGetConsoleLogLevel failed" 或找不到设备，问题在驱动，不是监控：检查 npu_peermem、davinci 内核模块是否加载，容器里要挂 /dev/davinci*、/dev/davinci_manager、/dev/devmm_svm 这些设备节点，且镜像内的 CANN 版本要与宿主机驱动匹配。2. 采集层：拿什么数据、放哪去- 单机排障：npu-smi 就够，重点看 AICore 利用率、HBM 显存、温度、功耗四个指标；- 集群监控：用 msnpureport 抓运行日志（msnpureport -f 导出），或部署 npu-exporter 把指标吐给 Prometheus。注意 exporter 通常以 DaemonSet 部署在每台昇腾节点上，需要 hostPath 挂 /dev 与 /usr/local/Ascend，否则读不到设备。3. 指标层：看板要盯的几条- AICore 利用率（区分计算/内存带宽瓶颈）；- HBM 使用率与分配失败次数（显存泄漏最直观的信号）；- 温度与降频（超过阈值会掉频，表现为"训练变慢但吞吐没降"）；- PCIe/NVLink 带宽（多卡通信训练里常见瓶颈）。4. 常见误区- 把 npu-smi 的显存占用当成"进程占用"：它是设备级统计，容器共享时会互相干扰；- 只看 AICore 利用率判断瓶颈：利用率高但吞吐低，往往是数据加载或 H2D 拷贝卡住；- 用 GPU 的 nvidia-smi 思路套昇腾：昇腾没有等价的任务级查询，多进程场景要靠 msnpureport 或框架侧的 profiler 区分子进程。建议先用 npu-smi watch 抓到一次真实负载曲线，再决定要不要上 Prometheus，别一上来就搭全套监控。

这篇侧重"上下文在哪一层传递"，和纯讲职责划分的角度互补一下。1. 协议层：initialize 决定后面怎么传连接建立后先 initialize，双方交换 protocolVersion 与 capabilities。这一步决定了能用哪些能力：服务端声明支持 resources 才能读文件，声明支持 sampling 才能反向请求模型，声明支持 notifications 才能推进度。没协商过的能力，后面调用直接报错，所以"传不过去"有时不是代码 bug，是能力没声明。2. 会话层：上下文靠 session 关联，不靠一次塞满每次请求带 session 标识，长任务用 notifications/progress 与 notifications/cancelled 成对传递进度和取消。也就是说上下文是**请求-通知对**持续累积出来的，不是把全部历史一次性放进 prompt。这样做的直接好处是：客户端可以随时压缩本地历史，而不破坏服务端的资源句柄。3. 资源层：用 URI 引用，不要复制内容resources/list 拿到的是 URI 清单（file:// 、db:// 、自定义 scheme），resources/read 才真正取内容，并且支持分页。把"引用"和"内容"分开有三个实际收益：- token 消耗可控，只在需要时读；- 可以做缓存与失效判断（同一 URI 内容未变就不重复读）；- 权限校验落在 read 上，比在 tool 参数里塞内容好审计。4. 大上下文怎么控- tool 返回值精简：只回结构化字段，不要把整个 HTTP body 原样返回；- 历史压缩时保留"工具调用的输入输出摘要"，丢掉原始大文本；- 长文档走 resources 分页，而不是一次性进 prompt。5. 传输方式影响上下文设计stdio 传输是单进程管道，天然一对一，上下文可以放在进程内存；HTTP+SSE 是无状态传输，必须在每次请求里携带会话状态或引用，所以要小心"内存里存了个上下文但请求打到了另一个实例"这类问题——多副本部署时上下文必须外置（Redis/DB），否则表现为"偶尔丢上文"。一句话：MCP 把上下文拆成协议能力、会话关联、资源引用三层，分别由不同机制承载。搞清哪一层丢了，比笼统地说"上下文没传过去"有用得多。

结论对：EIP 解绑不等于不收费，只要没释放就继续计费。但费用构成要说清楚，否则优化方向会错。1. 两笔费用要分开看- IP 保有费（未绑定也会收）：按小时计费，单价低于绑定状态，但长期闲置会一直扣；- 带宽/流量费：只有绑定了实例、并且实际有流量时才产生。解绑后这部分停止，只剩保有费。所以"解绑后账单没降到 0"是正常的，降的是带宽那边，保有费还在。2. 计费模式影响很大- 按需计费（按带宽）：绑定时按带宽档位收，解绑后转为保有费；- 按需计费（按流量）：有流量才计费，闲置成本低，但突发流量贵；- 包年/包月：订购周期内无论绑不绑定都不退，解绑不会省钱，只能等周期结束。长期闲置的 EIP，正确动作不是解绑，而是**释放**（控制台 → 弹性公网IP → 更多 → 释放）。释放后 IP 会回收到池子里，可能再也拿不回来，如果这个 IP 在别处有白名单要提前迁移。3. 怎么确认到底扣了什么费用中心 → 账单 → 明细账单，按"产品=弹性公网IP"筛，能看到每小时的保有费记录；也可以用资源账单里的"未绑定EIP"标签快速盘点闲置资源。4. 顺手做两件事- 给账号设一条"闲置 EIP"检查：控制台资源列表筛选状态为未绑定，按月清理；- 如果只是临时保留 IP（比如等新机器），评估保有费和重新申请的成本，多数情况下释放再买更划算。

单线程还能快，是因为它把"并发"这件事从线程换成了事件循环。补充几个常被忽略的点。1. 快在哪里，其实只有三条- 纯内存操作：一次 GET/SET 是内存读改写，没有磁盘 IO；- 事件循环 + epoll：单线程用 IO 多路复用轮询就绪的 socket，避免每连接一线程的栈开销和上下文切换；- 数据结构是专门设计的：SDS、跳表、压缩列表、listpack 都是为了常数级或对数级操作，没有"顺手遍历全表"这种隐式成本。注意最后一条：单线程省掉的是锁竞争，不是"并发安全"。因为根本不存在并行执行，所有命令天然串行，所以才有原子的单命令和 Lua 脚本。2. 一条慢命令就能拖垮全实例这是单线程最真实的风险。KEYS *、大 key 的 HGETALL、SMEMBERS、对百万元素的集合做 ZUNIONSTORE，都会把事件循环卡住，期间所有请求排队。排查手段：redis-cli --latency # 看基线延迟redis-cli --bigkeys # 找大 keySLOWLOG GET 10 # 看慢命令redis-cli --intrinsic-latency 100 # 排除自身机器抖动线上更稳的做法是用 SCAN 代替 KEYS，大 key 拆分成 hash 分片，删除大 key 用 UNLINK 而非 DEL。3. 6.0 之后的多线程只是"搬运"Redis 6.0 的 io-threads 把 socket 读写、协议解析分散到多个线程，但命令执行仍然是单线程。所以它提升的是高并发下的网络吞吐，不会让单条慢命令变快。别指望开 io-threads 解决 bigkey 问题。4. fork 与持久化的隐藏成本RDB/AOF rewrite 需要 fork，fork 时复制页表，内存越大耗时越长；开了 THP（透明大页）会让 COW 复制放大，延迟尖刺更明显。生产上建议关闭 THP，并把实例内存控制在合理范围，而不是无限扩。5. 什么场景不该用它做主力需要复杂事务、跨 key 强一致计算、超大集合运算时，Redis 单线程会成为瓶颈，此时应在应用侧分片，或者把这些计算放到下游服务里做，Redis 只当缓存。

分区不是"性能开关"，用对了省 IO，用错了反而更慢。补几个容易忽略的点。1. 分区裁剪成立的前提只有 WHERE 条件里直接出现分区键，优化器才能裁掉无关分区。写成 YEAR(create_time)=2026 或 DATE(create_time)='2026-10-01' 会让裁剪失效，变成扫全部分区：-- 裁剪失效WHERE YEAR(create_time) = 2026-- 裁剪生效WHERE create_time >= '2026-01-01' AND create_time '2027-01-01'EXPLAIN 里看 partitions 列，只出现目标分区才算真的裁剪了。2. 主键与唯一键必须包含分区键MySQL 要求分区表上每个唯一索引（含主键）都必须包含分区列。也就是说 (id) 做主键、按 create_time 分区是不允许的，得改成 (id, create_time)。这一步在已有大表上做等于重建表，规划阶段就要定下来。3. 删历史数据用 DROP PARTITION，不要 DELETEDELETE 一年数据会写大量 undo、产生 binlog、还可能锁表；DROP PARTITION 是元数据操作，秒级完成、几乎不产生 binlog。这是分区最实在的收益——不是为了查得快，是为了删得快。4. 分区数不是越多越好每个分区一套元数据和打开的文件句柄，几百上千个分区会让打开表变慢、DDL 更难。按天分区只适合保留期很短的场景，长期存历史的按月或按季度更稳。5. 分区表的代价跨分区查询不会并行执行（MySQL 分区是逻辑拆分，不是并行扫描）；分区表不支持外键；ALGORITHM=INPLACE 能做的 DDL 更少。所以它替代的是"分表"，不是替代索引。一句话：分区解决的是单表数据量过大导致的维护困难和范围查询 IO，索引与 SQL 质量仍然是第一位的。

规格选型的核心不是"哪款便宜"，而是先算清楚这台机器要扛的是哪一类资源，再去挑对应的规格族。做法我一般分四步。1. 先给负载定性- CPU 密集（编译、转码、加解密、Java 应用）：看主频和 vCPU 数，不看内存；- 内存密集（Redis、ES、JVM 大堆）：看内存/vCPU 比值，通常 1:4 到 1:8；- IO 密集（数据库、日志）：看云盘的 IOPS 和吞吐上限，规格本身反而次要；- 网络密集（网关、代理）：看内网带宽和 PPS 上限，小规格常常卡在这里。2. 云服务器规格族的对应关系（华为云为例）- 通用型 s 系列：1:2 或 1:4，Web 前端、中小应用；- 计算型 c 系列：1:2，高主频，适合计算密集；- 内存型 m 系列：1:8，缓存、大数据；- 磁盘增强/本地盘型 d 系列：高 IOPS 场景；- 网络增强型：高 PPS，转发类业务。3. 拿真实数据反推先在 2C4G 上跑压测，采集：top -bn1 | head -20vmstat 1 10 # 看 us/sy/wa、上下文切换iostat -x 1 5 # 看 %util、awaitsar -n DEV 1 5 # 看网卡带宽是否打满如果 %sy 高、%wa 高而 %us 很低，加 CPU 是浪费钱；如果 load 高但 CPU 不满，大概率卡在 IO 或锁上，加核无效。4. 算成本，不要只看单价同样的钱，2 台 2C4G 通常比 1 台 4C8G 更能扛住单机故障；但要注意跨可用区、带宽和云盘费用往往比 CPU 更贵。实践里最省钱的动作通常是：- 先按峰值 70% 选规格，留 30% 余量；- 配合弹性伸缩应对周期性高峰，而不是常年按峰值付费；- 用按需先跑一周出真实曲线，再转包年包月。一个反例：把 8C16G 换成 4C8G 却把云盘从超高 IO 降到普通 IO，数据库 QPS 掉一半——瓶颈从来不在 CPU 上，这种"降配"是负优化。

MCP（Model Context Protocol）里的上下文传递，核心是"谁负责维护上下文"这件事被明确划分了，不走"每次把全量历史重塞给模型"这条路。1. 三段上下文，边界很清楚- 客户端（宿主）持有会话状态：对话历史、用户身份、权限；- 服务端（MCP Server）持有资源上下文：文件、数据库、API 句柄；- 模型只看到本次请求里被显式放进去的内容。关键点是：MCP Server 不保存对话历史，它只暴露能力和资源。历史由客户端管理，这避免了服务端成为有状态瓶颈，也让同一个 Server 能被多个客户端复用。2. 传递机制有四种，别混用- tools/list + tools/call：能力发现与调用，参数由模型生成，上下文靠参数显式传入；- resources/list + resources/read：只读上下文，最适合放"长文档、配置、日志"，用 URI 引用而不是把内容塞进 prompt；- prompts：预置提示词模板，由服务端提供、客户端取用；- sampling：服务端反向请求客户端代为调用模型，上下文仍然留在客户端侧。实践中最常见的误区是把大段上下文直接拼进 tool 参数里。正确做法是让 Server 返回一个 resource URI（比如 file:///logs/app.log#L100-L200），客户端按需读取——这样 token 消耗可控，也能做缓存和权限校验。3. 会话与关联initialize 阶段协商协议版本和 capabilities，之后每次请求带 session 标识；进度、取消都通过 notification 传递（notifications/progress、notifications/cancelled）。所以长任务的上下文不是"一次传完"，而是靠请求-通知对持续关联起来的。4. 上下文长度怎么控- 用 resources 做分页读取，按需拉取；- 工具返回值尽量结构化、字段精简，别把整个 HTTP 响应体原样回传；- 客户端侧做历史压缩时，保留工具调用的输入输出摘要，不保留原始大文本。一句话：MCP 不谈"上下文窗口怎么塞满"，它谈的是"上下文存在哪里、按什么协议取"。把这条分清，长会话就不会越跑越贵。