2023 年用 LangChain 构建一个 Agent 需要写大量「脚手架」代码路由逻辑判断用户意图决定调哪个 Chain工具选择根据任务类型选择合适的工具输出解析用 OutputParser 把模型的文本输出转成结构化数据重试逻辑模型返回格式错误时自动重试提示模板用 PromptTemplate 管理复杂的 Prompt 拼接这些功能LangChain 都提供了封装好的抽象。2026 年如果你用 Claude 3.7 或 GPT-4o 直接调用 API大多数情况下不需要这些封装——模型自己就会做。这就是框架层坍缩。一、什么是框架层坍缩「坍缩」不是说框架消亡了。是说框架过去承担的功能正在被转移到两个方向一部分向下转移到模型层——模型变聪明了以前需要代码来实现的逻辑现在模型原生就能做。一部分向上转移到 Harness 层——真正属于系统工程的部分从框架里分离出来成为独立的 Harness 关注点。中间那层「框架胶水代码」正在萎缩。二、已被模型吸收的功能约 80%2.1 路由决策2023 年的做法写一个 Router Chain根据用户意图的关键词或分类模型决定把请求路由到哪个处理链。2026 年的做法直接告诉模型有哪些能力让它自己决定用哪个# 2023 年需要显式路由逻辑 from langchain.chains.router import MultiPromptChain chains { coding: coding_chain, writing: writing_chain, analysis: analysis_chain, } router MultiPromptChain(router_chain..., destination_chainschains) result router.run(user_input) # 2026 年模型自己路由 response client.messages.create( modelclaude-opus-4-7, system你有以下能力 - 代码编写和审查写代码、debug、代码解释 - 文档写作技术文档、说明书、报告 - 数据分析统计、可视化建议、洞察 根据用户请求选择合适的能力完成任务。, messages[{role: user, content: user_input}] ) # 模型自己判断该做什么不需要路由逻辑2.2 工具选择以前需要手动实现工具选择逻辑或者用框架的 Agent Executor 来管理工具调用顺序。现在模型的 Function Calling / Tool Use 原生支持工具选择——给模型一组工具它自己决定调哪个、什么时候调、调几次tools [ { name: read_file, description: 读取文件内容, input_schema: {type: object, properties: {path: {type: string}}} }, { name: search_web, description: 搜索网络信息, input_schema: {type: object, properties: {query: {type: string}}} }, { name: run_code, description: 执行 Python 代码, input_schema: {type: object, properties: {code: {type: string}}} } ] # 模型自己决定用哪个工具、按什么顺序 response client.messages.create( modelclaude-opus-4-7, toolstools, messages[{role: user, content: 分析 data.csv 里的销售趋势}] ) # 模型会先 read_file(data.csv)然后 run_code 做分析 # 不需要任何手动编排逻辑2.3 输出解析以前需要 OutputParser 把Answer: 42这样的文本提取出42或者把 Markdown 表格转成 Python 字典。现在模型原生支持结构化输出import anthropic from pydantic import BaseModel class CodeReviewResult(BaseModel): passed: bool issues: list[str] severity: str suggestions: list[str] # Claude 直接输出符合 schema 的 JSON不需要解析 response client.messages.create( modelclaude-sonnet-4-6, messages[{role: user, content: f审查以下代码\n{code}}], tools[{ name: submit_review, description: 提交代码审查结果, input_schema: CodeReviewResult.model_json_schema() }], tool_choice{type: tool, name: submit_review} # 强制调用这个工具输出结构化结果 ) # 直接得到结构化结果无需解析 result CodeReviewResult(**response.content[0].input)2.4 重试逻辑以前当模型输出格式不对需要手写 retry 循环或者用框架的 RetryParser。现在模型更可靠格式错误率大幅下降即使出错可以直接在对话里纠正def get_structured_output(prompt: str, schema: type) - dict: messages [{role: user, content: prompt}] for attempt in range(3): # 最多 3 次通常第一次就对 response client.messages.create( modelclaude-sonnet-4-6, messagesmessages, tools[{name: output, input_schema: schema.model_json_schema()}], tool_choice{type: tool, name: output} ) try: return schema(**response.content[0].input) except Exception as e: # 把错误反馈给模型让它自己修正 messages.append({role: assistant, content: response.content}) messages.append({role: user, content: f输出格式有误{e}请重新输出}) raise RuntimeError(多次尝试后仍无法获得正确格式)三、仍在 Harness 层的部分约 20%模型变聪明可以替代很多胶水代码但有四类问题再聪明的模型也解决不了——这些是 Harness 不可替代的部分。3.1 持久化模型没有持久记忆。对话结束上下文消失。跨会话的状态——任务进度、用户偏好、项目背景——必须由 Harness 管理文件系统CLAUDE.md、AGENTS.md、progress.txt——人类可读的持久化数据库结构化状态、用户数据、任务历史Git代码变更的版本控制也是 Agent 操作的审计日志这不会被模型替代。模型可以读写文件但决定「什么状态需要持久化、怎么组织、何时清理」是 Harness 设计问题。3.2 确定性重放模型是概率性的同样的输入可能产生不同的输出。对于需要「从断点恢复」的长程任务必须有确定性的检查点机制每完成一个关键步骤把状态写入检查点任务失败时从最近的检查点重启而不是从头来人工审查时能精确复现某次执行的完整路径LangGraph 的 Checkpoint 机制是目前这类需求最成熟的解决方案。这不是模型能力问题是工程基础设施问题。3.3 可观测性上一篇讲了 Agent 可观测性——Traces、Metrics、Logs。这些不是模型能力是系统基础设施模型不能给自己追踪 Token 用量模型不知道自己这次调用花了多少钱模型不能在失败时自动报警这些是 Harness 层的职责无论模型多聪明都不会改变。3.4 错误恢复有一类错误是模型层面无法处理的——基础设施错误API 限流429 Too Many Requests网络超时OOM内存溢出依赖服务宕机处理这类错误需要 Harness 层的重试策略、断路器、降级方案。模型不知道外部世界发生了什么它只能生成 token。import anthropic from tenacity import retry, stop_after_attempt, wait_exponential retry( stopstop_after_attempt(5), waitwait_exponential(multiplier1, min4, max60), retrylambda exc: isinstance(exc, (anthropic.RateLimitError, anthropic.APITimeoutError)) ) def call_with_retry(messages: list) - str: Harness 层处理基础设施错误模型层不感知 response client.messages.create( modelclaude-opus-4-7, max_tokens4096, messagesmessages ) return response.content[0].text四、Framework vs Harness 的本质区别理解了什么被吸收、什么留下来就能看清楚 Framework 和 Harness 的本质区别Framework 解决的是「开发者如何构建 Agent」的问题——抽象、封装、减少样板代码。当模型变强开发者需要的抽象减少框架的价值自然下降。Harness 解决的是「Agent 如何在生产中安全运行」的问题——持久化、可观测性、故障隔离、成本控制。这些不随模型能力变化而消失生产系统永远需要这些。这两件事的目标受众不同Framework 服务开发者Harness 服务运行中的 Agent。五、各框架的进化方向既然框架层在坍缩各框架是怎么应对的5.1 LangChain → LangGraphLangChain 最初的定位是「AI 应用开发框架」提供大量封装好的 Chain、Agent、Memory 抽象。随着模型能力增强这些抽象的必要性下降。LangChain 的应对把重心转移到LangGraph——专注于工作流编排状态机、检查点、持久化而不是封装模型调用。这个转型方向对LangGraph 提供的正是「仍在 Harness 层」的那部分功能不会被模型替代。5.2 CrewAI → 企业级 HarnessCrewAI 从角色编排框架演进正在向企业级 Harness 平台发展——加入更多生产特性任务追踪、成本监控、企业权限管理、合规报告。这个方向也对把框架定位从「帮你写 Agent」变成「帮你在生产中跑 Agent」。5.3 AutoGen → MAF微软统一框架Microsoft 把 AutoGen 和 Semantic Kernel 合并构建MAFMicrosoft Agent Framework——不再只是对话式多 Agent而是覆盖从 Agent 开发到企业级部署的完整栈。六、轻量 Harness 方法把规则写进提示框架层坍缩还催生了一种新的 Harness 模式Markdown-based Harness——把 Harness 规则直接写进系统提示或配置文件而不是用代码实现。6.1 AGENTS.md 模式Codex 推广的约定在项目根目录放一个 AGENTS.md 文件Agent 在开始任务前自动读取# AGENTS.md ## 工作约束 - 修改代码前先运行测试确认当前基线通过 - 每完成一个子任务git commit 一次commit message 格式feat/fix/refactor: 简短描述 - 不要修改 .env 和 credentials/ 目录下的任何文件 - 如果不确定停下来问不要猜 ## 代码规范 - Python 3.11使用 type hints - 单行不超过 88 字符black 格式化标准 - 所有公共函数必须有 docstring ## 测试要求 - 修改任何功能代码后新增或更新对应测试 - 运行命令pytest tests/ -v --tbshort - 覆盖率目标核心模块 90% ## 禁止操作 - 不执行 DROP TABLE, DELETE FROM无 WHERE 条件 - 不 push 到 main 分支只能提 PR - 不在代码里硬编码 API key 或密码6.2 CLAUDE.md 模式Claude Code 的约定项目级别的持久化记忆和约束Claude Code 在每个会话开始时自动读取。这种方法的优势零框架依赖只是一个文件任何 Agent 都能读人类可读可编辑不需要改代码就能调整 Agent 行为版本控制友好和代码一起提交有完整的修改历史限制只能表达「静态规则」动态的流程控制条件分支、循环、检查点仍然需要代码。七、什么时候用框架什么时候不用有了前面的分析可以给出一个实用的决策框架7.1 不需要框架的场景单次 LLM 调用即使很复杂简单的工具调用序列不需要复杂编排原型验证阶段快速实验想法这些场景直接用 SDK 就好——anthropic.messages.create()干净、可控、没有额外依赖。7.2 需要 LangGraph 的场景工作流有复杂的条件分支成功/失败走不同路径需要跨会话的检查点和状态恢复有人工审批节点的长程任务7.3 需要 CrewAI 的场景明确的角色分工代码生成 测试 审查需要快速上手多 Agent 编排已有 CrewAI 技术栈的团队7.4 不需要任何框架但需要 Harness 的场景生产部署可观测性、成本监控、错误恢复——这些用基础设施工具Langfuse、Helicone不需要 Agent 框架长程任务自己实现检查点不一定要上 LangGraph八、反直觉的结论更少的框架依赖更好的 Harness一个经常被忽视的事实框架引入了依赖、学习成本、升级风险。当 LangChain 从 0.x 升到 1.xAPI 全面破坏性变更依赖它的项目要花大量时间迁移。这不是批评 LangChain——任何快速演进的框架都会这样。成熟的团队正在走向「最小框架依赖」的方向直接用 Anthropic/OpenAI SDK只在真正需要时引入 LangGraph状态机编排Harness 层用基础设施工具不是框架Langfuse 做可观测性Helicone 做成本追踪这不是反框架是认清楚框架的边界——在它真正有价值的地方用它在其他地方用更简单的方案。# 2026 年的「最小框架依赖」Agent 架构 import anthropic # 直接用 SDK from langfuse.decorators import observe # 只引入可观测性工具 observe() # Harness追踪 def run_agent(task: str) - str: client anthropic.Anthropic() messages [{role: user, content: task}] while True: response client.messages.create( modelclaude-opus-4-7, max_tokens4096, toolsTOOLS, # 工具列表 messagesmessages ) if response.stop_reason end_turn: return response.content[0].text # 处理工具调用模型自己决定用哪个工具 tool_results execute_tool_calls(response.content) messages.append({role: assistant, content: response.content}) messages.append({role: user, content: tool_results}) # Harness检查点每次工具调用后保存状态 save_checkpoint(messages)这段代码没有 LangChain没有 CrewAI没有 AutoGen但它有 Harness可观测性追踪、工具执行隔离、检查点保存。这就是框架层坍缩之后「真正的 Harness」长什么样。参考文献框架层坍缩——LangChain 们正在被重新定义
【学习笔记】框架层坍缩——LangChain 们正在被重新定义-14/15
2023 年用 LangChain 构建一个 Agent 需要写大量「脚手架」代码路由逻辑判断用户意图决定调哪个 Chain工具选择根据任务类型选择合适的工具输出解析用 OutputParser 把模型的文本输出转成结构化数据重试逻辑模型返回格式错误时自动重试提示模板用 PromptTemplate 管理复杂的 Prompt 拼接这些功能LangChain 都提供了封装好的抽象。2026 年如果你用 Claude 3.7 或 GPT-4o 直接调用 API大多数情况下不需要这些封装——模型自己就会做。这就是框架层坍缩。一、什么是框架层坍缩「坍缩」不是说框架消亡了。是说框架过去承担的功能正在被转移到两个方向一部分向下转移到模型层——模型变聪明了以前需要代码来实现的逻辑现在模型原生就能做。一部分向上转移到 Harness 层——真正属于系统工程的部分从框架里分离出来成为独立的 Harness 关注点。中间那层「框架胶水代码」正在萎缩。二、已被模型吸收的功能约 80%2.1 路由决策2023 年的做法写一个 Router Chain根据用户意图的关键词或分类模型决定把请求路由到哪个处理链。2026 年的做法直接告诉模型有哪些能力让它自己决定用哪个# 2023 年需要显式路由逻辑 from langchain.chains.router import MultiPromptChain chains { coding: coding_chain, writing: writing_chain, analysis: analysis_chain, } router MultiPromptChain(router_chain..., destination_chainschains) result router.run(user_input) # 2026 年模型自己路由 response client.messages.create( modelclaude-opus-4-7, system你有以下能力 - 代码编写和审查写代码、debug、代码解释 - 文档写作技术文档、说明书、报告 - 数据分析统计、可视化建议、洞察 根据用户请求选择合适的能力完成任务。, messages[{role: user, content: user_input}] ) # 模型自己判断该做什么不需要路由逻辑2.2 工具选择以前需要手动实现工具选择逻辑或者用框架的 Agent Executor 来管理工具调用顺序。现在模型的 Function Calling / Tool Use 原生支持工具选择——给模型一组工具它自己决定调哪个、什么时候调、调几次tools [ { name: read_file, description: 读取文件内容, input_schema: {type: object, properties: {path: {type: string}}} }, { name: search_web, description: 搜索网络信息, input_schema: {type: object, properties: {query: {type: string}}} }, { name: run_code, description: 执行 Python 代码, input_schema: {type: object, properties: {code: {type: string}}} } ] # 模型自己决定用哪个工具、按什么顺序 response client.messages.create( modelclaude-opus-4-7, toolstools, messages[{role: user, content: 分析 data.csv 里的销售趋势}] ) # 模型会先 read_file(data.csv)然后 run_code 做分析 # 不需要任何手动编排逻辑2.3 输出解析以前需要 OutputParser 把Answer: 42这样的文本提取出42或者把 Markdown 表格转成 Python 字典。现在模型原生支持结构化输出import anthropic from pydantic import BaseModel class CodeReviewResult(BaseModel): passed: bool issues: list[str] severity: str suggestions: list[str] # Claude 直接输出符合 schema 的 JSON不需要解析 response client.messages.create( modelclaude-sonnet-4-6, messages[{role: user, content: f审查以下代码\n{code}}], tools[{ name: submit_review, description: 提交代码审查结果, input_schema: CodeReviewResult.model_json_schema() }], tool_choice{type: tool, name: submit_review} # 强制调用这个工具输出结构化结果 ) # 直接得到结构化结果无需解析 result CodeReviewResult(**response.content[0].input)2.4 重试逻辑以前当模型输出格式不对需要手写 retry 循环或者用框架的 RetryParser。现在模型更可靠格式错误率大幅下降即使出错可以直接在对话里纠正def get_structured_output(prompt: str, schema: type) - dict: messages [{role: user, content: prompt}] for attempt in range(3): # 最多 3 次通常第一次就对 response client.messages.create( modelclaude-sonnet-4-6, messagesmessages, tools[{name: output, input_schema: schema.model_json_schema()}], tool_choice{type: tool, name: output} ) try: return schema(**response.content[0].input) except Exception as e: # 把错误反馈给模型让它自己修正 messages.append({role: assistant, content: response.content}) messages.append({role: user, content: f输出格式有误{e}请重新输出}) raise RuntimeError(多次尝试后仍无法获得正确格式)三、仍在 Harness 层的部分约 20%模型变聪明可以替代很多胶水代码但有四类问题再聪明的模型也解决不了——这些是 Harness 不可替代的部分。3.1 持久化模型没有持久记忆。对话结束上下文消失。跨会话的状态——任务进度、用户偏好、项目背景——必须由 Harness 管理文件系统CLAUDE.md、AGENTS.md、progress.txt——人类可读的持久化数据库结构化状态、用户数据、任务历史Git代码变更的版本控制也是 Agent 操作的审计日志这不会被模型替代。模型可以读写文件但决定「什么状态需要持久化、怎么组织、何时清理」是 Harness 设计问题。3.2 确定性重放模型是概率性的同样的输入可能产生不同的输出。对于需要「从断点恢复」的长程任务必须有确定性的检查点机制每完成一个关键步骤把状态写入检查点任务失败时从最近的检查点重启而不是从头来人工审查时能精确复现某次执行的完整路径LangGraph 的 Checkpoint 机制是目前这类需求最成熟的解决方案。这不是模型能力问题是工程基础设施问题。3.3 可观测性上一篇讲了 Agent 可观测性——Traces、Metrics、Logs。这些不是模型能力是系统基础设施模型不能给自己追踪 Token 用量模型不知道自己这次调用花了多少钱模型不能在失败时自动报警这些是 Harness 层的职责无论模型多聪明都不会改变。3.4 错误恢复有一类错误是模型层面无法处理的——基础设施错误API 限流429 Too Many Requests网络超时OOM内存溢出依赖服务宕机处理这类错误需要 Harness 层的重试策略、断路器、降级方案。模型不知道外部世界发生了什么它只能生成 token。import anthropic from tenacity import retry, stop_after_attempt, wait_exponential retry( stopstop_after_attempt(5), waitwait_exponential(multiplier1, min4, max60), retrylambda exc: isinstance(exc, (anthropic.RateLimitError, anthropic.APITimeoutError)) ) def call_with_retry(messages: list) - str: Harness 层处理基础设施错误模型层不感知 response client.messages.create( modelclaude-opus-4-7, max_tokens4096, messagesmessages ) return response.content[0].text四、Framework vs Harness 的本质区别理解了什么被吸收、什么留下来就能看清楚 Framework 和 Harness 的本质区别Framework 解决的是「开发者如何构建 Agent」的问题——抽象、封装、减少样板代码。当模型变强开发者需要的抽象减少框架的价值自然下降。Harness 解决的是「Agent 如何在生产中安全运行」的问题——持久化、可观测性、故障隔离、成本控制。这些不随模型能力变化而消失生产系统永远需要这些。这两件事的目标受众不同Framework 服务开发者Harness 服务运行中的 Agent。五、各框架的进化方向既然框架层在坍缩各框架是怎么应对的5.1 LangChain → LangGraphLangChain 最初的定位是「AI 应用开发框架」提供大量封装好的 Chain、Agent、Memory 抽象。随着模型能力增强这些抽象的必要性下降。LangChain 的应对把重心转移到LangGraph——专注于工作流编排状态机、检查点、持久化而不是封装模型调用。这个转型方向对LangGraph 提供的正是「仍在 Harness 层」的那部分功能不会被模型替代。5.2 CrewAI → 企业级 HarnessCrewAI 从角色编排框架演进正在向企业级 Harness 平台发展——加入更多生产特性任务追踪、成本监控、企业权限管理、合规报告。这个方向也对把框架定位从「帮你写 Agent」变成「帮你在生产中跑 Agent」。5.3 AutoGen → MAF微软统一框架Microsoft 把 AutoGen 和 Semantic Kernel 合并构建MAFMicrosoft Agent Framework——不再只是对话式多 Agent而是覆盖从 Agent 开发到企业级部署的完整栈。六、轻量 Harness 方法把规则写进提示框架层坍缩还催生了一种新的 Harness 模式Markdown-based Harness——把 Harness 规则直接写进系统提示或配置文件而不是用代码实现。6.1 AGENTS.md 模式Codex 推广的约定在项目根目录放一个 AGENTS.md 文件Agent 在开始任务前自动读取# AGENTS.md ## 工作约束 - 修改代码前先运行测试确认当前基线通过 - 每完成一个子任务git commit 一次commit message 格式feat/fix/refactor: 简短描述 - 不要修改 .env 和 credentials/ 目录下的任何文件 - 如果不确定停下来问不要猜 ## 代码规范 - Python 3.11使用 type hints - 单行不超过 88 字符black 格式化标准 - 所有公共函数必须有 docstring ## 测试要求 - 修改任何功能代码后新增或更新对应测试 - 运行命令pytest tests/ -v --tbshort - 覆盖率目标核心模块 90% ## 禁止操作 - 不执行 DROP TABLE, DELETE FROM无 WHERE 条件 - 不 push 到 main 分支只能提 PR - 不在代码里硬编码 API key 或密码6.2 CLAUDE.md 模式Claude Code 的约定项目级别的持久化记忆和约束Claude Code 在每个会话开始时自动读取。这种方法的优势零框架依赖只是一个文件任何 Agent 都能读人类可读可编辑不需要改代码就能调整 Agent 行为版本控制友好和代码一起提交有完整的修改历史限制只能表达「静态规则」动态的流程控制条件分支、循环、检查点仍然需要代码。七、什么时候用框架什么时候不用有了前面的分析可以给出一个实用的决策框架7.1 不需要框架的场景单次 LLM 调用即使很复杂简单的工具调用序列不需要复杂编排原型验证阶段快速实验想法这些场景直接用 SDK 就好——anthropic.messages.create()干净、可控、没有额外依赖。7.2 需要 LangGraph 的场景工作流有复杂的条件分支成功/失败走不同路径需要跨会话的检查点和状态恢复有人工审批节点的长程任务7.3 需要 CrewAI 的场景明确的角色分工代码生成 测试 审查需要快速上手多 Agent 编排已有 CrewAI 技术栈的团队7.4 不需要任何框架但需要 Harness 的场景生产部署可观测性、成本监控、错误恢复——这些用基础设施工具Langfuse、Helicone不需要 Agent 框架长程任务自己实现检查点不一定要上 LangGraph八、反直觉的结论更少的框架依赖更好的 Harness一个经常被忽视的事实框架引入了依赖、学习成本、升级风险。当 LangChain 从 0.x 升到 1.xAPI 全面破坏性变更依赖它的项目要花大量时间迁移。这不是批评 LangChain——任何快速演进的框架都会这样。成熟的团队正在走向「最小框架依赖」的方向直接用 Anthropic/OpenAI SDK只在真正需要时引入 LangGraph状态机编排Harness 层用基础设施工具不是框架Langfuse 做可观测性Helicone 做成本追踪这不是反框架是认清楚框架的边界——在它真正有价值的地方用它在其他地方用更简单的方案。# 2026 年的「最小框架依赖」Agent 架构 import anthropic # 直接用 SDK from langfuse.decorators import observe # 只引入可观测性工具 observe() # Harness追踪 def run_agent(task: str) - str: client anthropic.Anthropic() messages [{role: user, content: task}] while True: response client.messages.create( modelclaude-opus-4-7, max_tokens4096, toolsTOOLS, # 工具列表 messagesmessages ) if response.stop_reason end_turn: return response.content[0].text # 处理工具调用模型自己决定用哪个工具 tool_results execute_tool_calls(response.content) messages.append({role: assistant, content: response.content}) messages.append({role: user, content: tool_results}) # Harness检查点每次工具调用后保存状态 save_checkpoint(messages)这段代码没有 LangChain没有 CrewAI没有 AutoGen但它有 Harness可观测性追踪、工具执行隔离、检查点保存。这就是框架层坍缩之后「真正的 Harness」长什么样。参考文献框架层坍缩——LangChain 们正在被重新定义
