Wanted: who's using agentscope-extensions-jev

[jujn]

分享用 agentscope-extensions-jev 做工具决策与意图识别的实践

agentscope-extensions-jev 提供的是 TypeSafe System One / Jev 的 Java HTTP client。

它不是一个聊天模型。我们更关注的是另一类问题：

• Agent 面对几十上百个工具/Skill 时，如何减少发送给主模型的 tool schema？
• 如何在 reasoning 前判断哪些工具、技能或子流程值得进入上下文？
• 如何把“用户意图识别 / 路由 / 分级 / 置信度判断”从一次完整的 LLM 调用里拆出来？
• 在生产环境里，这种决策层的延迟、成本、准确率和失败策略是否值得？

这些问题很依赖真实场景。因此我们希望征集社区里的实际用法、自定义 middleware、评测方法和踩坑经验。成功和失败案例都欢迎。“在我们场景里没有收益”同样有价值！

我们希望看到什么

欢迎分享以下任意一种形式：

1. 自定义 middleware 组件

   • 基于 JevClient 自定义 Middleware（可参考 agentscope-extensions-jev 内示例JevToolSelectionMiddleware / JevSkillSuggestionMiddleware）
   • 例如动态工具过滤、意图路由、权限前置判断、RAG 重排、workflow 决策节点等

2. 完整项目或示例

   • 可公开的 GitHub / demo 链接
   • 包含关键思路和核心代码即可

3. 博客文章

   • 如果希望发布到 AgentScope Java 官网博客，可以提交 PR，位置：
     https://java.agentscope.io/v2/zh/blogs/
   • 也可以先在本 issue 留下外部博客链接，我们会挑选并收录

4. 评测和实践数据

   • 工具选择准确率、上下文 token 变化、延迟变化、成本变化
   • 与直接让主模型选工具的对比

你的场景也许正是别人在寻找的答案。期待一起完善 AgentScope-Java 决策层生态！

[oss-maintainer]

Issue Evaluation

Category: enhancement (ecosystem / case-study solicitation) | Status: Evaluated — intake path is outside this repo, no code change to generate (checked against main @ ed77530a4)

What was verified in-tree

• agentscope-extensions-jev does not exist in this repository. The agentscope-extensions aggregator declares 21 modules (aistio, channel, cos, higress, jdbc, mem, model, mongodb, mysql, nacos, oss, postgresql, protocol, rag, redis, sandbox, scheduler, skills, spring-boot-starters, studio, training) and none of them is JEV; no pom.xml, doc page or commit in main references it either. So JevClient, JevToolSelectionMiddleware and JevSkillSuggestionMiddleware named in this issue cannot be built, run or reviewed by anyone reading this repo — there are no Maven coordinates and no source link here.
• The framework side of the pattern this solicitation is about is first-class, so a community middleware has a stable place to hook in: MiddlewareBase exposes onAgent / onReasoning / onActing / onModelCall / onSystemPrompt plus order() and MiddlewareChain — agentscope-core/src/main/java/io/agentscope/core/middleware/MiddlewareBase.java:71-158.
• The closest in-repo precedent for "shrink what reaches the main model" already exists: DynamicSkillMiddleware implements MiddlewareBase + ToolkitAware and rebuilds the per-call skill view in onSystemPrompt (agentscope-core/src/main/java/io/agentscope/core/skill/DynamicSkillMiddleware.java:60, :129), i.e. tool/skill-schema selection is a documented middleware use case, not an unsupported one.
• The blog intake path mentioned in the issue is real and in this repo: docs/v2/en/blogs/usecases/ and docs/v2/zh/blogs/usecases/ currently hold index.md, finxscope.md, logistics.md, aidc-logistics.md, and each page is registered in the nav of docs/docs.json (en :381-384, zh :874-877).

Consequences for collecting the submissions this issue asks for

1. A submission PR to the blogs section has to add the markdown under both language trees and the matching docs/docs.json nav entries — a page that is not in docs.json does not appear on java.agentscope.io. Worth stating explicitly in the issue body so contributors do not open half-complete PRs.
2. Reproducible practice data needs a pinned artifact. Suggest adding to the first comment: groupId:artifactId:version (or the source repo URL), the AgentScope Java version the middleware was tested against, and whether the decision layer runs on the request path or off it. Without that, latency/token/accuracy reports in this thread will not be comparable to each other, which is exactly the value this issue is trying to capture.
3. For the "how to intercept tool schema" question, pointing contributors at MiddlewareBase.onReasoning / onModelCall (schema is on the model call boundary) and at DynamicSkillMiddleware as the working example would answer most of it without a doc page.

Action taken: categorized and labeled area/ext/integration for triage routing. No bot PR: this issue requests community reports, not a defect fix, and the referenced module is not in this repository, so there is nothing for an automated patch to change. Reviewing and merging any case-study contribution stays with maintainers.

---

Automated evaluation by github-manager-bot