MySQL 隐式类型转换导致物料串查：一次 Duplicate key C 排障

一次铁水批次配料试算报错，表面看是 Java 在把元素含量压成 Map 时遇到了重复的 C： 1java.lang.IllegalStateException: Duplicate key C 异常里出现了两个不同物料的碳含量记录。最初容易怀疑物料主数据重复、查询查了两个数据库，或者 toMap 的去重策略有问题。最后确认，真正的原因在 SQL 参数类型：数据库的 material_id 是字符
后端
#Java #踩坑复盘 #排障 #MySQL #数据库

ToolCall 前输出了一大段废话，Agent Runtime 应该怎么限制

在一次 ERP 文档导入中，Agent 明明已经准备调用 Tool，却先输出了整张表格的识别结果、配方元素和后续计划。紧接着，ToolCall 的参数又把同一批数据完整传了一遍。 这不是普通的“回复有点啰嗦”。一次实际会话里，单轮混合了文本与 ToolCall 的 Assistant Message 达到 11,392 个 output tokens、14,890 个字符。用户侧观察到整段流程约
AI
#AI工作日志 #Agent #Pi #Tool Calling #Claude Code #Codex #DeepSeek

MySQL 联合唯一索引遇到 NULL：公共记录为什么会重复

设计多租户配置表时，我想用 tenant_id = NULL 表示公共配置，再给 (tenant_id, skill_name) 加联合唯一索引。直觉上，公共配置和 Skill 名称应该只能有一行，实际插入两条相同的公共记录时，MySQL 并不会报重复键错误。 这个行为容易被误判成索引失效。索引工作正常，冲突判断遇到的是 SQL 对 NULL 的特殊语义。 一个最小例子12345678910111
数据库
#MySQL #SQL #唯一索引 #多租户

给 Pi Java Runtime 加一层工厂级 Skill Override

我们的铁水批次计划已经不适合继续共用一份 Skill。A 工厂创建计划时只需要写计划数据，B 工厂还要创建配方和产品，两个工厂使用同一个业务名称，执行步骤却完全不同。 Tool 暂时没有租户差异，所有工厂仍可调用同一批 Java MCP Tool。变化集中在流程编排：模型处理“创建计划”时，需要先加载当前工厂对应的 Skill，再按正文决定调用哪些 Tool、按什么顺序调用。 这版设计保留 Pi
AI
#AI工作日志 #Agent #Pi #Java Runtime #MCP #Skill #多租户

把 Spring MVC Controller 接成 AI HTTP Tool：一套低侵入方案

业务系统里已经有大量 Spring MVC Controller。如果为了接入 AI Tool，再为每个接口手写一层工具方法，会同时复制参数定义、响应结构和调用逻辑；接口变更时，两套代码还要同步维护。 更低侵入的做法是：保留现有 Controller，只在允许被 AI 调用的方法上增加 @AiToolDef。AI Runtime 从 Spring MVC 和 Swagger 元数据生成 Tool
AI
#AI工作日志 #Pi #MCP #AI Tool #Swagger #Spring MVC

从云效 Pipeline 到 Registry：一条镜像构建链路如何工作

最近给 Pi Java Runtime 增加了一条镜像构建流水线。这个接入只新增了一个仓库构建脚本和一条云效 Pipeline，背后沿用的是现有构建系统：云效收集代码版本并提交构建请求，构建机排队执行，仓库的 Dockerfile 产出镜像，Registry 保存制品，企微通知和 Build Event 分别面向人和系统记录结果。 下面按一次请求真实经过的路径，整理各组件的职责、配置和失败边界。P
AI
#AI工作日志 #Pi #云效 #Flow #CI/CD #Docker #Registry #构建机

从 Prepare–Confirm 到 Draft–Confirm：ERP AI 单据的过期、校对与页面回链

创建一张只有一两行明细的入库单，Agent 生成预览，用户看一眼再确认，Prepare–Confirm 已经够用。 文件导入把这个流程推到了另一种规模。一个 Excel 或 PDF 可能包含几十到几百行明细，模型识别出九成字段仍然不够：漏掉的物料、错位的数量和串列的备注都会进入正式单据。聊天里展示一段摘要也接不住逐行校对，用户需要一个可以直接修改的结构化页面。 我们因此准备把已经实现的 Prepa
AI
#AI Agent #AI工作日志 #Pi #Java Runtime #MCP #ERP #架构设计

给 ERP AI Tool 开发组一支 Codex Agent Team：角色、Loop 与交接合同

接入一个 ERP 模块，交付物远不止一个 Tool 方法。 开发者要先从代码和 UI 里还原业务能力，找领域人员确认规则，再决定 Tool 粒度；实现完成后还要补模块 Skill、单元测试、Agent Scenario、Canary 和开发环境验收。查询和创建单据还有公共协议，模块实现不能各写一份。 我们准备把这条链路交给一支 Codex Sub-agent Team。人只处理领域知识、模块优先级
AI
#AI Agent #AI工作日志 #Pi #Java Runtime #Codex #ERP #Sub-agent #架构设计