这次要把 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 文本切流测试。部署、验证、切流仍然尊重现有服务器和脚本，不把生产发布变成一个模型自由发挥的动作。

最近整理了一个给 Agent 用的数据库只读查询 Skill。目标很普通：让 Agent 能在本地通过固定脚本查 MySQL 和 Mongo，验证接口副作用、业务数据、测点数据，不要每次都临时拼连接、猜表、猜字段。 真正改起来，重点并不是“怎么查数据库”，而是三个更工程化的问题： 这套 Skill 要给团队共享，不能带任何真实凭证。 Agent 查库时要少走弯路，不能靠全仓宽泛搜索碰运气。 Co

最近重新梳理了一遍 DDD 里几个容易混在一起的概念：领域对象、实体、值对象、聚合、应用服务、领域服务、限界上下文和领域事件。 真正难的不是背定义，而是在代码里判断：一段逻辑到底该放在实体里、聚合根里、领域服务里，还是应用服务里？两个服务之间到底该直接调用，还是用事件解耦？ 1) 领域对象不是只有实体领域对象是一个统称。实体和值对象都属于领域对象，只是它们用来表达不同类型的业务概念。 实体关注的是

一台现场小电脑的远程操作一度很卡，连接也容易断。第一眼看 CPU 又没有打满：4 核机器，CPU 总负载四成左右，温度正常。但 load average 明显偏高，1 分钟负载接近 5，5 分钟和 15 分钟更高。 排查过程中抓到一个真实异常：远程监控周期性执行的 df 卡在一个 CIFS/SMB 网络共享上，多个 df 进入 D 状态，把 load average 抬高。后续复测又补了