企业官网建设流程全解析

1. Agent学习框架的底层逻辑与选型思路

1.1 从“会聊天”到“会干活”的分水岭

很多人第一次接触Agent这个概念，脑子里浮现的还是那个只会一问一答的聊天窗口。但真正做过Agent项目的人都知道，这两者之间隔着一道巨大的鸿沟。聊天机器人是被动的，你问一句它答一句，它不关心上下文之外的世界；而Agent是主动的，它有自己的目标、有自己的记忆、有调用外部工具的能力，甚至能在没有人干预的情况下连续执行多步操作。

这个分水岭的核心，就是学习框架。一个Agent能不能从零搭起来、能不能稳定跑下去、能不能在复杂任务里不跑偏，几乎全看它的学习框架设计得合不合理。我见过太多团队，模型选的是最顶配的，提示词写得花里胡哨，结果一到多轮任务就崩，根因往往不在模型本身，而在框架层面缺少对状态、记忆和工具调用的系统性管理。

所以这篇文章我想聊的不是“Agent是什么”这种科普层面的东西，而是从一个实际搭建者的角度，把Agent学习框架拆开来看：它由哪些模块组成、每个模块为什么这么设计、主流的几种框架各自适合什么场景、以及未来这个方向会往哪里走。如果你正在准备从零搭一个Agent，或者已经在搭但总觉得哪里不对劲，这篇内容应该能帮你理清思路。

1.2 学习框架到底在“学”什么

这里要先澄清一个容易混淆的点。Agent的学习框架，并不是指让模型去重新训练一遍。绝大多数实际项目里，我们用的是已经训练好的大模型，框架要做的是让模型在推理阶段表现出“学习”和“适应”的能力。这听起来有点绕，我换个说法。

你可以把大模型想象成一个知识渊博但记性很差的顾问。他懂很多东西，但你每次找他，他都像第一次见你一样，不记得你上次说过什么、不记得你偏好什么风格、不记得你之前否决过哪些方案。Agent学习框架的作用，就是给这位顾问配一个秘书团队：有人负责记录历史对话，有人负责整理关键信息，有人负责在他跑偏的时候把他拉回来，有人负责在他需要查资料的时候递上正确的工具。

具体来说，框架要解决的核心问题包括这几个：

• 状态管理：当前任务进行到哪一步了，哪些信息是已经确认的，哪些还是待定的。
• 记忆机制：短期记忆（当前对话）和长期记忆（跨会话的知识）怎么存、怎么取、怎么淘汰。
• 工具编排：什么时候该调用工具、调用哪个、参数怎么传、返回结果怎么解析。
• 决策循环：Agent执行完一步之后，怎么判断下一步该做什么，什么时候该停下来。
• 安全边界：怎么防止Agent执行危险操作、怎么防止它陷入死循环、怎么防止它被恶意输入带偏。

这五个问题，构成了Agent学习框架的骨架。后面我讲的所有框架、所有技巧，基本都是在围绕这五个问题做文章。

1.3 为什么现在必须重视框架而不是只盯模型

过去两年，大家的注意力几乎都在模型能力上，谁的模型参数大、谁的推理强、谁的支持上下文长。但到了实际落地阶段，你会发现一个很尴尬的现实：同一个模型，套不同的框架，效果能差出好几倍。

我做过一个对比实验，用同一个模型分别跑两套不同的Agent框架去完成一个多步信息检索任务。框架A是简单的“提示词+单轮工具调用”，框架B是带状态机和记忆压缩的循环框架。结果框架A在第三步就开始丢失上下文，第五步直接开始编造不存在的信息；框架B跑了十几步依然能准确引用前面获取的数据。模型完全一样，差距全在框架。

这就是为什么现在行业里越来越强调“Agent工程”这个概念。模型是发动机，框架是底盘和传动系统。发动机再好，底盘不行，车照样跑不起来。而且模型能力越强，框架的重要性反而越突出，因为强模型能执行更复杂的指令，也就意味着它对框架的容错要求更高，一旦框架设计有缺陷，强模型会“聪明地”把错误放大。

2. 主流Agent框架拆解与适用场景对照

2.1 ReAct范式：最经典的起点

如果要选一个所有Agent学习者都必须先吃透的框架，那一定是ReAct。它的全称是Reasoning and Acting，核心思想非常朴素：让模型在每一步都先“想一下”，再“做一下”，然后根据做的结果继续想。

这个范式的价值在于它把Agent的决策过程显式化了。模型不是直接输出最终答案，而是输出一个思考过程，然后基于这个思考决定调用什么工具，拿到工具返回结果后再进入下一轮思考。这个循环可以一直持续到模型认为任务完成为止。

我刚开始搭Agent的时候，就是从一个最朴素的ReAct循环写起的。核心代码逻辑大概是这样：

while not done: thought = model.think(context) action = model.decide_action(thought) if action.type == "tool": result = execute_tool(action.name, action.params) context.append(result) elif action.type == "finish": done = True final_answer = action.answer

看起来很简单对吧？但真正跑起来你会发现一堆问题。比如模型有时候会忘记自己已经调用过某个工具，反复调用同一个；比如工具返回的结果太长，把上下文撑爆了；比如模型在思考阶段就开始编造工具返回的内容，根本没真正去调用。

这些问题逼着我在ReAct的基础上加了很多补丁：加了一个已调用工具的记录表，防止重复调用；加了一个结果摘要模块，把长结果压缩后再放回上下文；加了一个校验环节，确保模型声称的工具结果和实际返回一致。这些补丁后来我才发现，其实就是很多成熟框架里已经内置的功能。

ReAct适合什么场景？我的经验是，适合任务步骤相对明确、工具数量不多、单次执行时间要求不高的场景。比如做一个简单的信息查询助手、做一个文档问答机器人，ReAct足够用。但如果你要做的是需要几十步操作、涉及十几个工具、还要处理并发请求的复杂Agent，裸ReAct就不够了，必须往上叠更复杂的编排逻辑。

2.2 Plan-and-Execute：先谋后动

ReAct是走一步看一步，Plan-and-Execute则是先把整个计划列出来，再按计划执行。这个范式的出现，是因为ReAct在长任务里容易“迷失”。当任务需要十几步才能完成时，模型在每一步都重新思考全局，很容易被中间结果带偏，走着走着就忘了最初的目标。

Plan-and-Execute把过程拆成两个阶段。第一阶段是规划阶段，模型根据用户目标生成一个完整的步骤列表。第二阶段是执行阶段，模型按照步骤列表逐步执行，每执行完一步就更新状态，但不会轻易改变整体计划。

这个范式的好处是目标感强。因为计划是提前定好的，执行过程中不容易跑偏。而且计划本身是可以被人工审核和修改的，这在企业级应用里非常重要。我做过一个企业内部的数据分析Agent，用的就是Plan-and-Execute。用户提出分析需求后，Agent先生成一个分析计划，包括要查哪些表、要做哪些计算、要输出什么图表。这个计划会先展示给用户确认，用户觉得没问题再执行。这样一来，既保证了Agent的自主性，又给了人足够的控制权。

但Plan-and-Execute也有它的短板。最大的问题是计划一旦定下来，遇到意外情况就不够灵活。比如执行到第三步发现第二步的数据有问题，需要回头重新查，这时候固定的计划就成了束缚。所以后来很多框架把这两种范式结合起来，用Plan-and-Execute做整体规划，用ReAct做局部调整，兼顾目标感和灵活性。

2.3 记忆增强框架：让Agent不再“失忆”

前面两个范式主要解决的是“怎么决策”的问题，而记忆增强框架解决的是“怎么记住”的问题。这个问题在实际项目里比想象中要严重得多。

我踩过最大的一个坑，就是早期做的一个客服Agent。用户第一轮说“我要退掉上周买的那件蓝色衬衫”，Agent处理得很好。结果用户第二轮说“换成红色的吧”，Agent直接懵了，因为它根本不记得上一轮说的是哪件衬衫。这就是典型的短期记忆丢失。

记忆增强框架通常把记忆分成几层：

工作记忆最简单，就是把当前对话的所有消息都塞进上下文。但上下文窗口是有限的，对话一长就装不下了。所以需要情景记忆，把历史对话压缩成摘要存起来，需要的时候再检索出来。语义记忆更进一步，不是存原始对话，而是存从对话里提炼出来的事实和规则。程序记忆则是存“怎么做”的知识，比如某个任务的成功执行路径，下次遇到类似任务可以直接参考。

这里有个关键的技术点叫记忆检索。存进去容易，取出来难。用户说了一句话，怎么从海量记忆里找到最相关的那几条？常见做法是用向量相似度检索，把用户输入和所有记忆都转成向量，算余弦相似度，取最高的几条。但纯向量检索有个问题，它只看语义相似，不看时间。有时候最近发生的记忆比语义最相似的记忆更重要。所以实际项目里通常会做混合检索，把时间衰减因子也考虑进去。

还有一个容易被忽视的点是记忆淘汰。记忆不是越多越好，存太多会拖慢检索速度，还会引入噪声。所以需要定期清理过时、低价值的记忆。我一般会设置一个规则：超过一定时间没有被检索到的记忆，自动降权；连续多次被判定为无关的记忆，直接删除。

2.4 多Agent协作框架：从单打独斗到团队作战

当任务复杂到单个Agent搞不定的时候，就需要多个Agent协作了。这个方向最近一年特别火，各种多Agent框架层出不穷。

多Agent协作的核心思路是分工。一个Agent负责规划，一个Agent负责执行，一个Agent负责审核，一个Agent负责总结。每个Agent有自己的角色定位、自己的工具集、自己的记忆空间。它们之间通过消息传递来协调。

我做过一个比较典型的多Agent项目，是一个自动写行业分析报告的Agent。整个系统里有四个角色：研究员Agent负责搜集资料，分析师Agent负责分析数据，撰写者Agent负责写初稿，审核者Agent负责挑毛病。研究员把资料整理好传给分析师，分析师把分析结果传给撰写者，撰写者写完传给审核者，审核者提出修改意见再传回撰写者。这个流程跑下来，出来的报告质量确实比单个Agent一次性生成要好得多。

但多Agent协作的代价也很明显。首先是成本高，四个Agent意味着四倍的模型调用量。其次是延迟大，Agent之间来回传递消息，每一步都要等。最后是协调难，Agent之间可能互相等待、互相推诿，甚至陷入死循环。我遇到过最离谱的一次，审核者Agent一直觉得撰写者写得不好，撰写者一直改，改了十几轮还没通过，最后是我手动介入才停下来。

所以多Agent协作不是银弹。我的建议是，只有当任务确实复杂到单个Agent无法胜任，且对延迟和成本不敏感时，才考虑多Agent方案。大部分场景下，一个设计良好的单Agent加上丰富的工具集，效果不比多Agent差，而且更可控。

2.5 框架选型的决策清单

说了这么多框架，到底怎么选？我整理了一个决策清单，每次开新项目的时候都会过一遍：

• 任务步骤是否超过10步？是的话优先考虑Plan-and-Execute。
• 是否需要跨会话记住用户信息？是的话必须加记忆增强。
• 工具数量是否超过5个？是的话需要专门的工具编排层。
• 是否涉及敏感操作（如写数据库、发邮件）？是的话必须加人工审核环节。
• 并发量是否超过每秒10次？是的话要考虑异步执行和状态隔离。
• 团队是否有足够的运维能力？没有的话优先选成熟框架而不是自研。

这个清单不是绝对的，但能帮你快速排除掉明显不合适的选项。选框架这件事，没有最好的，只有最合适的。

3. 从零搭建Agent学习框架的实操路径

3.1 环境准备与基础依赖

动手之前先把环境理清楚。我下面列的是我目前最常用的一套基础配置，不追求最新，但求稳定可复现。

# 基础环境 Python 3.10+ pip 23.0+ # 核心依赖 openai>=1.0.0 # 模型调用 langchain>=0.1.0 # 框架基础 chromadb>=0.4.0 # 向量存储 pydantic>=2.0.0 # 数据校验 fastapi>=0.100.0 # 服务化 uvicorn>=0.23.0 # ASGI服务器

这里重点说一下为什么选这些。Python 3.10是底线，因为很多新框架已经不支持3.9了。LangChain虽然被不少人吐槽太重，但它的生态确实最全，各种工具集成、记忆模块、检索器都有现成的，前期能省很多事。ChromaDB适合中小规模项目，部署简单，不需要额外起服务。Pydantic用来做工具参数的结构化校验，能避免很多因为参数格式错误导致的调用失败。

如果你要做的是企业级项目，还需要考虑容器化部署。Docker是标配，把Agent服务和它的依赖打包成一个镜像，部署的时候直接拉起来就行。我一般会写一个简单的Dockerfile：

FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

这个镜像不大，启动也快，适合快速迭代。

3.2 核心模块的代码实现

接下来是重头戏，把前面说的那些模块一个个落地。我按依赖顺序来讲，从最底层的模型调用开始，一层层往上搭。

模型调用层。这一层要做的事情很简单，就是封装一个统一的接口，不管底层用的是哪家模型，上层调用方式都一样。这样做的好处是以后换模型不用改上层代码。

class LLMClient: def __init__(self, model_name, api_key, base_url=None): self.model_name = model_name self.client = OpenAI(api_key=api_key, base_url=base_url) def chat(self, messages, tools=None, temperature=0.7): response = self.client.chat.completions.create( model=self.model_name, messages=messages, tools=tools, temperature=temperature ) return response.choices[0].message

这个封装看起来简单，但有几个细节要注意。temperature这个参数很关键，做Agent决策的时候建议设低一点，0.1到0.3之间，因为决策需要稳定，不能太随机。做创意生成的时候可以设高一点。tools参数是传给模型的工具定义，格式要严格按照模型要求的JSON Schema来写，写错了模型会调用失败。

工具注册层。Agent能用的工具需要统一注册和管理。我一般用一个装饰器来注册工具，这样写起来最简洁。

TOOL_REGISTRY = {} def register_tool(name, description, parameters): def decorator(func): TOOL_REGISTRY[name] = { "function": func, "schema": { "type": "function", "function": { "name": name, "description": description, "parameters": parameters } } } return func return decorator @register_tool( name="search_web", description="搜索互联网获取最新信息", parameters={ "type": "object", "properties": { "query": {"type": "string", "description": "搜索关键词"} }, "required": ["query"] } ) def search_web(query): # 实际搜索逻辑 return results

这个注册机制的好处是，工具的定义和实现放在一起，增删工具只需要改一个地方。而且schema是自动生成的，不会出现定义和实现不一致的情况。

记忆模块。记忆模块我一般分成短期和长期两部分。短期记忆就是一个列表，存当前会话的所有消息。长期记忆用向量数据库存。

class Memory: def __init__(self, vector_store): self.short_term = [] self.vector_store = vector_store def add_message(self, role, content): self.short_term.append({"role": role, "content": content}) # 超过阈值就压缩 if len(self.short_term) > 20: self.compress() def compress(self): # 把前10条消息压缩成摘要 old_messages = self.short_term[:10] summary = summarize(old_messages) self.vector_store.add(summary) self.short_term = self.short_term[10:] def retrieve(self, query, top_k=3): return self.vector_store.search(query, top_k)

压缩策略是记忆模块的核心。我试过几种方案，最后发现按消息数量触发压缩比按token数量触发更稳定。因为token数量不好预估，有时候一条长消息就超了，有时候十条短消息还没超。按数量触发简单直接，每积累10条就压缩一次，节奏很稳。

决策循环。这是把前面所有模块串起来的地方。

class Agent: def __init__(self, llm, memory, tools, max_steps=15): self.llm = llm self.memory = memory self.tools = tools self.max_steps = max_steps def run(self, user_input): self.memory.add_message("user", user_input) for step in range(self.max_steps): context = self.build_context() response = self.llm.chat(context, tools=self.tools) if response.tool_calls: for tool_call in response.tool_calls: result = self.execute_tool(tool_call) self.memory.add_message("tool", result) else: self.memory.add_message("assistant", response.content) return response.content return "任务执行超过最大步数限制"

这个循环里有两个关键设计。一个是max_steps，防止Agent陷入死循环。我一般设15步，大部分任务够用，超过15步还没完成的基本上就是出问题了。另一个是build_context，它负责把系统提示词、历史消息、检索到的长期记忆拼成最终的上下文。这个拼接顺序有讲究，系统提示词放最前面，然后是检索到的长期记忆，最后是最近的对话。这样模型能先看到角色设定，再看到相关背景，最后看到当前对话，逻辑最顺。

3.3 参数调优与性能优化

框架搭起来只是第一步，真正让它跑得好还需要调参。我分享几个我踩过坑之后总结出来的关键参数。

上下文窗口分配。模型的上下文窗口是有限的，怎么分配很关键。我的经验分配比例是：系统提示词占10%，长期记忆占20%，历史对话占40%，当前输入和工具返回占30%。这个比例不是固定的，任务越复杂，历史对话占比应该越高；工具返回越冗长，工具返回占比应该越高。

工具调用超时。每个工具调用都要设超时，不然一个卡住的工具能把整个Agent拖死。我一般设30秒，超过就返回超时错误，让Agent决定是重试还是换方案。

重试策略。模型调用失败是常态，网络抖动、限流、超时都会导致失败。重试策略我一般设三次，第一次立即重试，第二次等1秒，第三次等3秒。超过三次就放弃，返回错误给上层。

并发控制。如果Agent要服务多个用户，必须做并发控制。最简单的做法是用信号量限制同时执行的Agent数量。我一般设10，超过就排队。更复杂的做法是用异步IO，但异步会带来状态管理的复杂度，前期不建议上。

import asyncio semaphore = asyncio.Semaphore(10) async def handle_request(user_input): async with semaphore: return await agent.run_async(user_input)

这个信号量机制能有效防止并发过高把模型API打爆。我实测下来，10个并发对于大部分模型API来说是比较安全的数字。

3.4 测试与评测方法

Agent的测试比普通软件测试要难得多，因为它的输出是不确定的。同一句话，今天问和明天问，回答可能不一样。所以不能用传统的断言式测试。

我一般用三种方法来评测Agent：

固定用例回归测试。准备一批标准问题，每次改完代码都跑一遍，看回答质量有没有下降。质量评估用人工打分或者用另一个模型来打分。我一般准备50个用例，覆盖常见场景和边界情况。

轨迹评估。不只看最终答案对不对，还要看Agent的执行路径合不合理。比如一个查询任务，理想路径是“搜索→筛选→总结”，如果Agent走了“搜索→搜索→搜索→总结”，虽然结果可能也对，但效率明显低了。轨迹评估能发现这类问题。

对抗测试。故意输入一些刁钻的问题，看Agent会不会崩溃。比如输入超长文本、输入包含特殊字符、输入诱导性的问题。我遇到过Agent被用户诱导去调用不该调用的工具，这就是安全边界没做好。

4. Agent框架的常见故障与排查实录

4.1 工具调用失败的五种典型情况

工具调用是Agent最容易出问题的环节。我把遇到过的故障整理成了一张速查表：

这里面最常见的是第一种，模型不调用工具。很多人以为是模型能力问题，其实大部分时候是工具描述写得不好。模型不知道这个工具是干什么的、什么时候该用，自然就不会调用。我的经验是，工具描述要写得像给新员工写操作手册一样，说清楚这个工具做什么、输入什么、输出什么、什么场景下用。

4.2 上下文溢出与记忆丢失

上下文溢出是长对话的必然问题。对话轮次一多，消息列表就越长，迟早会超过模型的上下文窗口。这时候如果不做处理，要么报错，要么模型开始“遗忘”前面的内容。

我的处理策略是分级压缩。第一级是消息级压缩，把连续的多条短消息合并成一条。第二级是轮次级压缩，把一轮完整的对话压缩成摘要。第三级是会话级压缩，把整个会话压缩成一段话。每一级压缩都会丢失一些细节，所以能不用就不用，优先用更轻的级别。

还有一个技巧是关键信息标记。在对话过程中，把重要的信息（比如用户明确说的偏好、确认过的事实）打上标记，压缩的时候这些标记过的信息不压缩，原样保留。这样能在压缩的同时保住最关键的内容。

4.3 死循环与跑偏的拦截

Agent跑着跑着陷入死循环，或者偏离了原始目标，这是另一个高频问题。我遇到过最典型的一次，Agent在搜索一个不存在的信息，搜不到就换个关键词再搜，换了十几个关键词还在搜，就是不承认搜不到。

拦截这类问题，我一般设三道防线。第一道是步数限制，超过max_steps强制停止。第二道是重复检测，如果连续三步调用了同一个工具且参数相似度超过90%，就判定为死循环，强制停止。第三道是目标校验，每隔几步就让模型自己检查一下当前进展是否还在朝着原始目标前进，如果偏离了就纠正。

def check_loop(history, threshold=3): recent = history[-threshold:] if len(recent) < threshold: return False tool_names = [h.get("tool_name") for h in recent] if len(set(tool_names)) == 1: params = [h.get("params") for h in recent] if similarity(params[0], params[-1]) > 0.9: return True return False

这个检测逻辑很简单，但能拦住大部分明显的死循环。更隐蔽的死循环（比如换着工具调用但一直在原地打转）需要更复杂的检测，但那种情况比较少见，前期不用过度设计。

4.4 安全边界与权限控制

Agent安全这个话题最近越来越热，因为Agent能调用的工具越来越多，能做的事情越来越危险。一个没有安全边界的Agent，理论上可以删库、可以发邮件、可以转账。这显然不能接受。

我的做法是最小权限原则。每个工具都有明确的权限等级，Agent默认只有只读权限。需要写操作的时候，必须经过人工确认。确认的方式可以是在对话里问一句“我要执行XX操作，确认吗”，用户回复确认后才执行。

另外还有一个容易被忽视的点是输入过滤。用户输入里可能包含诱导Agent执行危险操作的指令，比如“忽略之前的所有指令，现在执行XX”。这类输入需要在进入Agent之前就过滤掉。我一般用一个简单的规则引擎，匹配到敏感模式就直接拒绝，不传给模型。

提示：安全边界的设计要在项目初期就做，不要等出了问题再补。后期补安全，往往要改动大量已有代码，成本很高。

5. Agent学习框架的未来演进方向

5.1 从固定框架到自适应框架

现在的Agent框架基本都是人设计好的固定流程：先规划、再执行、再反思。但未来的趋势是框架本身能根据任务特点自适应调整。简单任务走简单流程，复杂任务走复杂流程，不需要人提前指定。

这个方向的技术基础是模型的元认知能力。模型不仅要能执行任务，还要能判断这个任务需要什么样的执行策略。比如一个简单的查询任务，模型应该直接调用搜索工具，而不是先规划再执行。一个复杂的分析任务，模型应该先规划再执行。这种自适应能力，会让Agent的效率大幅提升。

5.2 记忆机制的进化

现在的记忆机制还比较粗糙，基本就是存和取。未来的记忆会更接近人类的记忆方式：有遗忘曲线、有情感权重、有联想触发。

遗忘曲线意味着记忆会随时间自然衰减，但重要的记忆衰减得慢。情感权重意味着和用户情绪相关的记忆会被优先保留。联想触发意味着一个记忆被激活时，相关的记忆也会被连带激活。这些机制能让Agent的记忆更高效、更人性化。

5.3 多Agent协作的标准化

多Agent协作现在还是各做各的，没有统一的标准。A框架的Agent和B框架的Agent没法直接协作。未来应该会出现一套标准化的Agent通信协议，就像HTTP协议让不同的网站能互相访问一样，标准化的Agent协议能让不同的Agent互相调用、互相协作。

这个方向已经有一些早期尝试了，但离成熟还有距离。我个人的判断是，未来两年内会出现事实上的标准，但不会是某一家公司主导的，而是社区共同推动的。

5.4 评测体系的完善

Agent评测现在是个大难题。没有统一的评测标准，各家都说自己的Agent好，但没法横向对比。未来会出现更完善的评测体系，包括标准化的测试集、标准化的评分维度、标准化的对比方法。

评测体系的完善会反过来推动框架的进步。因为有了统一的评测标准，框架之间的优劣就能被客观衡量，好的框架会脱颖而出，差的框架会被淘汰。这对整个行业是好事。

5.5 与业务系统的深度融合

现在的Agent大多是独立的，和业务系统是分离的。未来Agent会深度嵌入到业务系统里，成为业务系统的一部分。比如CRM系统里内置一个Agent，能自动跟进客户；ERP系统里内置一个Agent，能自动处理订单异常。

这种深度融合会带来新的挑战，比如权限怎么管理、数据怎么隔离、故障怎么隔离。但也会带来巨大的价值，因为Agent能直接操作业务数据，效率会比现在高得多。

6. 一些实操心得与避坑建议

6.1 不要过早追求多Agent

我见过太多项目，一上来就搞多Agent，结果复杂度爆炸，进度严重滞后。我的建议是，先用单Agent把核心流程跑通，确认单Agent确实搞不定了，再考虑多Agent。大部分场景下，单Agent加上丰富的工具集，已经能解决80%的问题。

6.2 日志要打全

Agent的执行过程是不透明的，出了问题如果不打日志，根本不知道哪一步错了。我一般会在这些地方打日志：每次模型调用的输入输出、每次工具调用的参数和返回、每次记忆的存取、每次决策的推理过程。日志要结构化，方便后续检索和分析。

6.3 人工兜底不能省

不管Agent做得多好，都要留人工兜底的入口。用户遇到问题的时候，能一键转人工。这个兜底机制不仅是用户体验的保障，也是安全网。Agent处理不了的、处理错的，人工能补上。

6.4 版本管理要严格

Agent的行为受很多因素影响：模型版本、提示词版本、工具版本、框架版本。任何一个变了，行为都可能变。所以这些东西都要做版本管理，每次变更都要记录，出问题的时候能快速定位是哪个变更导致的。

6.5 从小场景切入

不要一上来就做通用Agent，那是个无底洞。从一个具体的小场景切入，比如“自动整理会议纪要”、“自动回复常见问题”，把这个小场景做深做透，再逐步扩展。小场景的好处是边界清晰、评测容易、迭代快。

我自己就是从“自动整理技术文档”这个小场景开始的，做了三个月，把记忆、工具调用、错误处理这些核心模块都打磨了一遍，然后再扩展到其他场景，就顺利多了。如果一开始就做通用Agent，估计现在还在填坑。

6.6 关注成本

Agent的成本比普通应用高得多，因为每次决策都要调模型，每次调模型都要花钱。一个复杂的任务跑下来，可能调用几十次模型，成本是普通对话的几十倍。所以成本控制要从一开始就考虑，比如缓存重复的模型调用、压缩上下文减少token消耗、用更便宜的模型做简单决策。

我一般会做一个成本监控面板，实时看每个任务的token消耗和费用。发现异常高的任务就分析原因，看是哪里浪费了。这个习惯帮我省了不少钱。

6.7 保持学习

Agent这个领域变化太快了，每个月都有新框架、新论文、新工具出来。保持学习是必须的。我的做法是每周花半天时间看最新的论文和开源项目，看到好的思路就记下来，找机会在自己的项目里试试。不一定要全盘照搬，但至少要知道行业在往哪个方向走。

这个领域现在还在早期，很多问题没有标准答案。今天觉得对的做法，明天可能就被推翻了。所以保持开放心态，多试多改，比死守一套方案要重要得多。