feat(adk): generify all remaining middlewares for AgenticMessage support

[shentongmartin]

Generify All Remaining Middlewares for AgenticMessage

Problem

The ADK core, deep agent, and filesystem middleware already support AgenticMessage via TypedChatModelAgentMiddleware[M], but the 7 remaining middlewares under adk/middlewares/ are hardcoded to *schema.Message. This blocks any agent using *schema.AgenticMessage from leveraging these middlewares for tool call patching, context reduction, summarization, skill execution, etc.

Solution

Generify all 7 middlewares over M adk.MessageType using the established TypedXxx[M] + backward-compatible alias pattern. Every middleware now has a NewTyped[M] constructor alongside the existing New(), with internal struct renamed to typedXxxMiddleware[M].

The key challenge: *schema.Message and *schema.AgenticMessage have fundamentally different field structures (flat Role/Content/ToolCalls vs nested AgenticRoleType/ContentBlocks). Each middleware needed type-switch dispatch to handle both:

switch m := any(msg).(type) {
case *schema.Message:
    // flat fields: m.Role, m.Content, m.ToolCalls
case *schema.AgenticMessage:
    // block-based: m.Role (AgenticRoleType), m.ContentBlocks
}

For hard middlewares (reduction, summarization, skill), this required genericizing Config callback types, internal helper functions, and deep message field accessors — not just the struct/constructor.

Decisions

Full AgenticMessage support vs pass-through: Initially considered making hard middlewares pass-through for *schema.AgenticMessage (return messages unchanged). Rejected — the plan explicitly requires native support, and pass-through defeats the purpose of the middleware.

Generic internal methods vs separate implementations: For reduction/summarization, chose generic helper functions (isAssistantMsg[M], getToolCallsGeneric[M], copyMessagesGeneric[M], etc.) with type-switch dispatch over maintaining two complete parallel implementations. This keeps the main algorithm in one place while isolating type-specific field access.

model.BaseModel[M] for skill: AgentHubOptions.Model and ModelHub.Get() changed from model.ToolCallingChatModel to model.BaseModel[M]. This is required because ToolCallingChatModel is an alias for BaseModel[*schema.Message], which would leak *schema.Message into generic code.

Key Insight

*schema.AgenticMessage has no tool role — tool results are ContentBlockTypeFunctionToolResult blocks in user-role messages. Any middleware that checks for "tool messages" (reduction, patchtoolcalls) needs fundamentally different detection logic for agentic messages: iterate ContentBlocks looking for FunctionToolResult entries instead of checking msg.Role == schema.Tool.

Summary

Problem	Solution
7 middlewares hardcoded to *schema.Message	Generic typedXxxMiddleware[M] with NewTyped[M] + New() delegation
*schema.AgenticMessage has different field structure	Type-switch dispatch with generic helper functions
Config callback types use concrete *schema.Message	TypedConfig[M] with Config = TypedConfig[*schema.Message] alias
AgentHubOptions.Model leaks *schema.Message via ToolCallingChatModel	Changed to model.BaseModel[M] in TypedAgentHubOptions[M]
No tool role in AgenticMessage	Iterate ContentBlocks for FunctionToolResult instead of role check
Type declaration inside generic function (Go 1.18 compat)	Moved struct to package level

---

泛化所有剩余中间件以支持 AgenticMessage

问题

ADK 核心、deep agent 和 filesystem 中间件已通过 TypedChatModelAgentMiddleware[M] 支持 AgenticMessage，但 adk/middlewares/ 下的 7 个中间件仍硬编码为 *schema.Message。这导致使用 *schema.AgenticMessage 的 agent 无法利用这些中间件进行 tool call 修补、上下文缩减、摘要生成、技能执行等。

方案

将所有 7 个中间件泛化为 M adk.MessageType，使用已有的 TypedXxx[M] + 向后兼容别名模式。每个中间件新增 NewTyped[M] 构造函数，保留已有的 New()，内部结构重命名为 typedXxxMiddleware[M]。

核心挑战：*schema.Message 和 *schema.AgenticMessage 的字段结构完全不同（扁平的 Role/Content/ToolCalls vs 嵌套的 AgenticRoleType/ContentBlocks）。每个中间件需要 type-switch 分发来处理两种类型：

switch m := any(msg).(type) {
case *schema.Message:
    // 扁平字段: m.Role, m.Content, m.ToolCalls
case *schema.AgenticMessage:
    // 基于 block: m.Role (AgenticRoleType), m.ContentBlocks
}

对于复杂中间件（reduction、summarization、skill），这要求泛化 Config 回调类型、内部辅助函数和深层消息字段访问器——不仅仅是 struct/constructor。

决策

完整 AgenticMessage 支持 vs 透传：最初考虑让复杂中间件对 *schema.AgenticMessage 做透传（原样返回消息）。被否决——计划明确要求原生支持，透传违背中间件的本意。

泛型内部方法 vs 独立实现：对于 reduction/summarization，选择使用泛型辅助函数（isAssistantMsg[M]、getToolCallsGeneric[M]、copyMessagesGeneric[M] 等）配合 type-switch 分发，而非维护两套完整的并行实现。这样主算法保持在一处，类型相关的字段访问被隔离。

skill 使用 model.BaseModel[M]：AgentHubOptions.Model 和 ModelHub.Get() 从 model.ToolCallingChatModel 改为 model.BaseModel[M]。因为 ToolCallingChatModel 是 BaseModel[*schema.Message] 的别名，会将 *schema.Message 泄漏到泛型代码中。

关键洞察

*schema.AgenticMessage 没有 tool 角色——工具结果是 user 角色消息中的 ContentBlockTypeFunctionToolResult block。任何检查"工具消息"的中间件（reduction、patchtoolcalls）都需要针对 agentic message 采用完全不同的检测逻辑：遍历 ContentBlocks 查找 FunctionToolResult 条目，而非检查 msg.Role == schema.Tool。

总结

问题	方案
7 个中间件硬编码为 *schema.Message	泛型 typedXxxMiddleware[M] + NewTyped[M] + New() 委托
*schema.AgenticMessage 字段结构不同	Type-switch 分发 + 泛型辅助函数
Config 回调类型使用具体的 *schema.Message	TypedConfig[M] + Config = TypedConfig[*schema.Message] 别名
AgentHubOptions.Model 通过 ToolCallingChatModel 泄漏 *schema.Message	改为 TypedAgentHubOptions[M] 中的 model.BaseModel[M]
AgenticMessage 没有 tool 角色	遍历 ContentBlocks 查找 FunctionToolResult 而非角色检查
泛型函数内的类型声明（Go 1.18 兼容性）	将 struct 移至包级别

[codecov]

Codecov Report

❌ Patch coverage is 89.13525% with 98 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (alpha/09@eb1de22). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
adk/middlewares/reduction/reduction.go	87.03%	24 Missing and 11 partials ⚠️
adk/middlewares/summarization/summarization.go	87.58%	29 Missing and 6 partials ⚠️
adk/middlewares/skill/skill.go	81.69%	12 Missing and 1 partial ⚠️
adk/middlewares/patchtoolcalls/patchtoolcalls.go	88.88%	6 Missing and 2 partials ⚠️
adk/middlewares/agentsmd/agentsmd.go	96.07%	2 Missing ⚠️
...k/middlewares/dynamictool/toolsearch/toolsearch.go	96.96%	2 Missing ⚠️
schema/agentic_message.go	97.43%	1 Missing and 1 partial ⚠️
adk/middlewares/summarization/customized_action.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             alpha/09    #1003   +/-   ##
===========================================
  Coverage            ?   83.09%           
===========================================
  Files               ?      162           
  Lines               ?    22712           
  Branches            ?        0           
===========================================
  Hits                ?    18872           
  Misses              ?     2590           
  Partials            ?     1250           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mrh997]

抽成一个 default 函数？

[mrh997]

这个也写成函数？

[mrh997]

有点别扭，user message 如果同时存在 UserInput 和 FunctionToolResult 是不是不能当作是普通 user message 处理

[mrh997]

写成一个方法？类似 toolResult.ToMessageInputParts()

[mrh997]

这个已经 Deprecated 了

[mrh997]

和extractTextContent的处理不一致，这个方法应该叫 getUserTextContent。原来 trim 逻辑也有点不太对，不应该破坏原来的 MultiPart 结构。第二点如果不好改，合入之后我来改也行。

[mrh997]

是不是应该换行拼接？