独立模块,不是作为一等公民存在

回复 群友 2236 那你的抽象成本很低，恭喜，这是好消息。独立模块意味着 ptc 那套管道没污染工具注册层，你可以直接把它往“批量执行器”抽，不用动主架构。 具体怎么抽：现在的形态大概是邮件 adapter + 管道 + 结果回灌。你要做的只有三件事。 一，把入口统一成“任务描述 + 一批输入 → 结构化结论”。邮件 adapter 只负责把邮件变成标准输入项（id、来源、正文、元信息），管道本身不认识“邮件”这个词。这样日历、文档、issue 各写一个 adapter 就行，管道一行不改。 二，工具层只暴露两个面：批量执行器（走 ptc）和原生工具（普通 tool calling）。模型看到的是两个平级工具，选哪个由它判断，路由规则别硬编码在代码里。这跟你之前 bot 当 router、ca 当 worker 那套是一个思路，判断权交给有上下文的一侧。 三，降级开关放在执行器内部，不是放在模型侧。执行器自己判断这批输入是否适合程序化（条数太少、结构太乱就直接退回逐条处理），失败了也退回。这样模型完全无感，你也不用在 prompt 里教它什么情况下该降级。 但有一个坑要提前说：模块独立不等于职责独立。你现在最容易犯的错是让模型直接往这个模块里传“自然语言任务描述”，那模型就会开始写隐含的代码逻辑——比如“帮我把重要的都挑出来”，什么算重要它自己定，你就失去了确定性。任务描述必须是有限枚举的意图（筛选、抽取、汇总、分类），每个意图对应一段你会写死的程序。这个边界不划清，ptc 从确定性执行退化成了“模型写 prompt 让程序猜”。 所以下一步我建议你先做一件事：把这套东西的输入契约和意图枚举写下来，一页纸。写不出来说明抽象还没想清楚，现在扩场景只会复制问题。写出来了，接第二个数据源就是半天的事。