java人的ai agent学习福音，这可不是玩具

java人的ai agent学习福音，这可不是玩具

很多 Java 团队看 AI Agent 项目时，会卡在一个很现实的问题上：示例很酷，落地很远。

TypeScript 生态里已经有不少成熟的 agent runtime、CLI、tool calling、session tree 和 provider 集成，但 Java 团队真要学习、改造、接入时，经常要先跨语言、跨工程习惯、跨部署体系。对业务交付团队来说，这个门槛不低。

我最近在做一个 Java/Spring 版的 pi-mono 实现：pi-mono-java。

它不是拿几个 prompt 包一层的 demo，也不是只能在本地玩一下的 toy project。它的目标很明确：让 Java 人能用熟悉的 Maven、多模块、Spring Boot starter、JUnit 测试和可读源码，学习并落地 pi-mono 风格的 agent 工作流。

项目地址：

https://github.com/MarcelLeon/pi-mono-java

这次刚推送了什么

本轮推送的提交是：

b0fb8ac Discover installed package resources

它补上了 CLI resource loader 的一个实际能力：在可信项目里发现已经安装到 .pi/packages/*/prompts 和 .pi/packages/*/skills 下的 prompt / skill 文件。

这件事看起来小，但它把 Java 版从“只能识别本地 .pi/prompts 和 .pi/skills”往 upstream package/resource 体系又推进了一步。

边界也说清楚：这不是完整 package runtime，不包含 package 安装、更新、extension 执行或 supply-chain 校验。现在对齐的是“已安装 package 中 prompt/skill 文件发现”这一层。

现在已经不是玩具的地方

这个项目目前已经有几个值得 Java 人认真看的能力面。

第一，Session 不是一次性问答。

它支持 session tree、JSONL persistence、restore、resume、fork、import/export、usage/reasoning token metadata、invalid JSONL 保护、rename event，以及非流式 tool-call continuation。也就是说，它在认真处理 agent 对话的状态和可恢复性。

第二，CLI 不是摆设。

现在 CLI 已支持 --no-session、--session-id、@file、/session、/resume、/tree、/fork、/export、/import、/models、/resources、/prompts、/skills、/edit，并且能加载 AGENTS.md、CLAUDE.md、.pi/settings.json、prompt templates、skills，以及这次新增的 installed package prompt/skill 文件。

第三，provider 不是 mock 到底。

项目里已有 OpenAI、Anthropic、Bedrock、GitHub Copilot 的非流式 provider 基础，包含 provider header contributor、request-scoped auth/options、tool calls、empty tool result placeholder、HTTP error body、retryable provider error 等能力。

本轮我还用本机 Claude-compatible 配置跑了一次真实 provider smoke：

/models 显示 anthropic provider available
/session 使用 opus-4-7
真实回复：API_OK

这说明“用本地 Claude 配置 dogfood Java provider 路径”是可行的，不只是 mock 测试。

第四，它对 Spring 团队是友好的。

pi-starter 是这个项目的核心价值之一。Java 团队最终需要的不是单独玩一个 CLI，而是把 agent runtime 接到已有 Spring Boot 服务、业务系统、权限边界和运维体系里。

怎么验证

这次不只看代码，我做了可执行验证。

JDK 21 是通过 Homebrew 安装的，但没有改系统默认 Java。默认 java 仍是 17，验证时使用临时环境变量：

JAVA_HOME=/opt/homebrew/opt/openjdk@21/libexec/openjdk.jdk/Contents/Home \
PATH=/opt/homebrew/opt/openjdk@21/bin:$PATH \
mvn test -Djava.version=21

结果：9 个 Maven 模块全部 SUCCESS。

真实 Claude-compatible smoke 用的是本地 shell 配置里的 Anthropic-compatible 环境变量，结果确认 Java provider 能拿到真实响应。

适合谁看

如果你是 Java / Spring 工程师，想理解 AI Agent 不是“调个大模型接口”这么简单，这个项目值得看。

你可以从这些问题切入：

• agent 的 session 如何持久化和恢复？
• tool call 怎么变成 Java 工具调用和 TOOL_RESULT？
• CLI 如何加载项目级上下文、prompt、skill？
• Spring Boot 里如何把 provider、session、tool manager 接起来？
• provider 错误、重试、认证、header 边界该怎么设计？

这些问题比“哪个模型更强”更接近真实工程落地。

目前还没有解决什么

也要明确边界。

Java 版还没有完整对齐 upstream 的 TUI、streaming transport、extension runtime、package install/update、Codex WebSocket/SSE、完整 RPC/orchestrator。

真实 provider 覆盖也还需要继续扩展。OpenAI、Bedrock、Copilot 的真实账号 smoke 还没系统跑完。

所以它不是“已经完整复刻 upstream”。更准确地说，它正在把 pi-mono 风格能力翻译成 Java/Spring 团队能学习、能验证、能继续演进的工程形态。

下一步

接下来更值得推进的是三件事：

1. 做真实 provider gated smoke，把 OpenAI、Anthropic、Bedrock、Copilot 的最小 chat/tool/error 行为跑出脱敏证据。
2. 开始补 streaming 最小路径，优先 OpenAI 或 Anthropic。
3. 把 extension before_provider_headers 从 Java hook boundary 推到更完整的 runtime dispatch。

如果你是 Java 人，想学 AI Agent 的工程骨架，而不是看一堆一次性 demo，可以从这个 repo 开始。

GitHub：

https://github.com/MarcelLeon/pi-mono-java

我会继续把每个对齐切片拆成可验证的 commit，不把“看起来像”当成“已经完成”。