这两年 Agent 的讨论热度实在太高了打开任何技术社区满屏都是“Agent 架构”“Agent 开发”“多 Agent 协作”“Agent 安全”这些词。我身边不少朋友拿着这类热搜词找过来问真想从零开始构建一个 Agent到底该先学什么、先做什么说实话最初我也被各种新概念绕得晕头转向直到把第一个最小可用的 Agent 真正跑起来才发现所谓“从零构建”核心其实不是去训练模型而是搞清楚怎么把已有的模型能力、工具和业务流程可靠地组装到一起。这篇文章就按我自己走过的路子来写。我会从最基础的认知讲起然后聊选型、亲手写一个 Agent 核心循环、把能力封装成 Skill、再说清楚 Harness 和多 Agent 的边界最后落到评测和安全。无论你是刚接触 Agent 的新手还是已经用框架写过几个 Demo 但总觉得差点意思的开发者这份内容应该都能帮你把零散的碎片拼成一张完整的图。1. 先泼盆冷水Agent 不是更聪明的聊天机器人构建前要回答三个问题很多初学者默认 Agent 就是“能自己干活的聊天机器人”把它理解成 GPT 套了一层自动化壳。这个认知不能说错但会严重误导你的构建方向。我的理解是Agent 是一个在目标驱动下能通过观察环境、调用工具、反思结果来推进任务的程序系统。模型只是它的“大脑”真正让它变得有用的是大脑之外那套能感知、能行动、能记忆的骨架。所谓“从零构建”不是从零写神经网络而是从零设计这套骨架。这就像你要做一个机器人不需要自己炼钢铁但必须很清楚电机、传感器、控制器之间怎么配合。动手之前我建议先回答下面三个问题。这三个问题决定你要构建的是什么样的 Agent也决定你后面所有技术选型。第一任务的边界在哪里。你是要它完成“写一份周报”这种一次性任务还是要它持续跟踪一个项目、隔一段时间主动汇报一次一次性任务用简单的单轮工具调用就能解决持续任务则需要引入任务队列、持久化记忆和定时触发机制。边界不清会让架构从一开始就变形。第二Agent 能触达哪些系统。一个只会聊天的 Agent 其实不需要构建多少基础设施但你要它查数据库、发邮件、操作文件系统就必须考虑权限、认证、数据格式这些现实问题。很多项目做了一半卡住不是模型不行而是工具链路没打通。第三使用者是谁容错率多高。内部工具型 Agent 出错了有人兜底甚至可以只给建议不自动执行对外服务的 Agent 则必须把失败处理、降级方案和审计日志当成一等公民来设计。这个问题不回答清楚上线后哪晚你都睡不踏实。我当时第一个 Agent 选的是一个非常窄的场景读取指定目录下的日志文件按照模板生成每日异常摘要。它不追求通用只求稳定。事实证明这个决定非常关键因为场景窄工具调用只有三个评测标准也很清晰我才能在三天内跑通全链路并把注意力放在理解 Agent 循环本身而不是被各种边界条件淹没。2. 基座与框架选型模型 API、LangChain/Dify/CrewAI 和自研路线怎么挑三个问题有了答案下一步就是选型。这里所谓选型包含两层模型层和框架层。这两层的选择逻辑完全不同别混在一起考虑。2.1 模型基座托管 API 还是私有化部署绝大多数个人项目和小团队项目我建议直接用托管模型 API比如 OpenAI、Claude 或者国内各家大模型平台提供的函数调用能力。理由只有一个省时间。从零构建 Agent 已经有很多工程复杂度如果模型层还要自己做推理优化、部署容灾学习曲线会一下子变得特别陡。什么时候考虑私有化部署通常是数据敏感、必须内网运行或者单次调用成本已经高到无法接受。本地模型的优势在于可控和低成本但推理质量、函数调用准确率往往比不上头部闭源模型。做 Agent 尤其是工具调用场景时模型“能不能严格按照 schema 输出参数”远比“会不会写诗”重要开源模型在这个维度上差距还是很实在的。另外注意一个所有模型都逃不过的问题上下文长度。Agent 循环里每一步工具返回结果、中间推理过程都要塞进对话里几个来回下来很容易把上下文撑爆。我的经验是在模型能力允许的前提下把上下文尽量留大同时在代码里严格控制消息历史的剪裁策略。别以为 max length 调大就万事大吉长度大了延迟和成本都会指数上涨。2.2 框架对比LangChain、Dify、CrewAI 和自研到底哪个好这几乎是每次群里讨论“Agent 框架”时必吵的话题。我的结论是没有最好的框架只有最匹配你当前阶段的框架。直接看对比表格方案适合场景优势坑点LangChain / LangGraph偏好代码化、需要复杂流程控制组件齐全节点可编程控制社区资料多抽象层次多版本升级改动大容易“组件地狱”Dify不想写太多代码想快速搭应用可视化编排自带知识库、工作流、日志深度定制受限复杂逻辑表达吃力CrewAI角色化多 Agent 协作角色定义直观一个流程里多个 Agent 各司其职多 Agent 调试难隐性成本高问题定位靠猜自研无框架学习理解、场景很轻、追求完全可控逻辑透明依赖少能彻底搞懂 Agent 原理并发、重试、日志、记忆都要自己造轮子我给新人的建议路径是先自研一个最小循环再用框架重写一遍。很多人恰恰反过来一上来就套框架结果出了诡异问题根本判断不出是自己的逻辑错了、框架封装的问题还是模型本身没调对。自研那一步不丢人它就像学开车先在空场地练直线比直接上高速安全得多。你要是问我现在生产环境用哪个我会说大部分平庸需求 LangGraph 和自研都够用Dify 适合团队里没有专职开发又想快速验证的创业场景CrewAI 适合要多个角色协作但核心流程不太复杂的场景。真正到多 Agent 大规模协作时框架反而是次要的重要的是你自己对消息流和控制权的理解。2.3 记忆存储别一上来就上向量库热词里“Agent 记忆”出现频率很高很多人以为做长期记忆必须上向量数据库。其实记忆是个分层结构先想清楚要存什么层次的数据。短期记忆就是当前会话的消息列表直接在内存里维护滚动丢出过老的消息。中期记忆指单次任务内跨步骤的状态比如 Agent 已经把用户原始需求拆成了子任务清单这个清单要存进一个结构化的状态对象。长期记忆才用向量库做的是“用户的偏好”“企业的知识库”“历史任务的相似案例”这类跨会话检索。我实测下来新手最容易犯的错误是过早引入向量库。你现在的场景可能就几百条知识记录直接全量塞进 prompt 反而比检索更准、更省事。我一般是等知识条目超过上下文放不下了才考虑切向量检索。记忆设计里真正难的不是存储而是什么时候写入、什么时候检索、检索结果放在 prompt 的什么位置。这些都需要结合具体场景反复试没有银弹。3. 把 Agent 核心循环手写一遍规划、调用工具、反思、终止Agent 几乎所有能力都围绕一个循环展开模型根据当前状态决定要不要调用工具调用后把结果放回上下文模型再决定下一步直到它认为任务完成。这个循环看起来简单但把每一步的细节抠清楚你就拿到了构建所有复杂 Agent 的钥匙。3.1 循环的本质是“感知—决策—行动—再感知”这个结构最早在 ReAct 这类经典方法里就被验证过模型交替执行 Reasoning推理和 Acting行动行动结果反馈给模型继续推理。放到今天的大语言模型 Agent 里就是工具调用Function Calling / Tool Calling机制。模型本身不会真的执行任何操作。你要在代码里完成以下几件事把工具列表连同描述传给模型模型如果认为需要工具会返回结构化的工具名称和参数你的代码校验参数、执行工具、把执行结果以“工具消息”的形式送回模型模型基于新信息继续推理可能再调下一个工具也可能直接输出最终答案。这个循环里最容易被忽略的是“校验”这一步。模型返回的参数偶尔会格式错误、缺字段、甚至幻觉出不存在的工具名。生产环境的 Agent 必须在执行工具前做一层严格校验而不是盲目相信模型的输出。3.2 手写一个最小但完整的 Agent下面这段代码是我建议每个人都自己敲一遍的骨架它不依赖任何框架只有一个模型 SDK。我用最常见的 OpenAI 风格函数调用示例你需要换成自己的模型时改接口封装即可。import json from openai import OpenAI client OpenAI() # 工具列表模型只能看到描述真正执行逻辑在 execute_tool 里 TOOLS [ { type: function, function: { name: get_weather, description: 查询指定城市今天的实时天气, parameters: { type: object, properties: { city: { type: string, description: 城市名例如北京 } }, required: [city], }, }, } ] def execute_tool(name: str, args: dict): 这里的工具函数要用白名单方式调用绝不能 name 传什么就执行什么。 if name get_weather: # 实际项目中这里会去请求天气服务演示时直接返回假数据 return {city: args[city], weather: 晴, temperature: 25} raise ValueError(f未知工具: {name}) def run_agent(user_input: str): messages [ {role: system, content: 你是一个能调用工具完成任务的中文助手。}, {role: user, content: user_input}, ] max_steps 5 for step in range(max_steps): response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, tool_choiceauto, ) message response.choices[0].message messages.append(message.model_dump()) if message.tool_calls: for tool_call in message.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) tool_result execute_tool(fn_name, fn_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(tool_result, ensure_asciiFalse), }) else: return message.content return 到达最大步数任务未能完成。 print(run_agent(北京今天天气怎么样))这段代码只有不到五十行但它已经具备了一个 Agent 最核心的生命周期发起请求、判断是否需要工具、执行工具、回填结果、继续推理、最终输出。你先别看不上它很多号称先进的框架削掉包装之后干的就是这件事。在这个基础上我会立刻做三件增强加全局步数限制和单次 token 限制防止死循环和超长输出拖垮成本给 execute_tool 包一层 try/except工具执行失败也要把这个失败信息作为结果返回给模型让模型自己调整策略给每一步的 messages 存一份带时间戳的日志后面调试和构建评测集全靠这些原始轨迹。3.3 “反思”不是玄学是循环里的一个显式节点很多 Agent 教程会提到 reflect反思听起来很玄。在我实现的系统里反思就是当工具执行结果不理想或者模型连续两步没有进展时额外让模型做一次“总结当前失败原因并提出新计划”的调用。举个例子Agent 查询天气把城市名传成了“北京市市辖区”工具返回空结果。普通循环里模型可能再试两次还是失败。加了反思节点后我会这样处理先把最近几步的轨迹压缩成摘要再让模型回答“为什么失败下一步要不要换一种查询方式”。这一步的 prompt 要有意识地引导模型区分“信息不足”和“操作错误”两者对应的修正策略完全不同。反思不是越多越好。每加一次反思节点就多一次模型调用延迟和失败可能。我的建议是只有当循环出现失败、重试、或者步骤数超过预设阈值时才触发反思。平时别让模型没事就“总结一下”很容易把简单问题复杂化。4. Tool 和 Skill 的边界在哪里把能力封装成可复用、可测试的模块单个 Agent 跑通后你要面对的第一个规模化问题就是功能越来越多工具越来越乱。这个时候就必须引入 Skill 的概念。热词里的“agent skill”“skill 教程”反复出现因为它确实是 Agent 工程里最实际的一层抽象。4.1 Tool 是原子操作Skill 是场景化能力我的定义非常简单Tool 是一个不可再分的原子操作比如“读取文件”“发送 HTTP 请求”“执行 SQL”。Skill 则是围绕某个场景组织的一组工具、提示词和校验逻辑比如“把网页保存为 Markdown”“生成销售周报”“从 PDF 中提取结构化表格”。区别在哪里Tool 是需要被模型直接调用的最小单位而 Skill 是给模型或者给编排系统提供的一个“能力包”。模型不需要知道 Skill 内部调用了三四个工具它只需要知道调用这个 Skill 完成什么目标传入什么入口参数。这个区分带来的实际好处是你不需要为模型维护一份巨大的扁平工具列表。工具数量超过二十个时模型的选择准确率会肉眼可见地下降给用户的感觉就是“它总是选错工具”。把工具归类封装成 Skill 后模型首先选择的是“哪个 Skill 最合适”再在 Skill 内部用固定的顺序或小策略执行子步骤整体准确率会有明显提升。4.2 Skill 的描述是生死线正反面例子对比Skill 封装得好不好90% 取决于描述文字写得清不清楚。模型没有用过你的 Skill它只能通过描述来判断这个功能适不适合当前任务。如果描述含糊再好的工具也容易被模型忽略或误用。给你一个反面例子名称: 网页转文档 描述: 把网页变成 markdown问题很多网页 URL 怎么传输出到什么位置哪些网页不支持和另一个叫“网页正文提取”的 Skill 有什么区别模型看到这种描述等于没看到。正面例子这样写名称: save_webpage_as_markdown 描述: 将一个网页 URL 下载并保存为 Markdown 格式的本地文件。 适用场景: 用户希望把某篇文章、文档页面或博客文章保存到本地笔记库。 入口参数: url: 完整的网页链接 output_path: 可选默认保存到 notes 目录 限制: - 仅支持静态可访问页面需要登录或动态渲染的页面可能失败 - 如果页面是 PDF 或其他非 HTML 文件建议使用其他 Skill这个描述把“什么场景能用”“参数是什么”“哪些情况会失败”都明明白白告诉了模型。模型本身就是个非常依赖说明书的执行者说明书的质量直接决定它的表现。4.3 一个真实例子网页保存为 Markdown 的 Skill热词里正好有人问“Agent 将网页保存成 Markdown 的 skill”。我完整做过一次分享下内部的模块拆分。这个 Skill 从表面看是“一个功能”内部其实包含了五个步骤抓取用 httpx 请求 URL设置合理的 User-Agent 和超时时间拿到 HTML清洗去掉 script、style、导航、广告这类噪音节点转换把清洗后的 HTML 转成 Markdown保留标题层级、链接、图片地址校验转换结果不能为空标题不能缺失链接列表要完整落盘按 URL 哈希或日期命名保存同时把来源 URL 写进 Markdown 头部作为元信息。这五个步骤里清洗是最容易被忽视的。很多网页正文之外有一堆推荐内容和页脚不洗干净转出来的 Markdown 就是垃圾。你在构建任何抓取/转换类 Skill 时都一定要在清洗环节多花时间而不是急着套转换库。Skill 的另一个关键点是“失败要可控”。网页访问会遇到超时、被反爬拦截、动态渲染无法得到正文等各类情况。每个子步骤的错误都要返回给上层让模型能据此改变方案。我实测中最常出现的失败原因是用户给了一个需要 JS 渲染的页面而我们的抓取器拿不到正文。这种情况下与其硬着头皮转出一个空壳文件不如明确告诉模型“此页面需要渲染建议换 Skill”让整个链路保持诚实。4.4 Skills 测试先手工显式触发再自动化回归Skill 上线前至少要测三轮。第一轮手工精确触发把你 Skill 的描述直接作为唯一的工具给模型输入标准参数确认输出正确。第二轮场景联调把 Skill 放进完整 Agent 里用几类典型的用户说法去触发比如“帮我把这篇文章存下来”和“这个网页我晚上想离线读”确认模型能自然联想到这个 Skill。第三轮自动化回归把之前用手工测过的输入输出固化成测试集之后每次改动描述或内部逻辑都重新跑一遍。自动化回归这事很多团队不做后果就是改了一个 Skill 的描述其他场景的触发率悄悄下降而你根本无感知。Agent 这门手艺里的很多问题都是回归问题真的建议从第一天就建立最基本的召回测试集。5. Harness、编排与多 Agent单 Agent 跑通之后再考虑的事单 Agent 跑通后很多人会兴奋地想冲多 Agent。我的建议是先泼第二盆冷水多 Agent 是手段不是目的。如果单 Agent 能解决不要为了炫技硬上。但在深入多 Agent 之前有两个概念建议先搞清楚什么是 Agent Harness什么是编排。5.1 Harness 就像 Agent 的操作系统热词里“harness 和 agent 区别”“agent harness”出现得也不少。我理解 Harness 是承载 Agent 运行的运行时环境。模型本身不执行工具代码里负责“接收模型意图、调用工具、管理上下文、调度生命周期、记录日志”的那部分整体就是 Harness。换句话说上一节里我手写的run_agent函数其实就是最简版 Harness。当你说“我用 LangGraph 做 Agent”LangGraph 提供的是框架当你说“我设计了一个 Sandbox 让 Agent 在里面安全地执行代码”这个 Sandbox 是 Harness 的一部分。Harness 要管的事情包括工具的权限边界、敏感操作是否要人类确认、上下文窗口的剪裁策略、失败重试策略、审计日志、以及步骤预算。它不一定多复杂但必须有。很多人觉得 Agent 不安全、不可控本质是 Harness 做得太薄把模型的工具调用直接映射成了真实系统的操作中间完全没有策略层。5.2 多 Agent 协作模式主管与执行者、流水线、竞合真正需要多 Agent 的场景通常是这样任务边界天然切分清晰比如一个 Agent 负责市场调研、一个 Agent 负责数据分析、一个 Agent 负责生成报告它们之间的结果要互相依赖。这时候最稳妥的架构是主管 Agent 执行 Agent 模式。主管 Agent 只负责理解任务、拆解、派活、汇总不亲自碰工具执行 Agent 各管一段把结果返回主管。另一种常用的是流水线模式。任务固定是 A 到 B 再到 C比如“抓取资料→清洗数据→生成报表”每个 Agent 是流水线上的一个工位。这种模式实现简单调试也容易因为每个环节的输入输出是确定的。我强烈不建议一上来就做“自由市场式多 Agent”所有 Agent 都能互相发消息、都能修改共享状态、自行决定下一个动作。这种架构表面先进实际上死循环、信息丢失、责任推诿会让你排查到崩溃。你可以在后期逐步放开自由度但前期最好把消息流转和会话生命周期管得死死的。5.3 防循环和防失控的三个土办法多 Agent 系统最常见的故障是消息环路Agent A 给 B 发消息B 给 C 发C 又回去找 A然后无限循环。三个土办法非常管用全局步数上限整个系统无论多少 Agent总步数超过阈值立即熔断消息去重指纹记录每条消息的内容哈希如果同一内容反复出现判定为循环越级锁Agent 只能给特定角色发消息禁止跨层级通信。这三个办法实现成本低效果立竿见影。别迷信复杂治理先用硬约束把系统保住再慢慢放开。6. 上线前躲不开的两件事评测集构建和 Agent 安全护栏Agent 和普通后端服务的最大不同在于普通服务有明确的输入输出断言Agent 的输出空间接近无穷而且状态和动作互相影响动一发牵全身。所以评测和安全是 Agent 能不能上生产的生死关这两个词在热词里也都出现了我分别说重点。6.1 评测不是看“聪明不聪明”而是看稳定不稳定很多团队评测 Agent 就是随手丢几个问题看回答“像不像样”。这种主观评测只能用来做产品 Demo不能用来做回归。我的做法是构建一个任务型评测集每条用例长这样任务描述一段模拟真实用户的指令正确行为路径应该调用哪些工具、大概按什么顺序成功判定最终结果必须满足哪些字段或条件干扰项故意加入模糊表达、无关信息、边界条件。评测维度也不只看完成率还要看这些数评测维度说明参考指标任务完成率最终结果是否满足成功判定越高越好低于 80% 别上线平均步数完成任务需要的循环轮数步数越多成本越高也越容易出错工具调用准确率选对工具、传对参数的比例核心指标低于 90% 建议先优化工具描述成本/Tokens单任务平均消耗的 token 数变化明显时说明行为路径漂移了死循环/未收敛率触发步数上限的用例比例应为 0哪怕是极少数也要查清失败恢复率工具异常后能自行调整继续成功的比例这个指标最能反映 Agent 成熟度6.2 评测集从哪里来真实日志里的边界用例评测集最靠谱的来源是真实使用日志中那些把 Agent 难住的问题。每次生产环境出现一次失败就把相关轨迹抽出来去重整理查明是因为 prompt 不清、工具描述不准还是评测集没覆盖。这等于给 Agent 做错题本比你自己凭空造题有效得多。构建评测集的数据组织我建议这样基础集每类场景至少 10 条高质量用例保证每次都跑通回归集从历史 bug 里提炼粘在代码仓库里每次改动 Agent 逻辑就全跑干扰集故意把几个任务混在一句话里测试任务拆解能力评测集不是一次建完的它需要和 Agent 一起成长。你每加一个工具、每改一次描述都可能让旧用例的结果发生变化。评测集的意义就在于这种变化能第一时间被我们看到而不是等用户骂上门。6.3 安全护栏权限最小化、沙箱、敏感操作确认Agent 安全是另一个容易被“功能优先”挤掉的话题。但 Agent 的安全和普通 Web 应用有本质区别普通应用是固定的接口暴露什么才能访问什么Agent 是模型动态决定调哪个接口攻击面从“定义好的入口”扩散到了“模型任意组合工具的能力”。这里给出我实际在用的几条安全基线。最小权限原则。给 Agent 的工具凭证必须比人工默认权限更小。它只需要读某个目录就绝对不给写权限。Agent 不需要数据库的删除权限就不要建带 DROP 的账号。工具白名单。代码里execute_tool只能通过 if/elif 白名单调用绝不能让模型提供的函数名直接映射到任意 Python 函数或系统命令。沙箱隔离。凡是可能执行代码、解析文件、链接外部网络的工具都丢进 Docker 或独立子进程。这样即使某个环节被突破也炸不到宿主系统。敏感操作二次确认。发送邮件、转账、删除文件、对外发布内容这类操作应该设计成“Agent 生成请求人类确认后执行”的模式。别觉得这样“不智能”这种人工兜底恰恰是 Agent 能规模化使用的前提。审计日志。每一步工具调用的入参、出参、模型原始输出都要落日志。Agent 出了问题没有审计日志基本等于无法排查。6.4 成本控制和 Token 预算把成本当作功能指标Agent 一个循环里可能调用十几次模型每次都是真金白银。我见过不少 Agent 项目功能都正常但跑一次任务要花几块钱甚至几十块钱结果根本没法给用户用。Token 预算是必须写进 Harness 的单步最大输出、单任务最大总消耗、超限直接终止并提示。这里回答一个热词里的疑问“AI Agent token 是什么意思”。Token 是模型处理文本的基本单位可以粗略理解为一段文字被切分成的碎片数。中文字符通常一个或几个字符算一个 token。Agent 每多一轮工具调用就要把前面的记忆重新发送一遍所以总 token 消耗看消息长度乘循环次数。节约的核心不是抠单字字数而是剪裁记忆、减少无效循环、控制工具返回结果大小。工具返回动辄几千字的 JSON往往占了总 token 的大头建议每次返回前先做字段裁剪和摘要。7. 学习路线和面试题把热搜词变成你自己的能力图谱聊完技术细节再花点篇幅说说学习和求职。热词里的“agent 学习路线”“agent 面试题”“从入门到精通”其实都指向同一个需求这个领域变化太快到底该按什么顺序学面试会问什么。我结合自己带人踩过坑的经验给一条务实路径。阶段一把 prompt 工程和 Function Calling 用熟。所有 Agent 能力都建立在模型会正确理解指令和输出结构化参数的基础上。你可以用最简单的方式练习给模型两个玩具工具让它完成查询、计算等小任务。阶段二自己手写一次 Agent 循环就是我前面给的那段代码。务必亲手敲一遍并且尝试逼出几个 bug工具返回格式错误怎么办、模型连续调用同一个工具怎么办、上下文爆掉怎么办。这个阶段的目标是建立“循环直觉”。阶段三选一个框架重写一遍。LangGraph 也好Dify 也好CrewAI 也好你会发现自己已经能看懂框架文档里那些概念对应到你手写代码里的哪一行了。这时候框架对你不再是黑盒而是工具。阶段四做记忆和工具的深度实践。给 Agent 加一个向量记忆库做一个有五个子步骤的 Skill并搭一个自动化回归评测集把这些动作固化下来。这个阶段你会真正理解“评测驱动开发”在 Agent 领域有多重要。阶段五再去看多 Agent 和 Harness。有了前四个阶段的铺垫你再看 Supervisor、Worker、Router 这些概念会很有画面感而不是被名词淹没。至于面试我遇到的高频问题大概分成几类概念类什么是 Agent 核心循环Agent 和普通 LLM 应用的区别是什么Tool、Skill、Agent 的关系是什么参考思路Agent 核心是模型规划记忆工具的外部闭环普通应用是单轮或预设流程Agent 可以动态决策。原理类函数调用底层大概怎么实现记忆分几层参考思路可以从训练/指令遵循角度说也可以从系统设计的角度说清楚短期、中期、长期记忆的职责边界。实战类Agent 死循环怎么办工具调用乱选怎么办上下文膨胀怎么办成本太高怎么办这些问题没有标准答案考官其实是在看你是不是真的上手写过。把本文第 6 章那套思路整理成自己的语言就行。开放类如果让你给客服场景设计一个 Agent你会怎么做参考思路先谈边界、工具、权限再谈单 Agent 还是多 Agent然后谈评测和安全最后给出最小可行范围。“Agent 从入门到精通”这个口号看着很大实际上就是一次次循环的迭代。你不需要同时学十个框架也不需要背住所有新名词。把一个最小循环吃透然后围绕它去扩建记忆、工具、评测、安全这比任何速成路径都走得更远。最后说一句我自己的体会。做 Agent 和之前写普通软件很不一样普通软件是你定义逻辑机器忠实地执行Agent 是你定义目标和边界模型在边界内自由发挥。这个“自由”既让人兴奋也让人不踏实。我经历了无数次“demo 惊艳但上线翻车”之后才真正接受一个道理Agent 的能力上限由模型决定但它的可靠性下限完全由工程决定。所谓从零构建 Agent其实是从零构建一套能让模型稳定发挥的工程系统。控制好循环、封装好工具、做好评测和安全剩下的就让模型自己去探索吧。