把 Agent 工具调用收成一条 Codex 轨迹
把用户问题、工具调用和助手结果组合成可展开的 Codex 风格轨迹，并说明 Pi、Java Gateway 与页面事件投影的真实链路。
从 Prepare–Confirm 到 Draft–Confirm：ERP AI 单据的过期、校对与页面回链
创建一张只有一两行明细的入库单，Agent 生成预览，用户看一眼再确认，Prepare–Confirm 已经够用。 文件导入把这个流程推到了另一种规模。一个 Excel 或 PDF 可能包含几十到几百行明细，模型识别出九成字段仍然不够：漏掉的物料、错位的数量和串列的备注都会进入正式单据。聊天里展示一段摘要也接不住逐行校对，用户需要一个可以直接修改的结构化页面。 我们因此准备把已经实现的 Prepa
给 ERP AI Tool 开发组一支 Codex Agent Team：角色、Loop 与交接合同
接入一个 ERP 模块，交付物远不止一个 Tool 方法。 开发者要先从代码和 UI 里还原业务能力，找领域人员确认规则，再决定 Tool 粒度；实现完成后还要补模块 Skill、单元测试、Agent Scenario、Canary 和开发环境验收。查询和创建单据还有公共协议，模块实现不能各写一份。 我们准备把这条链路交给一支 Codex Sub-agent Team。人只处理领域知识、模块优先级
从 Pi JSONL 到 Java Session Store：保留原生 Session Entry，只替换存储
这次 Java Runtime 的会话迁移里，最容易混淆的是 Entry 名字。管理台里曾经出现过 final、tool_call、tool_result，本地会话里又有若干业务自定义 Entry。它们看起来都像“会话事件”，实际分属不同层次。 Java Runtime 现在不再创建本地会话文件。它直接把 Java Session Store 接到了 Pi 的 SessionRepository
把 Agent 评测器落到代码里：确定性断言、Golden 与双 LLM Judge
现有评测仓库已经能登录 Java Gateway，创建 Pi 会话，再检查 Tool 调用次数、Tool 名和内部字段泄露。仓库里目前有 7 组 Scenario、20 个 Case，评测框架自身的 20 个离线测试可以全部通过。 双 LLM Judge 还没有进入运行链路。配置模板里虽然有 judge 节点，Config、Runner 和报告对象都没有读取或执行它。Golden 也只是一个 ty
给 ERP AI Tools 收一套统一协议：commandType、prepare-confirm 与 Query Framework
ERP Tool 接到第三类单据时，重复代码已经很明显了。 每个创建工具都要判断 prepare 和 confirm，补全主数据，重新校验表单，再处理幂等和并发。查询工具也各自维护 page、pageSize 和返回总数。字段名字看着接近，默认值、上限和错误语义却散在不同 Service 里。 当前链路已经能稳定完成 Tool 发现和调用：Pi Runtime 从 Java 获取 Tool Sch
复制 ECS 后云效 Flow 部署串机：Runner 身份被一并复制
复制一台正在承担部署任务的 ECS 后，云效 Flow 开始把制品随机部署到原机器或复制机。两台机器的 ECS 实例 ID 不同，但在 Flow 看来，它们使用的是同一个 Runner 身份。 最后的止血动作很简单：停止并禁用复制机上的 Runner。真正值得记录的是，为什么复制磁盘会复制部署身份，以及 Flow Runner 到底怎样领取和执行任务。 现象原 ECS 承担前端发布。复制实例启动后
给 LLM Agent 搭自动化验收：分层用例、双裁判与 Golden 答案
我们给 ERP 系统接了一个 LLM Agent：用户在系统侧边栏用自然语言问”今天 3 号炉的生产计划怎么样”，Agent 调后端工具查数据，再组织成一段业务回答。 现在每发一个版本，两段都要人工扛。发布是六步手工命令：本地 build 镜像、打包、传到服务器、导入、起容器、验证健康检查。验收更麻烦：发布后在侧边栏手敲指令，人肉看 Agent 调没调对工具、数据对不对、有没有泄露内部字段。 人肉