• 算法和数据结构（性能，场景）：
  • 数据结构：
  • 算法
  • 数据库(mysql)
  • NoSql
  • 设计模式
  • 操作系统
  • java
  • 脚本语言
• 架构
  • 微服务
  • 分布式
  • 大数据
  • 运维 & 统计 & 技术支持
  • 测试
• 书单
• 实战
  • 实践一个双十一电商项目

机器学习相关知识点整理，

• 编程语言相关
  • java
  • python
• 数学基础
  • 抽样方法
    • 1.分层抽样的适用范围？
• 机器学习相关
  • 线性回归和LR
  • gbdt、xgboost相关
  • RF相关
  • kmeans相关
  • EM HMM CRF相关
  • 决策树相关
  • SVM相关
  • 降维算法相关
    • 各种ML模型比较
  • 其他
• 深度学习相关
• 自然语言处理相关
• 手撕算法&场景题
• 面经分享
• 一些有用的知识整理

本文章是本人的收藏夹，罗列了各种神奇的工具、文章。

微信

公众号

读书类

1. 阿猫读书
2. 每晚一卷书
3. 十点读书
4. 晚点LatePost
5. 知乎高赞

投资类

1. 阿猫投资学

认知升级\职场商业

1. 艾菲的理想
2. 笔记侠
3. 曹将
4. 插座APP
5. 得到
6. 洞见
7. 刘润

时事

1. warfalcon
2. 政事堂

优秀公众号合集

🔥笔记侠 - 思维方式
🔥印象笔记 - 一周排行榜
🔥有道云笔记 - 一周排行榜
刘润文章合集
财富自由书单
理财投资
B站推荐
笔记侠 - 更新书堂
艾菲的理想 - 文章精选
艾菲的理想 - 外在成功
语雀 - 小小哥的 Blog
道长的思维铺子 - 思考方式和思维模型

优秀公众号文章

🔥读懂《毛选》的人有多通透
比管理时间重要1000倍的，是管理精力
卡耐基的这100句话，畅销85年，改变了很多人
阅读新闻的技巧
看完德鲁克的72条思考，我终于明白他为何这么牛
别人送的第一桶金，一文不值

视频

🔥b站Up主推荐\书籍推荐

读书

🔥书籍解说
微信读书热门标注

github

资料收集

ixinzhi
apachecn
it-ebooks
wizardforcel
中文独立博客列表

周刊

科技周刊
Hello Github

其他

其他

TED

技术

周报

AIQ

很多团队做 Evals 时停在“做一张分数表”，然后把它放进周报。

问题是：

• 分数好看，不代表线上稳定。
• 评测跑了，不代表发布可控。

Evals 的正确定位应该是：发布门禁系统的一部分。

架构图：质量/成本/时延三门禁

时序图：一次回归是如何阻断发布的

工程化 Evals 的三个层次

1. 离线正确性评测

验证模型是否在核心任务上达到最低可用线。

2. 线上性能评测

监控延迟、成本、失败率，确保系统可运营。

3. 发布门禁评测

与 CI/CD 挂钩，回归即阻断发布。

建议的门禁规则（示例）

• 质量分数下降超过阈值：阻断。
• 成本上涨超过预算比例：阻断。
• P95 延迟超阈值：阻断。
• 关键业务样本失败：强制人工审批。

评测集建设要点

1. 代表性：覆盖真实高频和高风险请求。
2. 可追溯：样本来源、标签标准、版本都要记录。
3. 可迭代：每次线上事故都要反哺到评测集。

指标设计建议

误区复盘

1. 只做一次性 benchmark，不做持续回归。
2. 只关心质量，不关心成本和时延。
3. 门禁规则没有分级，导致团队频繁“手动放行”。

结语

AI 产品进入规模化后，评测不是科研动作，而是发布治理动作。

把 Evals 接进门禁，才是从“模型可用”走向“业务可发布”的关键一步。

很多 AI 应用上线后都会遇到同一个现实：

请求量上去后，推理成本和响应时延一起上去。

如果所有请求都走大模型，再好的产品增长也会被成本吞掉。更稳的策略是：SLM + RAG + 路由。

架构图：基于复杂度的成本感知路由

时序图：一次请求如何选择 SLM 或 LLM

核心思路

1. 先做检索，把上下文压缩到“足够解决问题”的证据集合。
2. 再做复杂度打分，简单问题走 SLM，复杂问题才升级到 LLM。
3. 对每次请求记录成本和时延，持续优化阈值。

这套方案为什么有效

1. 把“大模型调用”从默认路径改成升级路径

默认 SLM 可覆盖大量标准问答和流程类任务，LLM 只处理真正复杂场景。

2. 检索先行能显著降低推理负担

高质量 RAG 让模型不必“从零推理”，减少 token 消耗和幻觉概率。

3. 路由可持续迭代

通过在线指标，你可以动态调整“简单/复杂”阈值，而不是一开始拍脑袋。

可落地的阈值设计（示例）

• query length > 500 且多意图：优先 LLM。
• 命中强结构化 FAQ：优先 SLM。
• 证据召回不足：触发 LLM + 追问。

监控看板建议

常见误区

1. 一上来就做复杂路由策略，导致系统难以调试。
2. 不做检索质量治理，只盯模型切换。
3. 没有统一指标口径，优化效果不可比较。

结语

SLM + RAG 不是“降配方案”，而是工程化提效方案。

真正成熟的团队，不会把所有请求都交给最贵模型，而是把“模型选择”变成可度量、可优化的系统能力。

很多团队做 Agent 时，第一反应是“先把工具接起来”。

这一步没错，但只做连接、不做治理，系统上线后很快会遇到三类问题：

1. 权限边界混乱。
2. 工具调用不可审计。
3. 高风险操作无法及时阻断。

MCP 的真正价值不只是“统一接口”，而是把工具调用放进可治理的系统里。

架构图：MCP 安全治理栈

时序图：一次高风险动作是如何被拦截的

为什么 MCP 场景一定要做安全治理

1. Agent 能做“动作”而不是只生成“文本”

一旦接入工单、支付、客户系统，错误动作的代价会远高于错误回答。

2. 工具越多，风险面越大

工具调用链变长时，任何一个弱环节都可能成为越权入口。

3. 责任追踪必须可落地

生产事故发生后，必须回答四个问题：

• 谁发起了动作？
• 基于什么上下文？
• 调用了哪个工具？
• 为什么被允许/被拒绝？

可直接落地的 5 个控制点

1. 权限前置：在 Gateway 层做角色和 scope 校验，不把权限逻辑散落到各工具。
2. 策略集中：用 Policy Engine 管理“谁在什么条件下能调用什么工具”。
3. 敏感动作二次确认：如退款、删改客户数据，默认人工确认。
4. 全链路审计：每次调用都打审计日志并可关联到会话。
5. 异常告警闭环：被拒绝的高风险动作也要告警，不仅仅是失败动作。

指标建议（上线后每周看）

结语

MCP 时代的工程竞争，不是“谁接得快”，而是“谁接得稳”。

把安全治理栈和连接栈一起设计，才是企业级 Agent 能持续演进的前提。

2026 年开源 Agent 生态很热，但“热”不等于“适合你”。

我看到最多的失败案例是：

• 先看 Star 数。
• 迅速 PoC。
• 三个月后接入生产系统时发现权限、审计、治理全都不够。
• 最后被迫重构。

所以这篇文章不讲“谁最火”，只讲“怎么选才不踩大坑”。

先分三种路线

路线 A：平台型（如 Dify）

适合：

• 要快速上线 MVP。
• 产品和运营要参与编排。
• 团队工程人力有限。

路线 B：RAG 引擎型（如 RAGFlow）

适合：

• 文档复杂度高。
• 对知识检索和引用质量要求高。
• 需要围绕知识资产做长期演进。

路线 C：代码型（如 smolagents）

适合：

• 研发主导。
• 需要深度定制与系统集成。
• 对可控性和可测试性要求高。

图表1：能力矩阵（实战版）

图表2：选型决策树

1
2
3
4
5
6
7
8

flowchart TD
  A["你的首要目标"] --> B{"1个月上线MVP?"}
  B -->|"是"| C["平台型优先"]
  B -->|"否"| D{"核心难点在复杂检索?"}
  D -->|"是"| E["RAG引擎型优先"]
  D -->|"否"| F{"是否需要强定制与治理?"}
  F -->|"是"| G["代码型优先"]
  F -->|"否"| C

选型评审时必须回答的 10 个问题

1. 是否支持细粒度权限控制？
2. 是否具备完整审计日志？
3. 失败时是否可回放与复盘？
4. 多环境（dev/staging/prod）隔离是否完善？
5. 升级是否有明确迁移文档？
6. 核心组件能否替换（避免锁死）？
7. 监控指标是否可接入现有体系？
8. 是否支持你的合规要求？
9. 关键路径是否可自动化测试？
10. 团队非研发角色是否可参与？

如果这 10 个问题答不清，PoC 再惊艳也别急着上生产。

图表3：常见失败模式与预防动作

技术落地策略：双轨制最稳

轨道1：业务验证轨

先用平台型快速验证业务价值：

• 1-2 周产出 MVP。
• 让业务尽快看到结果。

轨道2：核心沉淀轨

把关键能力逐步代码化：

• 权限治理。
• 关键工作流。
• 数据与日志中台。

这能兼顾速度和长期可控性。

一个可执行的选型打分卡

1
2
3
4
5
6
7
8
9

评分维度（1-5 分）：
- 上线速度
- 可观测性
- 安全合规
- 可扩展性
- 迁移成本
- 团队适配度

总分 = 速度*20% + 治理*30% + 扩展*25% + 迁移*15% + 适配*10%

不要只比功能列表，要比“全生命周期成本”。

最后结论

平台选型真正的对手，不是竞品，而是未来的复杂度。

2026 年做 Agent 项目，最稳的做法是：

• 用平台拿速度。
• 用代码拿控制。
• 用标准接口拿迁移弹性。

这样你既不会错过窗口期，也不会被框架绑死。

参考来源

• GitHub：Dify
  https://github.com/langgenius/dify
• GitHub：RAGFlow
  https://github.com/infiniflow/ragflow
• Hugging Face：smolagents
  https://huggingface.co/smolagents
• Hugging Face Blog：Introducing smolagents
  https://huggingface.co/blog/smolagents
• 知乎：RAGFlow 社区与实践总结
  https://zhuanlan.zhihu.com/p/1989766537293350627
• 哔哩哔哩：Responses API 与 Agents SDK 实战体验
  https://www.bilibili.com/video/BV1SVQEYqEXu/

专业架构图（Kroki 生成）

平台选型决策架构

生产治理时序

如果你在 2026 年还把 AI 视频当作“玩具功能”，很可能会错过内容生产方式的结构性升级。

真正变化已经不在“能不能生成视频”，而在“能不能稳定、低成本、批量地产出可用视频资产”。

多模态视频为什么会突然进入主战场

原因不是某个模型单点突破，而是整条链路被打通了：

1. 文本模型负责脚本和镜头提示。
2. 图像/视频模型负责场景素材。
3. 语音模型负责旁白与角色声音。
4. 自动化工具负责剪辑、字幕与多端适配。

这意味着内容团队第一次有机会把创作流程“工业化”。

图表1：内容生产链路的时间成本重构（示意）

效率提升不是“玄学”，而是可被流程化复制。

图表2：多模态视频流水线架构

1
2
3
4
5
6
7
8
9

flowchart LR
  A["选题池"] --> B["脚本生成"]
  B --> C["分镜模板"]
  C --> D["视频/图像生成"]
  D --> E["配音与音乐"]
  E --> F["自动剪辑"]
  F --> G["字幕与封面"]
  G --> H["多平台分发"]
  H --> I["数据回流与A/B"]

技术博主视角：真正决定上限的是“系统设计”

1. Prompt 资产化

大多数团队的问题不是不会写 Prompt，而是没有“可复用 Prompt 资产库”。

建议至少管理三层模板：

• 选题模板。
• 脚本模板。
• 镜头模板。

2. 风格一致性机制

品牌内容最怕“每条都像不同账号”。

你需要显式定义：

• 叙事语气。
• 视觉色调。
• 字幕规范。
• 封面元素。

3. 版本管理与可回放

每次发布都应记录：

• 模型版本。
• Prompt 版本。
• 关键参数。
• 发布表现。

这样才能做真正的数据驱动优化，而不是凭感觉改内容。

图表3：内容团队能力迁移

实操框架：如何在 30 天内搭出可用生产线

第 1 周：定义标准

1. 明确 3 条高频选题线。
2. 设计脚本/分镜/字幕模板。
3. 设定视觉与文案风格基线。

第 2 周：搭流程

1. 选定工具链（脚本、视频、语音、剪辑）。
2. 把流程串成自动化节点。
3. 输出第一批 10 条样本内容。

第 3 周：做评估

关注四个指标：

• 完成率。
• 返工率。
• 发布速度。
• 互动/转化指标。

第 4 周：做迭代

淘汰低效模板，保留高转化模板，形成“模板中台”。

真实风险：别让效率变成事故放大器

1. 版权风险：素材来源必须可追溯。
2. 合规风险：避免未经验证的事实陈述。
3. 品牌风险：风格漂移会拉低账号认知。
4. 平台风险：政策变化导致内容失效。

一个可直接套用的内容卡片模板

1
2
3
4
5
6
7
8
9

topic: "AI Agent 在客服场景的落地"
audience: "SaaS 创始人"
video_goal: "引流 + 私域咨询"
style: "理性、快节奏、案例驱动"
constraints:
  - no_overclaim
  - no_unverified_stats
  - keep_under_90s
cta: "评论区领取实施清单"

结论

多模态视频不是“替代创作”，而是“重构创作产线”。

未来内容团队比拼的，不是谁更会用单个工具，而是谁能把工具变成稳定可复用的系统。

参考来源

• Google Blog：Gemini 2.0 and the agentic era
  https://blog.google/technology/google-deepmind/google-gemini-ai-update-december-2024/
• 知乎：全球 AI 模型发布时间线（持续更新）
  https://www.zhihu.com/tardis/zm/art/14903006525
• 哔哩哔哩：AI 动画制作流程教学
  https://www.bilibili.com/video/BV1YHCMBpEmt/
• 哔哩哔哩：多模态视频编辑工具测评
  https://www.bilibili.com/video/BV1buLTzsEjB/

专业架构图（Kroki 生成）

多模态视频生产链路

数据回流优化闭环

“AI 会不会替代程序员”这个问题，流量很高，但决策价值很低。

技术团队真正应该问的是：

当 AI Coding Agent 能读仓库、改代码、跑测试、回写 PR 后，我们的研发流程应该怎么重构？

这才是 2026 年的核心命题。

先定义清楚：什么叫 Coding Agent

Coding Agent 与传统代码补全的差异，不是“写得更快”，而是“能独立完成一段任务闭环”。

典型能力包括：

1. 读取代码库上下文。
2. 基于约束修改多文件。
3. 自动运行测试与静态检查。
4. 根据失败日志继续修复。
5. 生成变更说明与风险提示。

图表1：研发范式迁移

图表2：Agent 融入 CI 的标准链路

1
2
3
4
5
6
7
8
9

flowchart LR
  A["Issue/需求"] --> B["Agent 产出改动"]
  B --> C["Lint + 类型检查"]
  C --> D["单元测试"]
  D --> E{"通过?"}
  E -->|"否"| B
  E -->|"是"| F["生成 PR 说明与风险列表"]
  F --> G["人类 Review"]
  G --> H["合并发布"]

为什么有些团队效果好，有些团队效果差

核心不在于模型，而在于工程底座。

底座1：测试质量

没有可靠测试，Agent 的每次改动都会变成“未知风险”。

底座2：代码规范

风格和架构混乱会让 Agent 很难做稳定改动。

底座3：任务描述质量

输入若只有一句“把这个优化下”，产出必然不可控。

图表3：团队成熟度与收益映射

实战建议：如何把 Agent 从“玩具”变成“产能”

1. 建立任务契约

每个任务至少包含：

• 目标。
• 非目标。
• 验收标准。
• 禁止修改区域。

2. 强制三道门禁

1. 类型检查。
2. 自动化测试。
3. 安全扫描（依赖与密钥）。

3. 输出可审阅的变更说明

要求 Agent 自动附带：

• 变更文件清单。
• 行为变化说明。
• 潜在回归点。
• 回滚方案。

4. 记录失败样本，持续训流程

不要只关注成功案例。失败任务才是最有价值的流程训练数据。

可复用的任务模板（示例）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# Task
目标：修复支付回调偶发重复入账

# Constraints
- 不允许修改数据库 schema
- 不允许改动公共 SDK 接口

# Acceptance
- 新增并通过对应单测
- 回调幂等逻辑覆盖重复请求场景
- 性能回归不超过 5%

# Deliverables
- 代码改动
- 失败原因分析
- 风险点与回滚说明

最容易犯的 5 个误区

1. 让 Agent 直接 push 到主分支。
2. 缺少 sandbox，放开危险命令。
3. 只看“完成速度”，忽略回归代价。
4. 没有任务分级（低风险/高风险同策略）。
5. 不做审计，出了问题无法追责与复盘。

结论

Coding Agent 的本质不是“替代程序员”，而是改变程序员的杠杆：

• 从手工执行者，转向系统设计者。
• 从代码产量竞争，转向交付质量竞争。

未来最值钱的工程师，不是写得最快的人，而是能把 AI 产能稳定接入团队系统的人。

参考来源

• OpenAI：New tools for building agents
  https://openai.com/index/new-tools-for-building-agents/
• OpenAI：Introducing AgentKit（2025-10-06）
  https://openai.com/index/introducing-agentkit/
• Anthropic Docs：MCP
  https://docs.anthropic.com/en/docs/mcp
• Hugging Face Blog：Introducing smolagents
  https://huggingface.co/blog/smolagents
• 哔哩哔哩：Responses API 与 Agent 开发实践
  https://www.bilibili.com/video/BV1m5R2YHEeC/

专业架构图（Kroki 生成）

Coding Agent + CI 架构

PR 自动化时序

过去很多 RAG 项目在 PoC 阶段表现不错，一进生产就“体验崩盘”。

典型反馈是：

• 回答看起来专业，但不解决问题。
• 能引用文档，但不能推进流程。
• 一遇到复杂请求就回避。

这说明一个事实：传统 RAG 的上限是“知识回答系统”，而业务真正要的是“任务执行系统”。

为什么 Agentic RAG 会成为 2026 主线

RAG 的价值正在从“补充知识”转向“驱动动作”。

Agentic RAG 的核心不是多加几个插件，而是让系统具备这条闭环：

识别意图 -> 获取证据 -> 形成判断 -> 执行动作 -> 回写结果 -> 复盘评估

图表1：传统 RAG 与 Agentic RAG 的本质差异

图表2：生产级 Agentic RAG 架构

1
2
3
4
5
6
7
8
9
10

flowchart TD
  A["用户请求"] --> B["Intent Classifier"]
  B --> C["Retriever: 混合检索"]
  C --> D["Reranker: 证据重排"]
  D --> E["Planner: 动作规划"]
  E --> F["Tool Executor: 调用系统"]
  F --> G["Verifier: 结果与证据校验"]
  G --> H{"满足成功条件?"}
  H -->|"否"| E
  H -->|"是"| I["Answer + Action Log"]

工程拆解：四个关键模块

1. 检索层：混合检索是底线

只做向量检索，往往会漏掉关键词精确匹配场景。建议采用：

• 关键词检索（BM25 类）处理精确术语。
• 向量检索处理语义匹配。
• 重排模型做最终证据排序。

2. 规划层：把“答案”升级成“动作计划”

同一个问题，系统要先判断：

• 只是答复就够？
• 还是需要触发外部动作？
• 动作是否需要人工确认？

3. 执行层：工具契约要强约束

每个工具都要定义：

• 参数 schema。
• 幂等键。
• 重试策略。
• 超时与回滚。

4. 评估层：建立线上可观测指标

不要只看离线准确率，必须看线上：

• 完成率（Task Completion Rate）。
• 人工接管率（Escalation Rate）。
• 错误分布（检索错/规划错/执行错）。
• 单任务成本（Cost per Task）。

图表3：从 PoC 到生产的进阶路线

代码层建议：先做结构化输出

1
2
3
4
5
6
7
8
9
10
11
12

{
  "intent": "refund_request",
  "evidence": [
    {"doc_id": "policy_2026_03", "score": 0.91}
  ],
  "action_plan": [
    {"tool": "ticket.add_comment", "args": {"text": "..."}},
    {"tool": "refund.create_case", "args": {"order_id": "A123"}}
  ],
  "confidence": 0.86,
  "fallback": "human_review"
}

结构化输出的价值在于：可审计、可测试、可回放。

常见失败模式（真实项目高频）

1. 文档切片策略粗糙，导致证据缺上下文。
2. 重排缺失，召回看似高但命中质量差。
3. 让模型直接拼工具参数，缺 schema 校验。
4. 没有失败兜底，最终用户体验断崖下跌。

落地清单：一周可推进版本

1. 先定义 3 个高频任务，不贪多。
2. 给每个任务写成功条件和回退策略。
3. 检索链路接入重排与证据回显。
4. 工具调用强制 schema 校验。
5. 每周复盘错误归因，持续迭代。

结语

RAG 不会消失，但“只会回答的 RAG”会越来越难进入核心流程。未来两年，真正有壁垒的是：

• 证据可靠。
• 动作可控。
• 成本可衡量。

这三点加在一起，才是 Agentic RAG 的护城河。

参考来源

• OpenAI：New tools for building agents（2025-03-11）
  https://openai.com/index/new-tools-for-building-agents/
• GitHub：RAGFlow
  https://github.com/infiniflow/ragflow
• 知乎：RAG 与企业检索实战讨论
  https://zhuanlan.zhihu.com/p/1955668804727207627
• 知乎：从 RAG 到 KAG 的演进
  https://zhuanlan.zhihu.com/p/1977739890704798545
• 哔哩哔哩：Agentic RAG 全流程实战
  https://www.bilibili.com/video/BV1ZiEEzLE3X/

专业架构图（Kroki 生成）

Agentic RAG 生产流水线

Agentic RAG 执行时序