给 Management Console 加图片输入时，我先定了两个限制：一轮最多 5 张，原始单图不超过 10 MiB。随后看到 Runtime 给 Qwen 登记的上下文窗口是 1,000,000 Token，一个问题马上冒出来：一张 5 MB 图片发给模型，会不会直接吃掉几百万 Token，顺手把前面的系统指令挤出去？ 这两个数字属于不同阶段。5 MB 描述图片文件和 HTTP 传输；1M

管理台的语音输入最后没有做成“浏览器把音频交给 Pi，再让模型处理”。实际链路是：浏览器录音，Java 调用阿里云百炼转成文字，文字回填输入框；用户确认后，才按原有 SSE 对话链路交给 Pi。 这个拆分很重要：Pi 负责 Agent 会话、Tool 调用和模型回复；Java 负责 ERP Gateway 已有的鉴权、部署配置和外部 ASR 调用。音频不是 Pi 会话的一部分，也不会进入 LLM

我们准备把 Java MCP 接到 Pi Runtime 上。工具目录未来会按租户、用户和业务权限过滤，但过滤后的工具仍可能很多。把全部 Tool Schema 每轮发给模型，会增加 token 消耗，也会让相似工具之间的选择变得不稳定。 Pi 已经有渐进加载的底层机制：工具可以全部注册在 Registry 中，只把当前 Active Tools 发给模型。这套能力可以复用到 Java MCP，搜

这次要把 Pi Runtime 部署到一台已经安装 Docker 的 x86_64 Linux 主机上。代码还没有进入代码托管和构建流水线，因此第一版不接镜像仓库，也不做自动发布，只要求本地构建镜像、传到服务器、接入 Nginx，并把环境变量和运行数据放到镜像外面。 讨论到最后，真正需要理清的不是 Dockerfile 语法，而是三个边界：镜像负责什么，Compose 负责什么，环境变量和文件挂载

Pi 的 Skill 不是在启动时把所有 SKILL.md 正文塞进模型上下文。它采用渐进加载：启动或重载时发现 Skill 并保存元数据，构建 System Prompt 时只向模型展示目录，真正选中某个 Skill 后才读取正文。 理解这三层状态很重要：磁盘上的 Skill、运行时内存里的 Skill 元数据、模型上下文里的 Skill 正文不是同一件事。 三个加载时机完整链路可以压缩成三步：

Pi Java Runtime 目前把 Pi 的 AgentSession 写到本地 JSONL，再把原始 Entry 镜像到 Java 数据库。这个实现足以支持单机运行和管理台回放，但不适合作为云端部署后的会话恢复方案。 核心问题很直接：Runtime 续聊时仍从本机 sessions/*.jsonl 打开会话。如果实例重启、容器迁移或扩容到另一台机器，数据库虽然还保留管理台记录，Agent 却

一次物料出库的 AI Tool 调用失败，表面提示是“物料不存在或不属于当前工厂”。实际物料存在，问题发生在它作为 19 位 ID 穿过 JSON 与工具调用契约时。 第一次排查发现，工具调用收到的 ID 已经和查询结果不一致。随后将工具结果中的大整数序列化为字符串后，最新会话仍失败：返回值正确了，但工具参数 Schema 还是 integer，模型又把字符串 ID 当数字传回。这个问题需要同时修

自动配料页面最初的问题，不是字段不够，而是把所有字段同时摊在了一张表里：炉内、炉后、浇注三类配料混在一起；重量、比例、容差、固定比例、价格并列出现；目标成分又在另一张横向大表里同时表达炉前和产品目标。 用户面对的不是“制定一个配方”，而是一张需要不断横向滚动、反复确认列含义的配置表。字段本身有业务价值，但页面没有把业务过程表达出来。 这次改造的目标很明确：让页面按照真实工艺流程组织，让用户在每一步

今天主要是在收口一个 LoRa 相关项目的现场稳定性和配置体验。不是只修一个点，而是把几个长期摩擦放到同一条链路里整理：现场 LoRa 轮询被异常设备拖慢、转发模式开关和运行态保活互相打架、LR 配置页信息太散、子设备卡片缺少运行来源，以及 Codex 自身的 worktree、skill、commit scope 规则需要整理。 从本地 Codex 原始会话看，今天 2026-07-01 一共有

这次做的是一个云端部署 Skill。目标不是再造一套发布平台，而是把已经存在的人工发布流程拆成 Agent 能稳定执行、能停在正确位置、能把事实说清楚的几段能力。 最后落地的形态很克制：一份服务拓扑 YAML，一份 Skill 说明，三个面向 Agent 的 Python 脚本，再加一组 Nginx 文本切流测试。部署、验证、切流仍然尊重现有服务器和脚本，不把生产发布变成一个模型自由发挥的动作。