AIPing 开发者投稿

Main

---

第三期 长文本实战技巧

长文本实战中主要有2个注意点，一个是场景执行效果，另一个是API 调用成本

场景执行效果，如编码、多步骤工作流设计 ，主要经验如下

• 好的模型框架是工程落地的基础，类似 Claude Code 、OpenCode 等开源实现的 CLI 工具已非常丰富，但往往模型厂商自带的CLI 会有更多原生的工程实现来提高Coding 等长文本场景的执行效率，如CC 中自带的 上下文压缩机制，选择好的框架，尤其是有模型厂商原生，或垂直整合的CLI工具 （如 DeepSeek-TUI），往往能收获底层架构优化的加持，这部分开发者自己能做的比较少，一句话总结：选择大于努力，和谁在一起，往往能省很多事。
• 长文本中子任务的分类识别，一些数据采集、内容抓取、感知层的工作，可以调用instinct 模型来执行，从而节约thinking 模型的调用成本，且能节约时间，需要深度思考和写执行文件的环境，优先调用thinking模型来保证生成质量，但需要注意的是，从 instinct 切换到 thinking 的过程 因切换模型，会生成一次输入的上下文切换，但这与一直调用 thinking 模型来执行相比，成本上还是要节约不少的。一句话总结：了解任务的颗粒度和交付结果重要性，区分不同模型来执行

以上两者都是 底层 架构层面，对长文本实战的建议

技巧上的建议，如下供参考：

• 随着 Agent 框架中，加载的技能越来越多（个人常驻有20+，团队级有60+），问答首次加载，会携带大量的 skills 上下文，这无形中增加了大量非相关的Tokens 注入，这些首次加载的 Tokens 在LLM 架构设计上，会给予更高的注意力权重，不相关的注入，可能会造成污染。如何优化通用任务的 skills 头文件的加载效率，在企业级 Agent 场景 是有需求的，基于此，给大家推荐：基于外置向量存储桶实现skills 文件的 智能路由

  1. 实现原理

  该方案利用RAG（检索增强生成）技术，在OpenClaw调用大模型前增设“智能路由”层。具体流程为：预先将所有Skill描述文本通过Embedding模型转为向量存入COS向量桶；当用户提问时，系统将问题也转为向量，在向量桶中进行相似度检索，毫秒级筛选出最相关的Top-K个技能，仅将这些精选技能注入上下文，从而实现动态按需供给。

  2. 场景价值

  该方案主要解决AI Agent功能扩展与成本控制的矛盾。在多工具场景下，它能将单轮对话Token消耗降低92%（如从4867降至430），大幅削减推理成本；同时剔除无关技能噪音，提升模型响应精准度与速度，特别适合已接入数十个以上Skill、面临上下文过载与高费用困扰的生产环境。

demo

update by self-dev plugin

== END ==