内置能力只覆盖它声明的那一段
例子:attachment support ≠ 文件管线
Agent 框架的「附件支持」实际只做了一件事 —— 消息可以携带图片(如 agent.prompt(text, images) 传 base64)。
它不含:OCR、PDF/Word/Excel 解析、结构化分块、向量检索、TTL 存储。
于是可以据此简化方案:
普通图片 + 视觉模型 → 直接复用框架已有的图片入口
扫描 PDF / Office 文档 → 仍需自建解析与 OCR 管线
chunk / 向量 / 过期清理 → 仍需自建
该复用的复用,该自建的老实自建 —— 不要因为「框架说支持附件」就以为不用写解析层,也不要因为框架只支持图片就把整套协议重造一遍。
相关
- 能力要靠消费方认账 —— 同源:能力是否真的存在,要看它落到链路哪一段
- 契约只承载结构,个性留给扩展层 —— 复用已有的入口,把差异留在扩展层
- 文档附件解析管线 —— 这条判断在附件场景下的完整落法
- Agent Harness 不只是 Tool Loop —— 同源:harness 的边界比名字暗示的大/小