企业官网建设流程全解析

做了8个月Agent开发，中间有很长一段时间我是懵的。LangChain的文档翻了好几遍，AutoGen的例子跑通了几个，但真要我从零设计一个Agent应用，脑子里还是乱成一团。直到有一天我把自己写的代码和主流框架的源码放在一起对比，才突然意识到：Agent开发的复杂度不在于某个API怎么调，而在于这些能力被放在了不同的层级上。没看懂层级之前，所有的教程、框架、热词都是散的；看懂之后，LangChain、LlamaIndex、CrewAI这些名字才有了各自的位置。

这篇文章想把“框架层级”这件事讲透。不是概念层面的泛泛而谈，而是结合我这8个月的实战路径，从踩坑、选型、搭工作流到准备面试的全过程，给后来的人一条能直接上手的认知地图。如果你正被各种Agent框架淹没，或者刚入行不知道怎么规划学习路线，这篇应该能帮你省下不少时间。

1. 从“调API”到“写智能体”：我的理解拐点

1.1 最初踩的坑：把框架当万能工具箱

我接触Agent开发的第一周，最先干的事就是把当时热门的框架全装了一遍。LangChain、LlamaIndex、AutoGen、CrewAI，一个一个跑demo。跑通了之后信心爆棚，觉得自己已经会Agent开发了。但真的接到第一个需求时——一个企业内部的知识库问答Agent——我连从哪个框架下手都不知道。

我当时犯的最大错误，是把框架当成一个“什么都能干”的工具箱。遇到需求就找一个看起来最接近的抽象类往里套，套不进去就换一个框架。结果就是在LangChain里写了一半，发现它的Tool调用封装太绕；转去LlamaIndex又发现它主打的是RAG索引，业务逻辑还是要自己在外面写。折腾了半个月，项目进展几乎为零，每天的有效产出就是跑通一个demo。

后来我把几个框架的同类型代码并排打印出来看，才看出门道。LangChain和LlamaIndex的代码量差别其实没那么大，关键是它们把代码组织在了不同的层级上。LangChain的重心在编排和链式调用，LlamaIndex的重心在检索和索引，CrewAI的重心在角色分工和协作流程。如果我连自己要把代码写在哪个层级都不知道，框架当然帮不了我。

1.2 拐点：从代码结构看层级

真正让我想明白的是一段我自己写的、没用什么框架的Agent代码。那时候我试着用纯Python加OpenAI的函数调用接口，写一个能查数据库、能发邮件的“小秘书”。代码拆成了四层：最下面是对模型API的封装，中间是工具的注册和调用逻辑，再往上是任务规划和状态管理，最外层才是循环执行的入口。

写完之后我再回头看LangChain的AgentExecutor，一下就通了。它干的事情就是把我的这套流程标准化：模型对话循环、工具调用的触发与回传、中间状态的保存，全部做成了统一的抽象。你说它复杂吗？代码量确实大，但层级是清晰的。之前觉得复杂，是因为我拿着一个上层的抽象，试图去理解所有下层的细节，那当然会晕。

如果你也在学Agent开发，我的建议是：不求快、不追新，先把一次“模型—工具—模型”的完整循环用原生代码写一遍。这几十行代码带给你的理解，比你刷十个框架demo都有用。

这节课之后，我给自己定了一个原则：先画层级图，再选框架。所有需求到我手上，第一件事不是问用哪个框架，而是问这个能力应该放在哪一层。

2. 实践中总结的Agent框架四层模型

我按自己实战中用到的能力，把Agent框架拆成四个层级。这个分法不一定学术，但特别实用，因为每一层对应着一类你需要独立解决的问题。

2.1 模型层是底座，但别只盯模型

最底层是模型层，也就是LLM本身。这一层的核心能力是“对话理解与生成”，但真正决定Agent上限的，其实是大模型对结构化的支持，最典型的就是Function Calling（函数调用）。我用四个月才彻底搞明白，Agent和普通聊天机器人最本质的区别就落在这里。

普通聊天机器人只需要生成文本，而Agent需要让模型输出一个可执行的指令，比如“调用search_news(query='人工智能')”或者“调用send_email(to='xxx', content='...')”。模型要能在正常的对话里识别出这个意图，并且按规定的JSON格式输出参数。哪个模型在这件事上做得稳，哪个就更适合做Agent底座。

我实测过几个主流模型的函数调用表现，差异非常明显。有的模型在函数定义较多时，会出现参数缺漏或格式错乱的情况；有的模型在简单场景下表现很好，一旦函数定义超过20个就开始“选择困难”。所以我在选型上有一个很实际的建议：先把你的工具函数定义好，再用真实数据对模型做一轮“函数调用压力测试”，不要只看榜单分数。

另外提醒一点，上下文长度也是模型层的硬指标。Agent和模型一次交互往往要携带系统提示、工具定义、历史对话、工具返回结果，这些加在一起很容易超过小窗口模型的限制。窗口不够大，很多时候不是代码写得有问题，而是模型层压根装不下。

2.2 记忆与上下文管理：最容易被忽视的层级

很多初学Agent开发的人，包括我前几个月，都把注意力放在“怎么调工具”上，很少认真考虑“Agent怎么记住之前干了什么”。但随着任务变长，记忆问题会迅速成为瓶颈。这个层级我称之为“记忆与上下文管理层”。

它的核心问题有三个：短期记忆怎么存、长期记忆怎么存、上下文超了怎么处理。短期记忆最简单的方案是直接把对话历史塞给模型，实现成本最低，但会随着对话轮次增加快速膨胀。长期记忆则需要外部存储，比如向量数据库加Embedding，让Agent能检索到相关的历史信息。

上下文超限是所有方案里最现实的痛点。我之前做一个数据分析Agent，用户的会话经常长达几十轮，中间还穿插着大段的工具返回结果。有几次直接把上下文窗口撑爆了，程序直接报错。后来我采用了“滑动窗口+关键信息提取”的策略：会话历史只保留最近8轮，更早的内容让模型做一次摘要并存储下来，需要时再通过检索召回。这个方案运行稳定，成本也大幅下降。

记忆层级的设计会直接影响Agent的使用体验。如果做完一项任务后，Agent对用户之前提过的偏好完全没印象，用户就会觉得“这个Agent很蠢”。在2024年到2025年的开发趋势里，记忆已经从加分项变成了必需项，很多框架自带的Memory模块也开始分化出短期和长期两类。选框架时千万要看清这一层的实现方式，别等上线了才发现它只支持缓存两三轮对话。

2.3 规划与编排层：Agent聪明与否的分水岭

Agent和普通“调用工具的程序”最大的区别，在于它能不能自己规划步骤。规划与编排层负责的就是这件事：把一个大目标拆成若干小步骤，决定步骤之间的依赖关系，动态调整执行计划。

最早的Agent实现里，规划大多靠“人工写死”。例如我第一版个人任务管理Agent，就是先用关键词匹配用户意图，再走固定的流程。这样做的缺点是显而易见的：用户的话稍有变化，流程就乱了。后来我改成让大模型自己输出下一步动作，再根据执行结果决定后续动作，整个系统的灵活性才有了质的提升。

框架层面的编排能力差异是巨大的。轻量的编排就是循环调用模型；重一点的会引入Plan-Execute模式，也就是“先规划再执行”；再重一点的是ReAct模式，模型在Reasoning（推理）和Acting（行动）之间循环。LangChain的AgentExecutor、LlamaIndex的AgentRunner、AutoGen的ConversableAgent，本质上都是在做编排，只是编排的粒度和控制方式不同。

这一层还牵扯到“单Agent vs 多Agent”的选择。单Agent适合任务链路短、目标单一的场景；多Agent适合一个大项目需要多个角色协作的场景。但我要泼一盆冷水：很多项目的复杂度根本不需要上多Agent。我见过有人用一个三个Agent的团队去做一个简单的字段提取任务，结果Agent之间互相传话的token开销比实际干活还多，效果反而不如单Agent。多Agent是编排层的进阶选项，不是必选项。

2.4 工具与外部系统接入层：能否落地的关键

模型负责思考，但真正动手干活的是工具。工具与外部系统接入层就是Agent的“手脚”，它负责把Agent和外部世界连接起来：查数据库、调接口、执行代码、操作文件、访问网页等。

我在实践中的体会是，这一层的核心难点不在怎么调用API，而在工具的定义、注册和容错。先说定义，模型的Function Calling效果很大程度取决于函数描述写得好不好。函数名、参数描述、示例值都直接影响模型的选择准确性。我的经验是：函数描述里一定要写清楚“这个工具在什么情况下用、什么情况下不要用”，这比参数描述更重要。

容错是我踩坑最多的部分。工具返回的数据格式不固定、接口超时、第三方服务返回500，都是家常便饭。如果你的工具层没有做兜底处理，Agent的执行流程会直接卡死。我现在的做法是给每个工具包一层统一的返回格式，再在调用层加try-except和超时控制，同时要求模型在工具调用失败时能够自我修正。

接入层的复杂度直接决定了框架的选型。如果你的Agent只需要调用两三个结构化API，用轻量框架甚至原生代码就够了；如果你的Agent要接几十个内部系统、处理各种非结构化的返回数据，那就需要一个像LangChain这样有大量现成集成器的框架。我在选型时有一个简单粗暴的参考标准：工具数量在5个以内，用原生SDK；5到20个，考虑轻量Agent框架；超过20个或者需要复杂的工具动态选择机制，再上重框架。

3. 热门框架怎么选：LangChain、LlamaIndex、AutoGen、CrewAI实测对比

经常有人问我：“到底该学哪个框架？”我的回答永远是：先搞清楚你要解决什么问题，再选框架。作为把主流框架都折腾过一遍的人，我分享一下自己的横向对比和选型经验。

3.1 按场景选框架：先看需求，再看名气

LangChain是生态最丰富的，文档里能找到几乎所有厂商的集成器。它对“链式调用”和“工具编排”的抽象非常成熟，适合做复杂的业务逻辑编排，比如多步骤的工具处理流程、带路由的问答系统等。但它的学习成本也是最高的，因为抽象层级多，很多概念需要花时间理解。我建议对Agent原理还没完全吃透的新手，先别从LangChain入手，否则容易被抽象概念淹没。

LlamaIndex主打数据和RAG场景，如果你的核心需求是“让Agent理解一大堆文档”，它的索引、检索、重排序能力是做得很好的。但它本质上是一个偏检索的框架，Agent的编排能力相对较弱。我做过一个合同审查Agent，需求是先从数百份合同里捞相关的条款，再让模型做分析，用LlamaIndex做检索环节确实省事，但后面的分析编排我还是回到了LangChain。

AutoGen是微软开源的，主打多Agent对话式协作，内部Agent之间通过消息交换来协作完成任务。它在复杂任务分解、代码自动生成等方向表现不错。但代价是调试难度更高，两个Agent来回对话几十轮，出了问题很难定位是哪个Agent、哪条消息导致的。适合有一定经验的开发者研究。

CrewAI主打角色扮演式协作，可以用很直观的方式定义“分析师”“执行者”“审核者”等角色，并设定角色之间的协作流程。上手快、表达清晰，适合业务宣讲和多角色工作流的快速建模。但它的灵活性和对复杂控制流的支持不如LangChain。我的经验是：用它做MVP演示非常好，接近生产环境时要把协作逻辑摸透再决定。

3.2 轻量与重量之间的取舍

我在3.1提到按场景选择，这里想单独说说轻量和重量之间的取舍，因为这可能是最容易劝退新手的地方。我见过很多人一开始就上LangChain，结果被抽象概念绕晕，最后连一个完整功能都跑不出来。也见过有人坚持用原生代码，结果随着需求变复杂，代码里到处是判断分支，维护成本指数级上升。

目前Agent开发领域有一个明显的趋势：原生SDK的能力越来越强。OpenAI、Anthropic以及国内多家模型厂商都提供了原生的Agent开发套件或函数调用能力，很多简单的Agent用原生SDK完全能够实现。因此我自己的选择标准逐渐变为：先评估团队对Agent原理的熟悉度，再评估项目的工具数量和编排复杂度，最后决定要不要引入重框架。

如果你刚入行，我强烈建议从原生方式开始。先实现一次“循环调用模型—解析工具调用结果—再调用模型”的最小闭环，代码量大约50到100行。跑通之后，再来对比LangChain做了哪些抽象，这时候你看到的就不是一堆名词，而是有明确意义的封装逻辑。

3.3 我们项目里的真实选型过程

去年年底我参与了一个企业内部的智能工单Agent项目，需求是从用户的自然语言描述里提取工单信息、搜索历史工单、匹配处理方案并生成回复。当时团队内部发生了选型分歧，一部分人认为直接用LangChain的Agent，另一部分人认为工具就三个，没必要引框架。

最后我们采用的是折中方案：核心循环用原生代码，工具封装自己在内部实现，框架只使用了LangChain里的PromptTemplate和输出解析组件。这样做的原因有两条。第一，工具数量少且结构稳定，Agent需要处理的流程相对固定，上重框架带来的抽象成本大于收益；第二，团队当时对框架源码的理解还不够深入，一旦出bug反而难排查。

这个项目给我最大的启发是：选型不是为了用框架而用框架，而是为了降低代码的复杂度和维护成本。如果引入框架之后，你的代码变得更难理解，那这个引入就是不划算的。框架层级的价值在于提供“可编排的抽象”，但抽象也有它的代价——调试时你得同时理解业务逻辑和框架的封装逻辑。

4. 实战演示：从零搭一个“个人任务管理Agent”工作流

纸上谈兵聊了很多，这一节我用一个完整的例子来串联。需求很简单：做一个个人任务管理Agent，让用户用自然语言添加任务、查询任务、标记完成，并把任务清单存到本地JSON文件里。

4.1 需求拆解与任务层级设计

这类Agent最适合用来理解层级，因为它的功能边界清晰，工具不多，但又覆盖了模型层、记忆层、规划层和工具层。拆完之后大概是这样的：

• 模型层：负责理解用户意图，输出结构化指令
• 工具层：提供三个函数——add_task、query_tasks、complete_task
• 编排层：读取模型输出，执行对应函数，返回结果给模型
• 记忆层：保存任务数据到本地文件，实现长期存储

在拆解需求的时候，我习惯把每个功能点先标好层级，而不是一上来就写代码。这一步能让你在设计数据结构时就从全局出发，避免代码写到一半发现模型输出和工具参数对不上。

4.2 选型思路：这次我为什么不用重框架

这个项目我特意选择不用LangChain等重框架，原因有三。第一，工具数量太少，重框架的集成优势体现不出来；第二，业务逻辑简单，涉及的判断分支有限，原生的流程控制足够；第三，这个项目本身就是一个学习项目，用原生代码能把层级关系看得更清楚，也更方便你以后再去看框架源码。

如果你只是要一个能用的任务管理工具，用原生代码加模型SDK，几十行就够了。如果你想把Agent开发学明白，我建议你也在自己的学习项目里刻意避开重框架，先体验一下“没有框架帮你兜底”是什么感觉。

刻意练习的原理是：如果你总是依赖框架帮你完成关键流程，你永远不知道框架替你扛住了什么问题。只有亲手实现一次底层循环，你才会理解为什么框架要这样抽象。

4.3 核心实现与代码逻辑拆解

下面是任务管理Agent的核心逻辑，我用Python实现。主要分三块：模型对话循环、工具定义、工具调用分发。

import json import openai client = openai.OpenAI() TOOLS = [ { "type": "function", "function": { "name": "add_task", "description": "添加一个新任务。当用户明确表示要记录/新增任务时使用。", "parameters": { "type": "object", "properties": { "content": { "type": "string", "description": "任务内容" }, "due_date": { "type": "string", "description": "截止日期，格式YYYY-MM-DD，可选" } }, "required": ["content"] } } }, { "type": "function", "function": { "name": "query_tasks", "description": "查询当前任务列表。当用户询问有哪些任务、任务进度时使用。", "parameters": { "type": "object", "properties": {} } } }, { "type": "function", "function": { "name": "complete_task", "description": "将指定任务标记为已完成。当用户表示任务完成时使用。", "parameters": { "type": "object", "properties": { "task_id": { "type": "string", "description": "任务ID" } }, "required": ["task_id"] } } } ] def add_task(content, due_date=None): tasks = load_tasks() task = { "id": str(len(tasks) + 1), "content": content, "due_date": due_date, "completed": False } tasks.append(task) save_tasks(tasks) return f"已添加任务：{content}，ID为{task['id']}" def query_tasks(): tasks = load_tasks() return json.dumps(tasks, ensure_ascii=False) def complete_task(task_id): tasks = load_tasks() for task in tasks: if task["id"] == task_id: task["completed"] = True save_tasks(tasks) return f"任务{task_id}已标记完成" return "未找到对应的任务ID" def load_tasks(): try: with open("tasks.json", "r", encoding="utf-8") as f: return json.load(f) except FileNotFoundError: return [] def save_tasks(tasks): with open("tasks.json", "w", encoding="utf-8") as f: json.dump(tasks, f, ensure_ascii=False, indent=2)

上面这3个工具完全对应“工具层”。关键点是函数描述要写得足够清楚，比如add_task里面加了“当用户明确表示要记录/新增任务时使用”，这能有效减少模型在意图不明时误调用工具的概率。complete_task也是同理，加上了“当用户表示任务完成时使用”这样的触发条件描述。

模型层的调度循环如下：

def run_agent(user_input): messages = [{"role": "user", "content": user_input}] while True: response = client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=TOOLS, ) message = response.choices[0].message messages.append(message) if message.tool_calls: for tool_call in message.tool_calls: fn_name = tool_call.function.name args = json.loads(tool_call.function.arguments) if fn_name == "add_task": result = add_task(**args) elif fn_name == "query_tasks": result = query_tasks() elif fn_name == "complete_task": result = complete_task(**args) else: result = f"未知工具：{fn_name}" messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result }) else: print("Agent回复：", message.content) break if __name__ == "__main__": run_agent("帮我加一个任务：周三之前写完项目总结")

这段代码是“编排层”的核心逻辑：循环判断模型是否发起了工具调用，如果发起了，就遍历所有工具调用并执行，然后把结果作为tool角色的消息回传给模型；如果没有工具调用，说明回答已经生成，循环结束。

我刚开始写这个循环时，经常漏掉一个关键点——messages里必须把模型的返回原样追加进去，再把工具结果追加进去。如果漏了模型的那条带tool_calls的消息，后续请求就会失去上下文，模型会变得“很懵”。

4.4 实际调试中的问题与优化点

代码跑起来之后，我遇到了几个比较典型的问题，每个都和层级相关。

第一个问题是函数描述不精准导致的误调用。有次用户问“下午有什么安排？”，查询任务列表是合理的，但模型有时候会把这句话误判成新增任务。排查下来发现是add_task的描述太宽泛了。我把描述改成了“当用户说‘加一个/记住/新增/提醒我’等表示要录入新任务时才使用”，误判率立刻下降。这件事让我意识到：工具层定义不是写代码，是在和模型的注意力机制打交道。

第二个问题是并发处理。原本的执行逻辑是逐个执行tool_calls里的所有工具，假设模型一次生成两个工具调用，任务A和任务B会串行执行。对于任务管理场景足够用了，但如果以后接入耗时的外部API，就要考虑是否改成并行或异步执行。我的建议是：在工具层设计时，给每个工具预留一个“幂等性”的约定——同样的输入重复调用不会产生副作用，这样未来改造成并行执行时才不会出问题。

第三个问题是长期记忆。这个项目目前只把任务存到了JSON文件，但Agent本身没有跨会话的记忆。也就是说，下次启动对话，Agent不记得之前的偏好。如果想要更智能的体验，可以在工具层加一个“读取用户偏好”的工具，在每次真正完成任务前先检索一下；或者在系统提示词里把用户的历史偏好摘要注入进去。后一种做法实现简单，但需要额外的存储和检索能力，更适合接入向量数据库。

5. Agent开发学习路线与面试经验：给后来者的参考

这个博客最初定位是分享技术经验，但我发现读者里相当一部分是准备转行Agent开发、或者正在投Agent相关岗位的人。他们后台留言问得最多的两件事：怎么学、怎么准备面试。这一节我就把这两件事一次说清楚。

5.1 学习路线：先底层、再框架、后业务

如果你把Agent开发当成一个工种，那它的学习曲线其实非常陡峭，因为横跨的知识点太多了：Prompt、模型API、函数调用、RAG、向量数据库、工作流编排、多Agent协作、工程评估。如果一开始就去追着新框架、新概念跑，会很累。我的建议是按“底层能力—框架原理—业务落地”三个阶段推进。

第一阶段是底层能力，目标是把一次完整的“模型调工具”循环吃透，内容包括：OpenAI或其他模型提供商的ChatCompletion接口、Function Calling的机制、上下文构建方法，以及一个简单的工具调用分发器。这个阶段不需要任何框架，我上一节的任务管理Agent就是一个很好的练习项目。

第二阶段是框架原理，目标是从源码层面理解主流框架的核心抽象是来解决什么问题的。可以选LangChain和LlamaIndex各做一个小项目。LangChain项目可以做一个“带检索增强的问答Agent”，LlamaIndex项目可以做一个“本地文档知识库”。做完之后，再回头对比自己第一阶段写的原生代码，框架的设计取舍一目了然。

第三阶段是业务落地，目标是把Agent投放到真实场景里并解决工程化问题。重点关注：如何评估Agent的任务完成率、如何处理工具调用失败、如何设计人工兜底流程、如何控制token成本、如何做好日志追踪。越接近生产环境，工程化能力和评测手段就越重要。

关于学习资料，我不推荐只看某一家框架的官方教程。做Agent开发，真正的通用知识不是某个框架的用法，而是对“模型能力边界”和“任务流程拆解”的理解。框架会变，模型也会更新，但这两项能力可以一直复用。

5.2 Agent开发面试常考什么：我整理的高频问题

面试是检验水平和查缺补漏的好方式。我在面试中也面过不少候选人，一个很深的体会是：能讲清楚框架原理的人比会调框架的人稀缺得多。面试官虽然会问工具和API，但更看重的是你在陌生问题上的拆解思路。

我整理几个高频的面试方向，每一个背后都有一串需要系统掌握的知识点：

• 请讲一下你做过的一个Agent项目，为什么选择这个架构？ 这类问题考察的是项目决策能力，重点说清楚你要解决什么问题，为什么选这个模型、这个框架、这种记忆方案，以及你对比过哪些替代方案。我在面试中遇到的候选人多半只讲功能，很少讲“为什么”，当你讲清楚之后，会立刻和普通候选人拉开差距。

• 如果你的Agent调用的工具超时或返回了错误数据，你会怎么处理？ 这道题考察的是工程化兜底能力。回答思路包括：给工具统一包装超时和错误码；在编排层加入失败重试；在返回给模型的内容中明确标注当前状态是错误；在几次失败后切换到人工处理流程。其实考察点在于你有没有真的调试过Agent，而不是只跑过demo。

• 用户上下文超过了模型的窗口限制，怎么办？ 考察记忆和上下文管理能力。核心回答要点是：滑动窗口、关键信息摘要、外部向量检索、按需注入工具返回结果等。如果你能展开说明各种方案的取舍和适用场景，面试官一般会认可你的实战深度。

• 多Agent协作和单Agent相比，优势在哪里，劣势在哪里？ 这是现在很火的考点。可以从可维护性、可扩展性、调试难度、token开销、角色职责边界这几个方面展开。最重要的是要给出自己的判断准则，比如“当任务责任边界清晰且需要并发处理时适合多Agent，否则单Agent更好”。

• 你怎么评估Agent的效果？ 这个问题问的人开始变多，因为Agent评测确实是工程落地难点。你可以从任务成功率、工具调用准确率、回答相关性、用户反馈这几个维度设计评估集，再结合人工标注和线上指标来评估。评估集不需要特别大，但覆盖各种类型的场景很重要。

5.3 关于Agent开发工程师这份工作

搜“Agent开发工程师”这个岗位，能看到不少机会，但它和传统的后端开发、算法工程师又不太一样。和传统后端相比，Agent开发更多是在跟“不确定的输出”打交道；和算法工程师相比，Agent开发又要做大量的工程落地和业务需求理解。

从我做这8个月的感受来说，Agent开发工程师更像是一个“翻译官”——把业务需求翻译成模型能理解的任务，再把模型的行为翻译回业务结果。做好这份工作，需要的不是背几个框架API，而是不断积累“模型表现与业务预期之间的落差”处理经验。

如果你正打算入行，我的建议是：先把一个真实的小项目完整走通，记录下所有踩过的坑，然后带着这个项目去面试。有完整项目经验的人在面试里的竞争力，比看了一堆教程、但没有独立完成过任务的人强得多。项目不需要大，你只要把一个很小的任务交给Agent完成，并让它稳定跑上一个月，就已经超过了大部分人。

最后说点实在的

看过层级之后的Agent开发，和之前完全是两个世界。以前我被一种“什么都想用、什么都学不深”的焦虑推着走，总觉得是不是因为自己不够努力；现在我知道，真正有效的努力是把力气花在正确的层级上。模型层和工具层下功夫，能让Agent“能干活”；记忆层和编排层下功夫，能让Agent“干得聪明”；工程化评测和生产级设计下功夫，才能让Agent真正“靠得住”。

如果你身处转型期，或者正在写自己的第一个Agent，我的体会是：不用急着把所有热词都追一遍，也不用在框架选择上反复犹豫。用最少的依赖跑通一个最小闭环，然后把时间花在调试真实问题上，半年之后你也会有自己的答案。