概念对比

别问谁更先进，先问谁更适合。

把争论还原成具体条件。每组对比都给出选择问题、适用场景和一句可执行的结论。

需要现成智能体结构，还是细粒度流程控制？

LangChain与LangGraph

不同抽象层次，可组合

LangChain复用模型工具接口与常见循环

LangGraph自定义节点、分支、审批和恢复

选择建议：常见循环先评估 LangChain；需要明确状态与长任务恢复时研究 LangGraph。简单需求也可以直接调用模型。

先确认约束: 先判断只需常见模型工具循环，还是要自行定义状态、分支与暂停恢复。
最小验证: 用同一业务任务比较接入代码、失败恢复和调试工作量，不以代码行数单独决策。
边界与反例: LangChain 智能体构建于 LangGraph 之上；LangGraph 也可以独立使用。

编辑建议 · 事实依据见词条LangChain · 来源与核验记录 LangGraph · 来源与核验记录

知识从哪里来，模型怎样继续训练？

知识蒸馏与微调

监督来源与训练方式，可重叠

知识蒸馏迁移教师在目标任务中的表现

微调用任务数据调整已有模型行为

选择建议：蒸馏强调教师提供监督；微调强调已有模型继续训练。根据任务和评测设计组合，而不是按名称选高低。

先确认约束: 先确认监督信号是否来自教师，以及是否在已有模型上继续训练。
最小验证: 在独立留出集上比较教师、原始学生和训练后学生的质量、成本及关键错误。
边界与反例: 用教师生成的答案微调学生可以同时属于蒸馏和微调，二者不是互斥选项。

编辑建议 · 事实依据见词条Knowledge Distillation · 来源与核验记录 Fine-tuning · 来源与核验记录

任务路径是否能预先写清？

Agent与Workflow

可组合的控制方式

Agent开放目标、动态环境、需要自主选择工具

Workflow固定步骤、稳定分支、强调可预测性

选择建议：能写清就先用 Workflow；只有中间结果持续改变下一步时，再把控制权交给 Agent。

先确认约束: 先判断步骤能否预先确定，再比较失败恢复、延迟和人工介入成本。
最小验证: 用同一组真实任务比较固定流程与自主循环，记录完成率、调用次数与失败原因。
边界与反例: 动态任务也可能包含固定子流程；允许自主决策不等于允许无限重试。

编辑建议 · 事实依据见词条Agent · 来源与核验记录 Workflow · 来源与核验记录

资料应该先筛选，还是一次全读？

RAG与长上下文

可组合的资料组织方式

RAG大规模、常更新、需追溯的资料库

长上下文单份长文档、代码库、整体综合任务

选择建议：资料持续增长或需要引用时优先 RAG；材料有限且整体关系重要时可直接用长上下文，也可以组合。

先确认约束: 比较资料量、更新频率、上下文容量、延迟和每次请求成本。
最小验证: 对同一组问题分别提供全文和检索片段，检查答案依据、遗漏与调用成本。
边界与反例: 需要引用并不意味着只能用 RAG；长上下文同样需要验证引用是否正确。

编辑建议 · 事实依据见词条RAG · 来源与核验记录 Long Context · 来源与核验记录

需要新知识，还是稳定行为？

RAG与Fine-tuning

解决不同问题，可组合

RAG外部事实、私有资料、最新内容

Fine-tuning行为模式、输出风格、专项能力

选择建议：更新事实用 RAG；改变风格、格式或专项能力才考虑微调。没有评测集时不要急着微调。

先确认约束: 先分清缺少事实依据还是行为不稳定，并确认有可重复的评测样本。
最小验证: 分别提供正确资料和改进指令，观察错误是否减少，再判断是否需要训练。
边界与反例: 事实与行为问题可能同时存在，不能仅凭一次回答就决定微调。

编辑建议 · 事实依据见词条RAG · 来源与核验记录 Fine-tuning · 来源与核验记录

是连接协议，还是模型发起动作？

MCP与Tool Calling

不同层次，可配合使用

MCP跨客户端复用、标准化连接

Tool Calling单个应用内让模型选择函数

选择建议：Tool Calling 是模型提出结构化调用；MCP 规范了应用如何发现并连接可复用的工具、资源与提示。

先确认约束: 先确认是否需要跨客户端复用连接，再明确认证、权限与执行责任。
最小验证: 沿一次调用标出模型提议、应用校验、协议传输和实际执行的位置。
边界与反例: 采用连接协议不会自动保证模型选对工具，也不会替代应用的权限检查。

编辑建议 · 事实依据见词条MCP · 来源与核验记录 Tool Calling · 来源与核验记录

是在写指令，还是组织整个信息环境？

Prompt Engineering与Context Engineering

局部与整体

Prompt Engineering单次任务、指令与示例优化

Context Engineering多步系统、动态资料与状态管理

选择建议：Prompt Engineering 改善任务表达；Context Engineering 还管理资料、工具、历史、记忆与中间状态。

先确认约束: 先判断失败源于指令表达，还是资料、工具、历史与状态的组织。
最小验证: 固定模型与问题，一次只调整指令或资料输入，记录效果差异。
边界与反例: 增加上下文不必然改善结果；重复、冲突和无关信息也需要处理。

编辑建议 · 事实依据见词条Prompt Engineering · 来源与核验记录 Context Engineering · 来源与核验记录

保存的是经历，还是可维护事实？

Memory与Knowledge Base

职责不同，可共享存储设施

Memory偏好、任务进展、经验摘要

Knowledge Base文档、政策、产品资料、组织知识

选择建议：Memory 面向某个用户或 Agent 的历史与状态；知识库面向可治理、可共享、可更新的事实来源。

先确认约束: 明确数据属于谁、有效期、更新方式，以及查看和纠正权限。
最小验证: 把样例数据分成用户偏好、任务状态和组织文档，分别写出更新与删除规则。
边界与反例: 同一数据库可以承载多类数据，存储位置本身不能决定概念边界。

编辑建议 · 事实依据见词条Memory · 来源与核验记录 Knowledge Base · 来源与核验记录