2026-09-24 工作日志

物码早会

围绕物码项目主计划修订、卡券业务联调、数据监控分析、调拨延迟评估及集成测试卡点同步进展与待办。

小结

1. 项目整体进度与计划调整

• 修订版主计划：晓娜、马奇当天完成主计划修订版调整，依据为最新计划征集项及方中心要求。
• 统一发布：各端在修订版上完成调整后无需自行发布，统一检查后再整体发布。

2. 卡券业务联调

• 要点：市场部已完成卡券部分修改，项目团队下午 1:30 配合联调，完成整体场景闭环；宝仟负责拉起联调日程，并通知任杰等相关人员参与。

3. 数据监控与排期

• 方案排期已确认：各端正推动数据方案排期并开展开发。
• 监控数据分析：暂无最新监控数据，今日重点查看第 10 条历史数据，并与建新共同评估分析原因。

4. 调拨延迟问题

• 扫码出库状态延迟：扫码出库调用接口修改状态存在 10 分钟延迟，需活动中心进一步评估方案。
• 排期确认：已确定方案的第 9 条调拨问题，今日需确认排期安排。

5. 集成测试卡点

• SFA 前端：修改方案一直未给出排期，需明确后续排期安排。
• 活动中心盘点任务：涉及人员职位逻辑调整，需南林、明飞整体梳理方案并给出排期；活动中心先确定状态方案后再配合。

6. 测试问题与智慧门店短信跳转

• 测试问题：昨日测试出的问题，建新协助查看解决方案，相关人员下来沟通确认排期。
• 短信跳转测试：智慧门店短期短信到期提醒跳转钱包 H5 目前挂接生产环境链接，测试环境暂不具备条件；王琪、余建新下来对接确认测试环境及解决方案。

待办

1. 计划与联调

• 当天完成主计划修订版的调整工作。——晓娜、马奇
• 下午 1:30 配合市场部完成卡券业务联调闭环。——宝仟

2. 数据与问题跟进

• 查看第 10 条历史监控数据，并与建新共同评估分析原因。——郑然、建新
• 确认第 9 条调拨问题的排期安排。——刘晓娜
• 整体梳理人员职位逻辑方案并给出排期。——南林、明飞
• 协助查看测试问题的解决方案。——建新
• 对接确认智慧门店短信跳转问题的测试环境及解决方案。——王琪、余建新

计费管理工作量评估（个人交付）

小结

• 评估结果：计费管理工作量原评估 43 天，评估后 36 天，核减 7 天。

智能体接入方案研讨

发言人：王帅龙、刘振源、刘圣、王磊、刘阳等 7 人。研讨业务智能体接入 yilibuddy 平台的三种技术方案，明确高代码项目接入路径与排期，并规划接入规约包与后续技术文档准备。

小结

1. 三种接入方案对比

• 方案一（工具化接入）：维持原有 agent loop 不变，核心交互流程封装为工具暴露给 yilibuddy 调用，双方在工具层面进行通信和回调设计。
• 方案二（A2A 协议接入）：不引入新协议，以 Agent 到 Agent 协作形式，主 Agent 将任务委托给子 Agent 执行，通过标准化协议进行上下文传递与用户交互。
• 方案三（资产层拆解接入）：将原有 Agent 彻底拆解，业务逻辑转化为 Skill、MCP 和知识库等资产层组件，由 yilibuddy 平台托管 Agent Loop。

2. 方案选型评估

• 高代码项目接入成本：方案一、二接入较快，但高代码 Agent 修改参数时需 yilibuddy 侧同步配合调整表单，否则会导致运行报错。
• 轻量级 Agent 接入优势：以提示词为主或逻辑较轻的 Agent 采用方案三接入最快，天级别即可完成 Skill 化改造。
• 复杂脚本与数据存储：方案三支持在 Skill 中传入 Python 等脚本，其他语言需更新沙箱镜像包；原有数据库无需改变，可封装 MCP 接口调用。

3. 接入排期与规约包规划

• 排期目标：鉴于 10 月假期时间紧张，各团队预计 11 月底完成整体接入。
• 高代码标杆产出：选取 Java 和 Python 各一个高代码项目作为标杆，10 月 15 日前输出对接方案；其他团队基于该方案评估开发时间，10 月 30 日前完成计划排期。
• 规约包规划：将接入规范封装为「提示词 + JSON Schema + 示例」规约包，各团队智能体读取后通过执行器自行生成 Skill、MCP 等工具知识模板，降低人肉配置成本并避免文档过期。

4. 技术文档与权限配置

• 技术文档：yilibuddy 团队当天下午补充低代码（Defi）接入规范文档；针对表单页等界面交互场景提供教程视频，统一发送至沟通群。
• 平台权限：管理端权限较高，暂不全面开放配置管理界面，按各团队实际需求临时开通；技术服务和技管相关智能体接入权限分别由建朝、小贾和刘圣负责。

待办

1. 方案与排期

• 选取 Java 和 Python 各一个高代码项目作为标杆，10 月 15 日前输出高代码 Agent 对接方案。——刘阳
• 基于 10 月 15 日对接方案，各团队于 10 月 30 日前完成各自开发计划排期。——各团队（责任人待定）

2. 规约包与文档

• 将接入规范封装为「提示词 + JSON Schema + 示例」规约包，供各团队智能体自动读取并生成接入产物。（责任人待定）
• 当天下午补充提供低代码（Defi）接入规范文档。——yilibuddy 团队
• 提供表单页等界面交互场景教程视频并发送至沟通群。——yilibuddy 团队

3. 平台与沟通

• 根据各团队实际需求，临时开通 yilibuddy 平台配置管理权限。——yilibuddy 团队
• 建立沟通群，用于同步接入资料与后续交流。（责任人待定）

红包系统压测方案评审

发言人：郑然然、王军、王建朝。计费管理项目红包系统压测方案评审：重点评估各接口压测必要性，明确无需压测、单接口压测及混合场景压测的范围与标准，并优化压测方案文档呈现方式。

小结

1. 接口压测必要性评估

• 历史接口无需压测：历史接口线上最大每分钟请求量约 90，实际 TPS 已超 100，完全满足并发需求；椰奶与冷饮两事业部共用接口按 1.3 倍流量叠加评估后，现有 TPS 仍可覆盖最大请求量，确认无需压测。
• 智慧门店汇总接口压测标准：红包余额与累计红包统计汇总接口不按前端 60 TPS 预估，以规范的 200 TPS 作为最低压测标准执行。

2. 单接口压测方案调整

• 新增接口：全量压测，确保性能达标。
• 游标分页优化接口：压测对比优化前后性能，方案中仅体现「性能对比」，无需体现基准测试。
• 前端聚合逻辑变更接口：后端逻辑未变但增加前端聚合计算的接口，需进行基准测试，验证无高并发情况下页面展示旁路是否受影响。
• 复杂业务接口：发起余额提现等逻辑最复杂的接口需压测，确认是否存在性能下降风险。

3. 混合场景压测方案

• 组合策略：仅保留本次新增、性能对比及基准测试的接口，未改动接口一律剔除；后端逻辑相同的接口（如椰奶与冷饮）合并为一个，不按事业部区分；两个存在票据传递依赖关系且依赖 Redis 的新增接口采用混合压测，压测平台通过参数化将前一接口返回结果作为后一接口入参。
• 流量分配比例：按业务量分配权重，查询类接口占 20%，余额提现与结果汇总接口占 10%，总和 100%。

4. 压测方案文档规范

• 简化文档结构：压测方案只列出实际要压测的接口及目的，前期评估分析过程作为附件；压测报告有理有据，直接展示实际 TPS 与评估结论，避免复杂化导致评审不通过。
• 评审准备：压测方案与报告将在后续上线评审中汇报，需提前准备应对领导提问。

待办

1. 压测方案与脚本

• 修改压测方案文档，剔除无需压测的接口，仅保留新增、性能对比及基准测试接口，分析过程作为附件。（责任人待定）
• 在压测方案中备注两个 Redis 依赖接口必须同时执行成功（混合压）。——王军
• 按确定的接口组合与流量分配比例（查询 20%、提现 10% 等）完成混合场景压测脚本配置。（责任人待定）

2. 评审汇报

• 参加后续上线评审会议，汇报压测方案与报告。（责任人待定）

线上服务故障排查与发版排期研讨

发言人：潘玉平、王建朝、张喜、张建利、马奇等 6 人。营销活动中心项目会议，含 2 个技术方案评审：排查 RocketMQ 日志打满磁盘及网关故障问题，明确日志输出方案与故障服务下线计划，并重新调整节前紧急需求的发版排期。

小结

1. RocketMQ 日志打满磁盘问题

• 问题原因：receive 服务同一消费组消费多个 Topic，持续打印告警日志，占满容器 4G 磁盘。
• 修复方案：已增加 RocketMQ 的 logback 配置将日志直接打印到控制台，不再写入容器磁盘文件，测试环境验证成功；需将日志级别调整为 info，避免控制台输出过多无用告警。
• 消费组拆分排期：修改代码将不同 Topic 分配至不同消费组，彻底解决告警问题；需在业务低谷期（凌晨 1 至 2 点）执行，防止消息未消费完导致数据丢失。
• 其他服务隐患排查：其他历史服务此前已通过 JVM 参数将 RocketMQ 日志写入 NAS 盘并限制文件大小，暂无此问题；后续需梳理所有服务，确认是否存在类似共用消费组情况，评估是否统一调整日志配置。

2. 网关磁盘打满与 Sentinel 服务下线

• 故障原因：限流服务请求的测试地址域名无法解析，持续打印告警日志导致节点异常；经排查该 Sentinel 服务部署的是默认 Nginx 镜像，无构建记录且节点无法登录，属未生效的废弃服务。
• 下线处理方案：删除 pom 文件中的 Sentinel 依赖并清理 Nacos 配置中心相关配置；pet 和 sit 环境已验证日志停止生成、网关调用正常。
• Dashboard 部署评估：考虑后续可能需要接口限流或降级，暂缓彻底下线，改为部署 Sentinel Dashboard 查看接口调用情况并配置限流降级规则，部署方式可参考小智的现有方案。

3. 节前发版计划调整

• 紧急需求推迟节后：receive 服务修复发版（非核心业务，当前存储预计 30 天后打满）与网关修复发版（非紧急且问题长期存在）均推迟至节后，如 11 月 15 日停机发版时一并处理。
• 保留节前核心需求：B 端出库场景（查证、签收盘点签收）修复需求因业务方需在十一期间刷数，维持 9 月 28 日评审、9 月 29 日晚发版；9 月 30 日保留一天线上监控窗口，确保核心业务稳定。

待办

1. 故障修复与部署

• 梳理所有服务，确认是否有类似共用消费组的情况，评估是否需要统一调整日志配置。——潘玉平
• 凌晨 1 至 2 点（业务低谷期）执行 receive 服务的消费组拆分发版。（责任人待定）
• 部署 Sentinel Dashboard，参考小智的现有方案，以查看接口调用情况并配置限流降级规则。——潘玉平

2. 节前发版

• 9 月 28 日对 9 月 29 日的核心需求（B 端出库场景修复）进行评审。——张喜
• 9 月 29 日晚执行核心需求发版，并在 9 月 30 日进行一天的线上监控。——张喜