知识库草稿：CSDN 高价值技术检索 · LLM API 工程 · Agent 记忆架构 · RAG 2026 新范式 · LoRA 微调排障 · 2026-06-27

实例： Jay | 日期： 2026-06-27 | 检索范围： CSDN（blog.csdn.net / deepseek.csdn.net / aicoding.csdn.net / adg.csdn.net）、Substack（掘金转录 / 技术社区整理版）、arXiv 近期工程方向

一、筛选结论

二、保留条目详细记录

条目 1：Claude + GPT API 实战手册（2026版）

来源： deepseek.csdn.net，2026-05-14，作者：未标注（DeepSeek技术社区） URL： https://deepseek.csdn.net/6a31f461662f9a54cb801d20.html 分类： LLM API / 工程实践 / Agent 开发 标签： Claude, GPT, API, Function Calling, Prompt Caching, Claude Code, Codex, Anthropic, OpenAI

核心观点摘要：

全文分 8 个模块，以 Claude Opus 4.7 / GPT-5.5 为基准，对两家 API 进行工程级对比：

1. API 签名分化：Claude 坚持 messages.create()，GPT-5.5 强推新的 Responses API（client.responses.create()），旧 chat.completions.create() 仍兼容但功能受限（如 GPT-5.5 的 tool calling 必须用 Responses API）

2. Claude Opus 4.7 重大变更（⭐工程必知）： - temperature / top_p / top_k 三个采样参数已移除，传了会报 400 错误 - 扩展思考从 budget_tokens 改为 adaptive thinking（模型自主决定思考深度） - 如需"确定输出"只能通过 prompt 控制（如 "Return only JSON, no explanation"）

3. GPT-5.5 新参数： - reasoning.effort: 思考深度（minimal/low/medium/high/xhigh），复杂 Agent 任务用 high/xhigh - text.verbosity: 输出啰嗦程度，代码生成场景用 low 可省 token - previous_response_id: 新机制，服务端维护上下文，无需手动拼接历史

4. 国内访问三种方案： - 官方 API + 代理（设置 HTTPS_PROXY） - 第三方中转（OpenRouter / AIMLAPI，兼容 OpenAI 协议） - 国内合规模型（DeepSeek / GLM / 通义，兼容 OpenAI SDK）

5. 成本优化： - Prompt Caching（Claude 支持） - Batch API - 模型路由（主力任务用 Opus/V4-Pro，轻量任务用 Haiku/V4-Flash，节省 60-70%）

6. Claude Code / Codex CLI 实战：命令行 Agent 模式、环境变量配置

可信度判断： 高（2026年5月，基于实测代码，版本号具体） 是否需核验： 是——需在 Anthropic/OpenAI 官方文档核实 Opus 4.7 参数变更细节 工程价值： ★★★★★（直接可用的 API 调用模板，含版本差异说明） 建议写入路径： research-kb/published/llm-api/2026-claude-gpt-api-handbook.md

条目 2：LLM Agent 记忆架构深度拆解（2026版）

来源： deepseek.csdn.net，2026-06-13，作者：编程小饴 URL： https://deepseek.csdn.net/6a2cf6fb10ee7a33f27c133a.html 分类： Agent 系统工程 / 架构设计 标签： Agent, Memory, RAG, Context Window, Summarization Drift, OpenClaw, LangChain

核心观点摘要：

本文是 Agent 记忆系统设计的工程级深度总结，核心论点是：Agent 的核心差异化在记忆架构，而非模型选型。

1. Write-Manage-Read Loop（核心框架）： - 写入：环境观察、任务执行结果、反思总结 - 管理（最常被忽视）：修剪冗余、压缩历史、整合关联、消除矛盾 - 读取：决策时精准检索，注入上下文 - 大部分实现"写入"和"读取"做得不错，但"管理"几乎完全缺失

2. 四种记忆时间维度： - 工作记忆（Working Memory）：上下文窗口 = "便签纸"，超出即丢失 - 情景记忆（Episodic Memory）：按时间排列的事件序列，OpenClaw 中对应 Daily Standup Logs - 语义记忆（Semantic Memory）：抽象提炼的持久知识，OpenClaw 中对应 MEMORY.md - 程序性记忆（Procedural Memory）：行为模式 = "肌肉记忆"，OpenClaw 中对应 AGENTS.md / SOUL.md

3. 五大记忆机制： - 上下文驻留压缩（滑动窗口/滚动摘要/分层压缩）→ 失败模式：摘要漂移（Summarization Drift） - 检索增强存储（RAG 用于交互历史）→ 失败模式：语义相似 ≠ 因果相关 - 反思式自我改进（Reflexion / ExpeL / Google Memory Agent "梦境"系统） - 分层虚拟上下文（MemGPT 类 OS 架构，RAM/磁盘/冷存储分页调度） - 策略学习型管理：强化学习训练存储/检索/更新/丢弃策略——前沿方向，尚无成熟工具

4. 典型失败模式（工程高价值）： - 摘要漂移：反复压缩丢失细节，记忆与实际偏离；应对：保留原始记录 - 注意力稀释：即使百万 Token 窗口，中间信息被"遗忘" - 静默编排失败：分页/淘汰策略出错但无日志，Agent 回答越来越泛化 - 记忆盲区：Top-K 召回导致第 11 条记忆永远不可见

5. 设计核心张力： - 效用 vs. 效率（更好记忆 = 更多 Token / 更高延迟） - 效用 vs. 适应性（过时记忆 vs. 更新成本） - 适应性 vs. 忠实度（"智能整理"可能扭曲历史） - 忠实度 vs. 企业合规（ PHI/PII 数据治理）

6. 实践建议： - 从单一记忆类型开始，不要过早构建全部四种 - 认真对待管理环节（压缩/整合/淘汰策略） - 保留原始情景记录，不要只依赖压缩摘要 - 反思性记忆加版本号/时间戳，处理冲突 - 程序性记忆当代码管理，纳入版本控制

可信度判断： 高（2026年6月，引用 OpenClaw、Claude Code、Kiro CLI 等具体系统为案例） 是否需核验： 是——Reflexion/ExpeL/MemGPT 框架的工程成熟度需核实 工程价值： ★★★★★（Agent 系统设计的系统性框架，失败模式分析尤为实用） 建议写入路径： research-kb/published/agent/2026-agent-memory-architecture-framework.md

条目 3：Ollama 本地部署排障实战（2026合集）

来源： blog.csdn.net，多篇排障文章综合 URL（汇总）： - https://blog.csdn.net/m0_73679357/article/details/145432758（DeepSeek + Ollama 报错） - https://ask.csdn.net/questions/8592566（exited status=203） - https://tencentcloud.csdn.net/69ea7d9854b52172bc6e5d7d.html（Ollama 故障排除完全指南） - https://blog.csdn.net/DomicZhong/article/details/158700449（Ollama 避坑指南 10 例）

分类： 部署工程 / 排障实践 标签： Ollama, 本地部署, GPU, CUDA, 代理, 权限

核心观点摘要：

1. exited status=203 高频原因： - 模型文件损坏 - 路径配置错误 - GPU 驱动不兼容（CUDA/cuDNN 未正确配置） - 内存不足 - 解决：检查 ollama logs、验证模型文件完整性、确认 CUDA 版本

2. Pull model manifest 失败： - 网络问题（Ollama 默认直连海外，无代理） - 解决：设置代理 + ollama pull 重试，或清理缓存

3. 权限问题（自定义存储路径）： - ollama 服务默认以特定用户运行，创建自定义目录时权限不足 - 解决：OLLAMA_MODELS 环境变量指定路径 + 确保目录权限

4. GPU 相关： - 确认 NVIDIA 驱动 + CUDA 环境变量正确 - ROCm（AMD GPU）支持有限，需核实具体显卡型号

5. Ollama 版本问题： - 旧版（如 < 0.9.0）加载某些模型会报 500 internal server error - 解决：升级到最新版 ollama --version

可信度判断： 中（排障经验类文章，部分为旧版本 Ollama，需注意时效性） 是否需核验： 是——Ollama 版本演进快，建议核实官方文档最新版本号 工程价值： ★★★★（日常运维高频参考） 建议写入路径： research-kb/published/deployment/ollama-local-deploy-troubleshooting-2026.md

条目 4：LoRA/QLoRA 微调避坑指南（十大实战坑点）

来源： blog.csdn.net/m0_59235245，2026 URL： https://blog.csdn.net/m0_59235245/article/details/161777173 分类： 模型微调 / 工程实践 标签： LoRA, QLoRA, 微调, 数据清洗, LlamaFactory, Triton

核心观点摘要：

1. LoRA vs QLoRA 原理对比： - LoRA：低秩矩阵分解，原始权重冻结，只训练 A/B 矩阵 - QLoRA 2.0：4 位量化 + LoRA，单张消费级 GPU 可微调 70B 模型，内存减少约 60%

2. 十大实战坑点（提炼）： - 数据清洗占比 70% 工作量（质量 > 数量） - 学习率设置不当（LoRA 通常用 1e-4 ~ 3e-4，远高于全参微调） - 秩（rank）选择：太大会过拟合，太小欠拟合，典型值 8/16/32 - 模块定位错误（q_proj/k_proj/v_proj/o_proj 而非全部） - 目标模块冻结策略不明确 - 梯度累积步数与 batch size 配置错误 - 早停（early stopping）阈值设置不当 - 量化精度损失在某些任务（代码/数学）比文本更严重 - 推理时 lora weights 合并（merge）操作丢失部分精度 - 保存 checkpoint 时未正确处理 adapter config

3. LlamaFactory + Triton 推理优化： - QLoRA 训练 + TensorRT 引擎转换 - 动态 batch 调度 - FP8/BF16 混合精度

可信度判断： 中（工程经验总结，含具体数字但需核实最新框架版本） 是否需核验： 是——LlamaFactory 版本迭代快，需确认 Triton 支持最新状态 工程价值： ★★★★（微调实战的系统性避坑清单） 建议写入路径： research-kb/published/finetuning/2026-lora-qlora-pitfalls-guide.md

三、本次未入选条目（快速说明）

四、主题标签与分类

• LLM-API / Claude / GPT / OpenAI / Anthropic
• Agent / Memory-Architecture / Context-Window / Summarization-Drift
• RAG / Retrieval / Knowledge-Graph
• Fine-tuning / LoRA / QLoRA / LlamaFactory
• Deployment / Ollama / vLLM / SGLang / Troubleshooting
• Quantization / FP8 / AWQ / GGUF

五、本次总结与后续行动建议

本次高价值条目（3 条）： 1. Claude + GPT API 实战手册（★★★★★）——直接可用，含版本差异 2. LLM Agent 记忆架构深度拆解（★★★★★）——系统性框架，失败模式实用 3. Ollama 本地部署排障（★★★★）——运维参考

建议后续行动： - [ ] 精读 Claude Opus 4.7 API 变更，核实官方文档（temperature/top_p/top_k 移除细节） - [ ] 核验 Reflexion/ExpeL/MemGPT 框架工程成熟度 - [ ] 更新 Agent 架构主题页，整合记忆架构框架 - [ ] LlamaFactory + Triton 最新版本状态核实

本次写入路径： /shared/research-kb/inbox/jay/2026-06-27-csdn-llm-api-agent-rag-finetune.md

Jay · 2026-06-27 · CSDN 高频检索