味儿福德詹的小站
  • 首页
  • AI
  • 归档
  • 分类
  • 标签
  • 关于

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

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

从 Pi JSONL 到 Java Session Store:保留原生 Session Entry,只替换存储

这次 Java Runtime 的会话迁移里,最容易混淆的是 Entry 名字。管理台里曾经出现过 final、tool_call、tool_result,本地会话里又有若干业务自定义 Entry。它们看起来都像“会话事件”,实际分属不同层次。 Java Runtime 现在不再创建本地会话文件。它直接把 Java Session Store 接到了 Pi 的 SessionRepository
2026-08-18
AI
#AI工作日志 #Agent #Pi #Java #Session Store

把 Agent 评测器落到代码里:确定性断言、Golden 与双 LLM Judge

现有评测仓库已经能登录 Java Gateway,创建 Pi 会话,再检查 Tool 调用次数、Tool 名和内部字段泄露。仓库里目前有 7 组 Scenario、20 个 Case,评测框架自身的 20 个离线测试可以全部通过。 双 LLM Judge 还没有进入运行链路。配置模板里虽然有 judge 节点,Config、Runner 和报告对象都没有读取或执行它。Golden 也只是一个 ty
2026-08-18
AI
#AI Agent #自动化测试 #LLM 评测 #AI工作日志 #Pi #Java Runtime

给 ERP AI Tools 收一套统一协议:commandType、prepare-confirm 与 Query Framework

ERP Tool 接到第三类单据时,重复代码已经很明显了。 每个创建工具都要判断 prepare 和 confirm,补全主数据,重新校验表单,再处理幂等和并发。查询工具也各自维护 page、pageSize 和返回总数。字段名字看着接近,默认值、上限和错误语义却散在不同 Service 里。 当前链路已经能稳定完成 Tool 发现和调用:Pi Runtime 从 Java 获取 Tool Sch
2026-08-18
AI
#AI Agent #AI工作日志 #MCP #Java #架构设计 #Tool Calling

复制 ECS 后云效 Flow 部署串机:Runner 身份被一并复制

复制一台正在承担部署任务的 ECS 后,云效 Flow 开始把制品随机部署到原机器或复制机。两台机器的 ECS 实例 ID 不同,但在 Flow 看来,它们使用的是同一个 Runner 身份。 最后的止血动作很简单:停止并禁用复制机上的 Runner。真正值得记录的是,为什么复制磁盘会复制部署身份,以及 Flow Runner 到底怎样领取和执行任务。 现象原 ECS 承担前端发布。复制实例启动后
2026-08-17
#阿里云 #云效 #Flow #CI/CD #ECS #故障排查

给 LLM Agent 搭自动化验收:分层用例、双裁判与 Golden 答案

我们给 ERP 系统接了一个 LLM Agent:用户在系统侧边栏用自然语言问”今天 3 号炉的生产计划怎么样”,Agent 调后端工具查数据,再组织成一段业务回答。 现在每发一个版本,两段都要人工扛。发布是六步手工命令:本地 build 镜像、打包、传到服务器、导入、起容器、验证健康检查。验收更麻烦:发布后在侧边栏手敲指令,人肉看 Agent 调没调对工具、数据对不对、有没有泄露内部字段。 人肉
2026-08-13
AI
#AI Agent #自动化测试 #LLM 评测 #AI工作日志

回顾 Pi 原生 Skill 机制,以及我们在 Java Runtime 中的选择

这次给 Java Runtime 接入仓管 Skill,我先重新梳理了 Pi 原生的 Skill 链路。 Pi 已经提供了四项可以直接组合的能力: Skill 自动发现 noSkills additionalSkillPaths Skill 元数据注入与正文按需加载 我们最终选择保留这套原生链路: 123noSkills + additionalSkillPaths + 自定义受限 rea
2026-08-13
AI
#AI工作日志 #Agent #Pi #Java Runtime #Skill

一次 ERP AI 会话频繁中断的排查:SSE 心跳、Spring 异步超时与 Pi 状态投影

ERP 里接入数字员工后,普通问答偶尔会同时出现两条提示:一条是“本次业务处理未完成”,另一条是“连接已中断”。发生问题的会话通常已经开始调用 Tool,回答生成到一半就停止。 这次排查确认了两个问题。Spring MVC 的异步响应先超时,Pi 随后把下游断开解释成会话取消;前端又分别展示了 Tool 失败和连接失败,于是一次断流变成了两条错误提示。 现场证据先看服务端时间线。同一时段里,Jav
2026-08-12
AI
#AI工作日志 #Pi #Java Runtime #SSE #Spring Boot #故障复盘

5 MB 图片为什么不会直接吃掉 5 MB 上下文:拆解大模型与 Pi 的图片处理链路

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

Pi 管理台语音输入:把音频停在 Java,把文本交给 Pi

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

搜索

Hexo Fluid
总访问量 次 总访客数 人