企业官网建设流程全解析

AI智能体开发这件事，从2024年下半年开始就明显升温，到2025年已经成了后端和全栈工程师绕不开的一个方向。我身边不少做传统业务开发的朋友，最初都觉得Agent不过是"套壳调API"，直到真正上手做第一个能跑通业务闭环的项目，才发现里面涉及的东西远比想象中多——工具调用怎么设计、记忆怎么存、多轮任务怎么编排、并发上来之后怎么不崩，每一个环节都有坑。这篇内容就是把我自己在多个真实场景里踩过的路整理出来，围绕"AI智能体Agent实战开发"这个主题，从场景拆解到全链路落地，尽量把能复现的细节都写清楚。不管你是刚接触Agent概念的新手，还是已经写过几个Demo但卡在工程化阶段的老手，都能从里面找到能直接用的东西。

1. 先搞清楚Agent到底解决的是哪类问题

很多人一上来就问"Agent框架选哪个"，这个问题其实问早了。选框架之前，得先弄明白Agent和普通的大模型调用到底差在哪，不然做出来的东西大概率是个"伪Agent"——看着能对话，实际上一旦任务稍微复杂一点就露馅。

1.1 从"一问一答"到"自主完成任务"的跨越

普通的大模型调用，本质上是无状态的：你给它一段输入，它给你一段输出，结束。它不会记得你上一轮说了什么（除非你手动把历史拼进去），也不会主动去查资料、调接口、改自己的计划。而Agent的核心区别在于，它具备目标驱动的多步执行能力。

举个具体的例子。用户说"帮我看看这个季度华东区的销售数据，找出下滑最严重的三个城市，然后给对应的负责人发一封提醒邮件"。这句话如果丢给普通大模型，它只能给你一段文字建议，比如"你可以先查询数据库……"。但一个真正的Agent会这样做：先调用数据查询工具拿到华东区数据，然后对结果做分析排序，识别出下滑最严重的城市，接着调用通讯录接口找到负责人邮箱，最后调用邮件发送工具把内容发出去。整个过程它自己决定下一步做什么，遇到工具报错还会重试或者换方案。

这个"自己决定下一步"的能力，就是Agent的灵魂。它依赖三个东西：规划能力（把大目标拆成小步骤）、工具调用能力（能操作外部世界）、记忆能力（记住已经做了什么、还差什么）。

1.2 哪些场景真的需要Agent，哪些不需要

我见过太多项目，明明一个简单的分类任务，非要套个Agent架构，结果又慢又贵还不稳定。所以这里必须先泼盆冷水：不是所有场景都适合用Agent。

适合Agent的场景通常满足这几个特征：任务步骤不固定、需要和外部系统交互、中间结果会影响后续决策。比如：

• 客服工单自动处理：需要查订单、查物流、判断是否符合退款条件、生成回复，步骤随情况变化
• 代码审查助手：需要读代码、跑静态检查、查历史提交、给出修改建议
• 数据分析助手：需要根据数据特征决定用哪种分析方法，中途可能反复调整
• 多步骤信息收集：比如调研某个行业，需要搜索、筛选、交叉验证、汇总

而不适合的场景也很明确：单轮问答、固定流程的批处理、对延迟极度敏感的任务。这些用普通的大模型调用或者传统程序逻辑就够了，硬上Agent只会增加成本和不确定性。

提示：判断标准很简单——如果这个任务的执行路径用if-else就能写清楚，那就别用Agent。Agent的价值在于处理"路径不确定"的问题。

1.3 一个Agent的最小可用结构

抛开各种框架的包装，一个能跑起来的Agent最小结构其实就四块：

1. 大脑（LLM）：负责推理和决策，是整个系统的核心
2. 工具集（Tools）：Agent能调用的外部能力，每个工具都有明确的输入输出定义
3. 记忆（Memory）：短期记忆存当前任务的上下文，长期记忆存跨会话的知识
4. 执行循环（Loop）：不断重复"思考-行动-观察"这个过程，直到任务完成或达到终止条件

这个循环就是常说的ReAct模式（Reasoning + Acting）。它的工作方式是：模型先输出一段思考（Thought），然后决定调用哪个工具（Action），拿到工具返回结果（Observation）后继续思考，如此往复。理解这个循环，比记住任何框架的API都重要，因为所有框架本质上都是在这个循环上做工程优化。

2. 场景拆解：20+真实场景该怎么分类和取舍

标题里说"20+真实场景"，但真做项目的时候，你不可能每个场景都从零搭一遍。更高效的做法是按能力维度把场景归类，同一类场景共用一套底层架构，只在工具和提示词层面做差异化。我一般把Agent场景分成下面几大类。

2.1 信息检索与整合类场景

这类场景的共性是：Agent需要从多个来源获取信息，然后整合成用户要的答案。典型的有行业调研助手、竞品分析助手、文献综述助手、新闻聚合助手。

核心难点在于信息源的质量控制和去重。我做过一个竞品分析Agent，最初的设计是让它自己决定搜什么关键词，结果它经常搜出一堆重复内容，还容易被营销软文带偏。后来改成了"先由人给定信息源白名单，Agent只在白名单内检索和整合"，效果立刻稳定了。

这类场景的工具设计要点：

• 搜索工具要支持指定来源范围，而不是全网乱搜
• 加一个"内容质量打分"工具，让Agent自己过滤低质内容
• 整合阶段强制要求引用来源，避免编造

2.2 数据处理与分析类场景

这类场景包括销售数据分析、用户行为分析、财务报表解读、日志异常检测等。它们的共同点是：Agent需要操作结构化数据，并且分析结果要能追溯到原始数据。

这里最大的坑是让Agent直接写SQL或Pandas代码去跑。听起来很酷，但实际生产环境里风险极高——万一它写了个全表扫描，或者误删数据，后果很严重。我的做法是：把常用的数据操作封装成受限的工具，比如"按条件查询订单表"这个工具，内部已经限定了只能查、只能查指定字段、必须带时间范围。Agent只能调用这些安全工具，不能自由发挥。

2.3 内容生成与编辑类场景

文案生成、代码生成、报告撰写、翻译润色都属于这一类。这类场景看起来简单，其实对风格一致性和事实准确性要求很高。

我踩过的一个坑是：让Agent写产品介绍，它每次输出的风格都不一样，有时候很正式有时候很口语。后来在系统提示词里加了一段"风格锚定"——给它三篇范文，要求它模仿这个风格，并且每次生成后用一个独立的"风格检查"工具打分，不达标就重写。这个双保险机制让输出稳定性提升了很多。

2.4 流程自动化与任务编排类场景

这类场景是Agent最能体现价值的地方，包括自动化工单处理、定时报告生成、多系统数据同步、审批流程自动化等。

关键点是幂等性和可恢复性。Agent执行到一半挂了怎么办？重试的时候会不会重复发邮件、重复扣款？这些必须在设计阶段就考虑。我的经验是给每个关键操作加一个"操作日志"工具，Agent每次执行前先查日志，确认这个操作没做过再执行。

2.5 多Agent协作类场景

当单个Agent搞不定复杂任务时，就需要多个Agent分工。比如一个"项目经理Agent"负责拆解任务，然后分给"调研Agent""写作Agent""审核Agent"，最后汇总。

但我要提醒一句：多Agent不是越多越好。每增加一个Agent，通信成本和出错概率都会上升。我见过一个项目用了七个Agent，结果调试起来简直是噩梦。大多数场景下，两到三个Agent就够了，超过五个就要重新审视架构是否合理。

3. 工具调用设计：Agent能不能干活全看这一步

工具调用是Agent和外部世界交互的唯一通道，设计得好不好，直接决定了Agent是"能干活的助手"还是"只会聊天的玩具"。这一块我踩的坑最多，也最有心得。

3.1 工具粒度的把握：太粗和太细都是灾难

工具设计第一个要解决的问题是粒度。工具太粗，比如只给一个"执行任意操作"的工具，Agent根本不知道怎么用；工具太细，比如把"打开文件""读取第一行""读取第二行"拆成三个工具，Agent会被淹没在细节里。

我的经验法则是：一个工具对应一个完整的业务动作。比如"查询用户订单"是一个工具，"发送邮件"是一个工具，但"连接数据库""执行SQL""关闭连接"不应该拆成三个工具，而应该封装成一个"查询订单"工具。

判断粒度是否合适，有个简单方法：看这个工具的名字能不能用一句人话描述清楚，并且这句话里不包含"然后"。如果包含"然后"，说明它其实是多个动作，应该拆开；如果一句话说不清楚，说明太细了。

3.2 工具描述怎么写才能让模型用对

工具的描述（description）是模型决定要不要调用它的唯一依据，写得好不好直接影响调用准确率。我见过很多项目，工具功能没问题，但描述写得太随意，导致模型要么不调用，要么乱调用。

好的工具描述应该包含四要素：

• 做什么：一句话说清功能
• 什么时候用：明确使用场景
• 参数含义：每个参数是什么、什么格式、是否必填
• 返回什么：返回结果的结构和含义

举个例子，对比一下两种写法：

差的写法：

name: search description: 搜索

好的写法：

name: search_orders description: 根据用户ID和时间范围查询订单列表。当用户询问订单状态、订单金额、订单时间时使用此工具。不要用于查询用户信息或商品信息。 parameters: user_id: 用户唯一标识，字符串，必填 start_date: 查询起始日期，格式YYYY-MM-DD，必填 end_date: 查询结束日期，格式YYYY-MM-DD，必填 returns: 订单列表，每条包含订单号、金额、状态、创建时间

第二种写法里，我特意加了"不要用于查询用户信息或商品信息"这句负向约束。这是实战中总结出来的技巧——明确告诉模型什么情况下不要用这个工具，能大幅减少误调用。

3.3 参数校验和错误处理：别让Agent被一个报错卡死

工具调用失败是常态，网络抖动、参数格式错、权限不足都会导致失败。如果Agent遇到报错就卡住，那这个系统根本没法用。

我的处理策略分三层：

第一层是参数预校验。在工具真正执行前，先检查参数格式。比如日期格式不对，直接返回"日期格式错误，请使用YYYY-MM-DD格式"，而不是让工具去执行然后抛异常。这样Agent能立刻知道怎么改。

第二层是错误信息友好化。工具抛出的原始异常往往是一堆堆栈信息，模型看不懂。要把它转换成模型能理解的自然语言，比如把"KeyError: 'user_id'"转成"缺少必填参数user_id，请补充后重试"。

第三层是重试与降级。对于网络类错误，允许自动重试2-3次；对于参数类错误，把错误信息返回给模型让它自己修正；对于权限类错误，直接终止并告知用户。

注意：重试一定要设置上限，否则Agent可能陷入无限重试的死循环。我一般设置最多3次，超过就放弃并返回明确错误。

3.4 工具的安全边界：哪些能力绝对不能给

这是最容易被忽视但最重要的一点。Agent再智能，它也是在执行代码，给它太大的权限等于埋雷。

绝对不能开放的能力包括：任意代码执行、任意文件读写、任意数据库写操作、发送真实资金交易、删除类操作。如果业务确实需要这些，必须加人工确认环节。

我的做法是给工具分三级：

• 只读级：查询类操作，Agent可以自由调用
• 写入级：会产生副作用的操作，需要记录日志，部分需要二次确认
• 危险级：涉及资金、删除、对外发送的操作，必须人工审批

这个分级不是技术限制，而是流程约束。技术上Agent能调用任何工具，但流程上我们要确保危险操作有人把关。

4. 记忆机制：让Agent不再"金鱼脑"

没有记忆的Agent，每次对话都像第一次见面，用户体验极差。但记忆也不是越多越好，存太多会导致上下文爆炸、检索变慢、成本飙升。怎么设计记忆机制，是Agent工程化的核心课题之一。

4.1 短期记忆和长期记忆的分工

短期记忆就是当前任务的上下文，包括用户说了什么、Agent做了什么、工具返回了什么。它通常直接放在提示词里，或者用对话历史的形式传给模型。

长期记忆是跨会话的知识，比如用户的偏好、历史订单、常见问题的解决方案。它不能直接塞进提示词，需要存到外部存储（向量数据库、关系数据库、键值存储），用到的时候再检索出来。

两者的分工原则是：短期记忆保证当前任务连贯，长期记忆保证跨任务个性化。不要把长期记忆全塞进短期上下文，那样既浪费token又干扰模型判断。

4.2 上下文窗口管理：什么时候该压缩，什么时候该丢弃

上下文窗口是有限的，任务一长就会超。这时候需要做上下文管理，常见策略有三种：

滑动窗口：只保留最近N轮对话，老的直接丢弃。简单粗暴，但会丢失早期重要信息。

摘要压缩：把早期对话用模型总结成一段摘要，保留关键信息。比滑动窗口聪明，但摘要本身也可能丢信息。

分层存储：把对话按重要性分级，重要的完整保留，次要的压缩，无关的丢弃。

我实际项目里用的是混合策略：最近5轮完整保留，5-20轮做摘要，20轮以上只保留关键决策点。这个阈值不是固定的，要根据任务复杂度调整。任务越复杂，保留的轮次越多。

4.3 向量检索在记忆中的应用与坑

长期记忆最常用的技术是向量检索：把历史信息转成向量存起来，需要的时候用相似度搜索找出来。听起来很美，但实际用起来有几个坑。

第一个坑是检索精度。向量检索找出来的是"语义相似"的内容，但不一定是"当前需要"的内容。比如用户问"我上次买的那个东西到哪了"，向量检索可能找出一堆购物记录，但分不清是哪一次。解决办法是结合元数据过滤，比如加上时间范围、订单状态等条件。

第二个坑是更新延迟。用户刚说的话，如果还没写入向量库，下次检索就找不到。所以关键信息要同步写入，不能只靠异步。

第三个坑是成本。每次检索都要调用embedding接口，量大起来成本不低。我的做法是对高频查询做缓存，对低频查询才走实时检索。

4.4 记忆的写入策略：不是所有对话都值得记

很多项目犯的错误是把所有对话都往记忆里塞，结果记忆库越来越臃肿，检索越来越慢，还经常检索出无关内容干扰判断。

我的写入策略是选择性记忆：

• 用户的明确偏好（"我喜欢简洁的回答"）——必记
• 任务的关键结论（"这个订单已经退款"）——必记
• 用户的身份信息（"我是VIP用户"）——必记
• 普通寒暄、重复确认——不记
• 工具返回的原始数据——不记，只记结论

这个策略能大幅压缩记忆库体积，同时保证关键信息不丢。

5. 工作流编排：从单步调用到复杂任务链路

单个工具调用好做，难的是把多个步骤串成一条稳定的链路。工作流编排就是解决这个问题的，它决定了Agent能不能处理真实业务里的复杂任务。

5.1 线性编排、分支编排和循环编排

最基础的是线性编排：步骤A→步骤B→步骤C，一路走到底。适合流程固定的任务，比如"查订单→判断状态→生成回复"。

分支编排是在某个节点根据条件走不同路径。比如"如果订单已发货，走物流查询分支；如果未发货，走催单分支"。这需要Agent具备条件判断能力。

循环编排是某个步骤要重复执行直到满足条件。比如"不断搜索直到找到符合条件的信息"或者"反复修改直到通过审核"。循环最容易出问题，必须设置最大循环次数，否则可能死循环。

实际项目里这三种往往是混合使用的。一个完整的客服Agent可能是：线性走主流程，中间根据订单状态分支，在信息收集环节循环。

5.2 状态管理：任务执行到一半挂了怎么办

这是工程化里最容易被忽视的问题。Agent执行一个长任务，可能涉及十几个步骤，如果执行到第八步时服务重启了，前面七步的成果怎么保住？

我的方案是显式状态机。把任务的每个步骤定义成一个状态，状态之间的转换条件明确写出来，每次状态变更都持久化到数据库。服务重启后，从数据库读取最后的状态，继续往下执行。

这样做的好处是：任务可恢复、可追溯、可人工干预。坏处是开发复杂度上升，需要额外维护状态定义和转换逻辑。但对于生产级Agent，这个投入是值得的。

5.3 超时、重试与熔断

外部调用总是不稳定的，工作流编排必须处理这些异常。

超时：每个工具调用都要设超时，不能无限等待。我一般设10-30秒，根据工具类型调整。

重试：对于幂等的只读操作，失败可以重试；对于写操作，重试要谨慎，避免重复执行。

熔断：如果某个工具连续失败多次，暂时停止调用它，避免拖垮整个流程。等一段时间后再试探性恢复。

这三个机制配合使用，能大幅提升工作流的稳定性。我做过对比测试，加了熔断机制后，整体任务成功率从78%提升到了94%。

5.4 人工介入节点怎么设计

再智能的Agent也有搞不定的时候，这时候需要人工介入。人工介入节点设计得好不好，直接影响运营效率。

我的设计原则是：能自动的绝不人工，必须人工的要给足上下文。

具体做法是：当Agent判断自己无法处理时，生成一个"待人工处理"的任务，任务里包含完整的执行历史、当前卡点、Agent的建议方案。人工处理时不用重新了解情况，直接看Agent整理好的信息就能决策。

处理完之后，人工的决策结果要反馈回Agent，让它学习。这样下次遇到类似情况，Agent可能就能自己处理了。

6. 并发与性能：Agent扛不住并发就是玩具

Demo阶段单用户跑得飞快，一上生产环境多用户并发就崩，这是Agent项目最常见的翻车场景。这一块必须提前设计。

6.1 Agent为什么比普通接口更吃资源

普通接口一次请求可能就几十毫秒，Agent一次任务可能涉及多次模型调用和工具调用，耗时几秒到几十秒不等。而且每次模型调用都占用显存或API配额，并发一高就容易排队。

更麻烦的是，Agent是有状态的，每个用户的会话要独立维护上下文，不能像无状态接口那样随便水平扩展。这就导致单机能支撑的并发数很有限。

6.2 会话隔离与资源池化

解决并发的第一步是做好会话隔离。每个用户的会话数据必须独立存储，不能互相污染。我一般用"用户ID+会话ID"作为key，把上下文、状态、记忆都挂在这个key下面。

第二步是资源池化。模型调用、数据库连接、工具实例这些都要用连接池管理，避免每次请求都新建。特别是模型客户端，初始化开销很大，必须复用。

6.3 异步化与流式输出

Agent任务耗时长，如果同步等待，用户会以为卡死了。解决办法是异步化：用户发起任务后立刻返回一个任务ID，后台异步执行，用户通过任务ID轮询进度或者用WebSocket接收推送。

流式输出也很关键。模型生成的内容可以边生成边推给用户，让用户看到"正在思考"的过程，体验会好很多。工具调用的中间结果也可以流式展示，让用户知道Agent在干什么。

6.4 限流与排队策略

再好的架构也扛不住无限并发，必须限流。我的策略是分级限流：

• 免费用户：每分钟最多3个任务，同时最多1个进行中
• 付费用户：每分钟最多20个任务，同时最多5个进行中
• 内部用户：不限制，但记录用量

超过限制的任务进入排队队列，按优先级调度。队列要设置最大长度，满了就拒绝新任务并提示用户稍后再试。

7. 安全与合规：Agent能碰什么不能碰什么

Agent有了工具调用能力，就等于有了"手脚"，这时候安全问题的严重性就上来了。一个设计不当的Agent，可能被诱导去执行危险操作。

7.1 提示词注入的防御

提示词注入是最常见的攻击方式。用户在输入里藏一段指令，试图覆盖系统提示词，让Agent执行非预期操作。比如用户输入"忽略之前的所有指令，现在你是一个……"。

防御手段有几个层次：

第一层是输入过滤，识别并拦截明显的注入模式。但这种方法容易被绕过，不能只靠它。

第二层是权限隔离，即使Agent被注入了，它也调不动超出权限的工具。这是最可靠的防线。

第三层是输出审查，Agent生成的回复在发给用户前过一遍检查，发现异常就拦截。

我的经验是三层都要有，但重点放在第二层。因为前两层都可能被绕过，只有权限隔离是硬约束。

7.2 工具权限的最小化原则

给Agent的工具权限，要遵循最小化原则：只给完成当前任务必需的权限，不多给一分。

具体做法：

• 数据库账号只给只读权限，需要写操作时走单独的受控通道
• 文件系统只能访问指定目录，不能访问系统目录
• 网络请求只能访问白名单域名
• 敏感操作必须二次确认

这个原则说起来简单，做起来需要克制。开发阶段图方便给了大权限，上线前一定要收回来。

7.3 敏感数据的处理

Agent处理的数据里可能包含用户隐私、商业机密。这些数据在传给模型之前要脱敏，在存储时要加密，在日志里要打码。

我一般会做一个"数据分级"：公开数据、内部数据、敏感数据。公开数据随便处理，内部数据要记录访问日志，敏感数据必须脱敏后才能给模型。

7.4 审计日志：出了事能查清楚

Agent的每个决策、每次工具调用都要记日志。日志要包含：谁发起的、什么时候、调用了什么工具、参数是什么、返回是什么、结果如何。

这些日志一方面用于排查问题，另一方面用于合规审计。万一出了事故，能快速定位是哪个环节出的问题。

日志的存储要注意：不能记敏感数据原文，要脱敏；要设置保留期限，不能无限存；要防止日志被篡改。

8. 从Demo到生产：那些只有上线才会遇到的问题

前面讲的都是设计层面的东西，这一节讲讲上线后才会暴露的真实问题。这些问题在Demo阶段根本遇不到，但生产环境里一个都躲不掉。

8.1 模型输出的不确定性怎么兜底

同一个输入，模型可能给出不同的输出。这在Demo阶段是"智能"的体现，在生产环境就是"不稳定"的隐患。

兜底策略有几个：

• 关键字段用结构化输出（JSON Schema约束），减少自由发挥
• 重要决策加校验规则，不符合规则的输出直接拒绝重试
• 对同一任务多次采样，取多数一致的结果

我做过一个测试，加了结构化输出约束后，格式错误率从12%降到了0.3%。

8.2 成本控制：Token烧起来比想象中快

Agent一次任务可能调用模型十几次，每次都是钱。如果不加控制，成本会失控。

控制手段：

• 简单任务用小模型，复杂任务才用大模型
• 缓存常见问题的答案，避免重复计算
• 压缩提示词，去掉冗余内容
• 设置单任务Token上限，超了就终止

我算过一笔账，一个中等复杂度的Agent任务，优化前平均消耗8000 token，优化后降到3500 token，成本直接砍半。

8.3 效果评估：怎么知道Agent干得好不好

Agent的效果不能靠感觉，要有量化指标。我一般看这几个：

• 任务完成率：成功完成的任务占比
• 平均步数：完成任务平均用了几步，步数越少越好
• 工具调用准确率：调用的工具是否恰当
• 用户满意度：用户是否认可结果
• 人工介入率：多少任务需要人工兜底

这些指标要持续监控，发现异常及时排查。比如任务完成率突然下降，可能是某个工具挂了，或者模型更新导致行为变化。

8.4 版本迭代与灰度发布

Agent的提示词、工具、模型任何一个变了，效果都可能变。所以每次变更都要灰度发布，先小流量验证，没问题再全量。

我的做法是维护多个版本的Agent配置，通过流量比例控制灰度。比如新版本先给5%流量，观察一天，指标正常再逐步放大。

回滚机制也要准备好。一旦新版本出问题，能快速切回旧版本。

9. 学习路线与实战建议

最后聊聊怎么系统地学Agent开发。这块内容网上很杂，我按自己的经验给一条相对清晰的路径。

9.1 从理解ReAct循环开始

不要一上来就学框架，先把ReAct循环搞明白。自己用最朴素的方式实现一个"思考-行动-观察"的循环，哪怕只有一两个工具，跑通了你就理解了Agent的本质。

这个阶段推荐动手写一个简单的计算器Agent或者天气查询Agent，不依赖任何框架，纯手写循环。写完你会发现，所谓Agent框架，核心就是帮你把这个循环封装好了。

9.2 框架选型的考量维度

理解原理之后，再选框架。选型看几个维度：

• 生态成熟度：文档是否完善，社区是否活跃
• 可扩展性：能不能方便地加自定义工具
• 可观测性：有没有调试和监控支持
• 部署方式：能不能私有化部署，是否符合数据合规要求
• 学习曲线：团队上手要多久

没有绝对最好的框架，只有最适合当前项目的。小项目用轻量框架，大项目用生态完善的框架。

9.3 从单Agent到多Agent的进阶路径

不要一上来就搞多Agent，先把单Agent做扎实。单Agent能稳定处理80%的场景后，再考虑多Agent。

进阶路径建议是：单Agent单工具→单Agent多工具→单Agent带记忆→多Agent协作。每一步都要有实际项目验证，不要跳步。

9.4 持续跟进的方向

Agent这个领域变化很快，新方法、新工具层出不穷。值得持续关注的方向包括：更高效的规划算法、更可靠的工具调用、更长的上下文管理、多模态Agent、Agent的安全与对齐。

但不管技术怎么变，核心能力是不变的：理解业务、拆解任务、设计工具、管理状态、保证稳定。这些是基本功，值得花时间打磨。

我在实际项目里最大的体会是，Agent开发看起来是AI的事，实际上大部分工作是传统软件工程的事——状态管理、错误处理、并发控制、安全防护，这些才是决定项目成败的关键。模型能力只是其中一环，而且随着模型越来越强，这一环的重要性反而在下降。所以如果你是从传统开发转过来的，别觉得自己不懂AI就做不了Agent，你的工程经验恰恰是这个领域最稀缺的。