企业官网建设流程全解析

如果你问我今年在AI领域把时间花在哪最值，我的答案非常明确：学清楚AI Agent（智能体）。大模型本身是“大脑”，但真正能帮你干活、能自动完成任务、能在真实工作流里创造价值的，是围绕大模型构建的Agent体系。这个判断不是我拍脑袋说的，2025年整个行业的产品形态已经很明显了——从AI编程到多AI协作，从自动化测试到各种“AI员工”，本质都是在把一个能对话的大模型变成能行动的系统。

我身边不少朋友拿着大模型API玩了一个月，聊天、绘画、翻译都试了一遍，然后陷入迷茫：好像AI很厉害，但也就这样了。问题就出在他们只学了“对话模型”，没学“行动系统”。这就像你请了一个智力超群的助理，但他只会坐在那里跟你聊天，不会打电话、不会查资料、不会推流程，那他的价值就打了九折。Agent要解决的正是这个“最后一公里”问题。

这篇文章我想从“为什么是Agent”“基础要怎么打”“怎么从零搭一个能干活的最小Agent”“它如何在AI编程和测试里实战”以及“常见坑怎么排”这五个角度，把今年最值得学的东西讲透。无论你是程序员、产品经理、运营还是测试，下面这些内容都能直接用。

1. 为什么今年最值得学的是AI Agent

1.1 大模型是“大脑”，Agent才是“完整的人”

单次调用大模型，你输入提示词，模型返回一段文字，仅此而已。它的能力边界非常清晰：理解语言、生成语言、做一定的推理。但如果任务变成“帮我盯着这个网页的价格变化，降到预期值就发邮件通知我”“把这个Excel里的数据清洗完，按规则生成报表并发到群里”，单靠对话模型是完不成的，因为对话模型没有手、没有眼睛、没有记忆，也没有持续运行的能力。

Agent的本质就是在模型外面套了一层“行动系统”。它把大模型作为决策核心，然后给它接上工具、接上记忆、接上任务拆解逻辑，让它能在一个多步骤任务里自主地决定下一步干什么、调用什么工具、检查结果对不对。打个生活化的比方：大模型是一个知识渊博的顾问，而Agent是那个真正帮你把事跑完的项目经理。顾问负责出主意，项目经理负责把主意拆成动作、分配资源、盯进度、处理异常。

这个差异化在今年的行业信号里也特别明显。OpenAI的Operator、Anthropic的Computer Use、国内厂商密集推出的Agent类产品，以及社区里火爆的MCP（模型上下文协议）生态，全都是在做同一件事：让模型从“会说话”变成“会办事”。所以你说今年学AI哪个概念最值得学？不是追问某个模型的参数细节，而是把“如何构建一个能自主行动的AI系统”这套方法论学到手，这才是长期能复用的能力。

1.2 Agent的五个核心能力模块，每个都对应一套技术栈

一个能稳定干活的Agent，至少要具备五块能力。我把它拆开讲，方便你对照着自己缺哪块。

感知（Perception）解决的是“Agent怎么获取信息”。有的是通过用户输入，有的是通过API拉数据，有的是读取文件，还有的是抓网页。在多模态模型成熟后，感知还包含“看图”“听声音”。这块相对比较好实现，但要注意数据格式的统一。比如你给Agent读PDF、读网页、读数据库，最后都要归一成它能处理的结构化文本或消息。

规划（Planning）解决的是“Agent怎么拆解任务”。它可能是简单的思维链（CoT）提示，让模型一步步想；也可能是更复杂的任务分解（Task Decomposition），把一个目标拆成多个子任务。规划能力直接决定Agent的上限，也是目前最值得研究的点。一个常见做法是让模型先输出“计划列表”，每完成一步打个勾，最后再回顾整体是否达成目标。

记忆（Memory）解决的是“Agent怎么不把前面的事忘掉”。短期记忆靠上下文窗口，长期记忆要靠外部存储，比如向量数据库里存历史记录、用户画像、项目文档。做Agent的人都会遇到“跑着跑着忘了最初目标”的问题，这本质上就是记忆设计没做好。

工具使用（Tool Use）解决的是“Agent怎么产生行动”。大模型本身不能操作外部世界，所以通过Function Calling或MCP协议给它挂上工具。这个我后面会专门用代码演示，这是Agent落地最硬核的一环。

反思（Reflection）解决的是“Agent怎么自我纠错”。比如跑完一步后检查结果是否符合预期，不符合就重新来。ReAct范式（Reason + Act）和Reflexion都是这个方向。反思机制是Agent从“能跑”到“稳定跑”的关键。

1.3 哪些人最适合花时间学Agent

第一种是程序员，你天然有优势，因为Agent工程极其依赖代码能力，你学完可以直接把Agent接进项目里做自动化工具、做AI功能模块。

第二种是测试和运维工程师，Agent非常擅长做用例生成、日志分析、异常规则总结。我指导过一位测试朋友，他把接口测试用例生成交给Agent后，原来两天的工作量压缩到半天。

第三种是产品和运营同学，你不需要自己搭框架，但要学会用Coze、Dify这类可视化平台搭业务Agent，理解它的能力边界和交互设计。这比程序员学得更偏“应用层”，但同样很有价值。

第四种是学生或刚入行的AI从业者，学Agent是打入这个行业性价比最高的路径。因为研究型岗位的门槛高，而Agent工程化的人才缺口大，而且上手快、反馈直接，你能很快做出Demo证明自己。

2. 学Agent之前，这三块地基必须打牢

2.1 大模型运行的四个基本概念，越早理解越好

不管用什么框架，Agent底层还是在大模型API之上做文章。所以你需要先彻底搞懂这四个概念：Token、上下文窗口、温度（Temperature）和系统提示词（System Prompt）。

Token是大模型处理文本的最小单位，可以粗略理解成“碎片”，英文一个词大概1个Token，中文一个字大概1到2个Token。如果你在做Agent，必须养成“估算Token量”的习惯，不然还没跑几个回合，账单就会让你肉疼。

上下文窗口是模型一次能“看到”的最大文本量，类似一个人的工作记忆上限。比如4K窗口就是你每次最多输入+输出约4000个Token，超过就被截断。Agent的记忆设计很大程度上就是围绕这个限制做文章。

温度控制输出的随机性。做聊天可以设0.7到1.0，让回复有多样性；但做Agent建议设低一点，0.1到0.3，因为你需要稳定、可复现的逻辑决策，而不是聊花活。

系统提示词是你在对话开始前给模型设定的“角色说明书”，相当于给Agent写岗位JD。这个写得好不好，直接影响Agent的行为质量。后面我给模板时你会看到，系统提示词甚至比用户输入还重要。

2.2 提示词工程不是玄学，是结构化沟通

很多新手学Agent时最忽视的就是提示词工程，总觉得“模型应该能懂我的意思吧”。实战下来，大模型还真的会不懂，特别是在多步任务里，同一句话它不同时候理解还会不一样。所以你需要把需求写得很结构化：定义角色、说明背景、列出可用工具、给出执行步骤、明确输出格式。

我自己常用的一套Agent提示词骨架长这样：

你是一个任务执行助手。你的目标是完成用户提出的任务。 你有以下工具可用：{tool_list}。 请按步骤执行： 1. 分析用户意图，判断需要调用哪些工具。 2. 用工具获取必要信息。 3. 基于工具返回结果，生成最终回复。 输出要求： - 如果调用了工具，先用一句话说明“我将调用某工具完成……” - 最终回复用简洁中文，不超过200字。

注意，这里的关键不是“写得长”，而是“把边界和步骤写清楚”。大模型和人不一样，你给它模糊的指令，它就给你模糊的执行。你还应该在提示词里加上“如果信息不足，不要编造，请直接说明”这类约束，用来压制幻觉。

2.3 Function Calling：Agent的“双手”是怎么长出来的

理解了提示词，Agnet的下一步就是让模型能够调用工具。Function Calling是目前最核心的机制。它的工作方式很简单：你给API传一个“工具列表”的JSON Schema，模型不直接执行工具，它只是根据对话内容，决定“应该调用哪个工具，参数是什么”，然后返回一个结构化的调用请求；你的代码收到这个请求后，去真正执行函数，再把结果回传给模型，让模型基于结果继续生成回复。

我用一个极简例子说明。假设你有个查询天气的函数，模型看到用户问“北京今天冷吗”，它不会自己去查天气，而是返回类似{"name": "get_weather", "arguments": {"city": "北京"}}的结构。你的程序去调用真正的天气API，拿到结果后塞回给模型，模型再看一眼结果说：“北京今天零下2度，挺冷的，出门多穿点。”

这个机制的工程价值在于：Agent的所有能力扩展，都变成了往这个工具列表里加函数。今天接天气API，明天接数据库，后天接发邮件，Agent就从一个会聊天的程序，变成了一个真正能“动手办事”的助手。

3. 从零搭一个能真正干活的Agent

3.1 技术选型：框架和平台的取舍

在动手写代码前，我想先聊选型，因为很多新手在这里被反复劝退。目前市面上主要有四条路线。

第一条是用大厂的Agent平台，比如字节的Coze、开源的Dify。优点是可视化拖拽，内置大量插件和知识库能力，不用写代码也能搭出不错的Agent，适合产品和运营。缺点是封装度高，遇到卡点很难深入排查，灵活性受限。

第二条是用LangChain。优点是生态大，教程多。缺点也同样明显：抽象层级太多，很多函数包了一层又一层，出了问题特别难查，而且它对最新的模型能力跟进往往有滞后。我不建议新手直接上LangChain，它更适合有经验的人用来加速生产代码开发。

第三条是用轻量级方案，直接在代码里调模型API，自己做工具注册和循环调度。这是我最推荐的学习路径。代码量大概几百行，你能真正看清Agent的每一环是怎么跑的。关键是，等你自己写一遍之后，再回去看LangChain代码，很多抽象瞬间就理解了。

第四条是自研框架，适合你已经踩完坑，确定要构建复杂的多Agent系统时再考虑。

我做了一个对比表，方便你决策：

我个人比较推荐的学习路径是：100行代码自研一遍“能调一个工具的Agent”，然后用Dify搭一个业务场景，最后再看要不要引入LangChain或CrewAI。

3.2 最小可用的ReAct Agent代码

ReAct是Reason + Act的缩写，核心逻辑就是让模型循环“思考-行动-观察”直到任务完成。我先给出一份不依赖框架的Python代码，演示一个带“查询价格”和“计算总价”两个工具的Agent。

import json from openai import OpenAI client = OpenAI() # 定义工具 tools = [ { "type": "function", "function": { "name": "get_price", "description": "查询商品的价格，输入商品名称，返回价格", "parameters": { "type": "object", "properties": { "product": {"type": "string", "description": "商品名称"} }, "required": ["product"] } } }, { "type": "function", "function": { "name": "calculate_total", "description": "计算购买多个商品的总价，输入价格列表和数量列表", "parameters": { "type": "object", "properties": { "prices": {"type": "array", "items": {"type": "number"}}, "quantities": {"type": "array", "items": {"type": "number"}} }, "required": ["prices", "quantities"] } } } ] def get_price(product: str) -> float: # 模拟查询价格 price_map = {"apple": 5.0, "banana": 3.0, "computer": 6999.0} return price_map.get(product, 0.0) def calculate_total(prices: list, quantities: list) -> float: total = 0.0 for price, qty in zip(prices, quantities): total += price * qty return round(total, 2) # 执行工具调用 def execute_tool(name, arguments): if name == "get_price": return get_price(arguments["product"]) elif name == "calculate_total": return calculate_total(arguments["prices"], arguments["quantities"]) return "未知工具" # Agent主循环 def run_agent(user_input: str): messages = [ {"role": "system", "content": "你是购物助手，可以用工具查询价格并计算总价，不要编造数据。"}, {"role": "user", "content": user_input} ] # 限制最多循环5次，防止死循环 for step in range(5): response = client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=tools, ) message = response.choices[0].message # 如果模型没有要求调用工具，说明任务完成 if not message.tool_calls: print("最终回答:", message.content) return messages.append(message) # 逐个执行模型要求调用的工具 for tool_call in message.tool_calls: tool_name = tool_call.function.name arguments = json.loads(tool_call.function.arguments) print(f"第{step+1}步: 调用工具 {tool_name}，参数 {arguments}") result = execute_tool(tool_name, arguments) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps({"result": result}, ensure_ascii=False) }) print("达到最大轮次，终止。") # 测试一下 run_agent("我想买2台电脑和3斤苹果，一共多少钱？")

这段代码虽然短，但它完整展示了Agent最核心的循环：模型根据多轮消息上下文，决定调用哪个工具；程序执行工具并返回结果；模型基于结果继续推理或给出最终回复。你把它跑通之后，再去看任何高级Agent框架，会发现底层都是这个模式，只是在外面加了记忆、规划、并发、持久化这些功能。

3.3 记忆管理：让Agent别把前面的事忘掉

小白搭Agent最容易忽略记忆，结果就是跑多轮任务时，Agent像个金鱼一样，前面刚处理完的数据，这一轮又忘了。这里要区分短期记忆和长期记忆。

短期记忆的自然载体就是上下文字段。你把历史消息都塞进messages数组，模型就能“记住”当前任务里的前文。问题是上下文窗口是有限的，塞太多历史，开销大，而且模型注意力会被稀释。

长期记忆就要靠外部存储。最常见的做法是用向量数据库存“用户说过什么”“之前查过什么结果”。我推荐新手先用一个最简单的办法：把多轮对话里需要沉淀的信息，自动做成结构化摘要，存到本地文件或数据库里。等到下次需要时，再把摘要拉进上下文。这个方法虽然糙，但足够让你理解“压缩记忆”的核心逻辑。

举个例子，你的Agent是一个“周报生成器”。用户每次都提供零散的工作记录，你的Agent没必要把原始对话全存下来，它可以每轮结束后生成一条“本周工作要点”摘要，存进一个JSON文件。下次用户再来，Agent先把摘要读出来，作为上下文基础，再结合新输入继续干活。这个模式成本低、效果直观，值得先试。

3.4 工具注册与调用：给Agent装更多“手脚”

在上一节的代码里，工具已经得到了定义。但你有没有想过，为什么一个工具描述写得详细，Agent就能更准确地调用它？因为模型的工具选择和你的description字段质量高度相关。比如get_price的描述是“查询商品价格，输入商品名称，返回价格”，模型一看就知道这个工具是干嘛的。如果你的描述写得模棱两可，模型就会犹豫，甚至选错工具。

实操时我有一个习惯：每个工具的描述里都带上“什么时候该用、输入格式是什么、输出大概什么样”，以及简单的示例。你可以把它理解为给模型写“工具使用手册”。这个积累极其重要，你的Agent能不能在复杂场景下自动选对工具，一半取决于工具定义的质量。

工具多了也要注意命名空间问题。如果工具列表里有send_email和send_whatsapp，模型可能搞混。更好的命名方式是动词+宾语+可选项，比如send_email_via_smtp。另外，工具返回尽量用结构化数据（JSON），不要用一串无格式文本，这样模型更好解析。

3.5 多Agent协作的起步：多AI协作到底怎么协作

热词里频繁出现“多AI协作”，这在Agent领域对应的是Multi-Agent System。简单说，与其让一个Agent干所有事，不如让多个各司其职的Agent组成团队。比如一个“项目经理Agent”负责拆任务，一个“研究员Agent”负责查资料，一个“写作者Agent”负责出稿，一个“评审Agent”负责检查质量。

多Agent协作的常见架构有三种。

第一种是编排式（Orchestrator-Worker），一个主Agent负责任务分配和汇总，其他Agent执行子任务。这是最容易理解和上手的，也是我推荐新手先玩的模式。

第二种是流水线式（Pipeline），Agent如工厂流水线，前一个的输出是后一个的输入。

第三种是聊天式（Conversational），多个Agent互相讨论迭代，类似一个委员会在开会。这种模式效果上限高，但成本和调试复杂度也最高。

我给一个编排式的最小示例：一个Planner把大任务拆成步骤，一个Executor按步骤调用API，最后Reviewer检查结果。你不需要复杂框架，手写三个循环即可，每个Agent只负责自己的角色系统提示词。运行起来你就会发现，单个Agent没头绪的任务，多个Agent反而能找到可靠的执行路径，因为它们把“一个模糊的大问题”变成了“一组清晰的小子任务”。

4. AI编程和AI测试：Agent的最佳练兵场

4.1 AI编程智能体如何在真实项目里工作

为什么说AI搞编程和搞测试是Agent概念最好的学习场所？因为这两类任务目标清晰、反馈迅速，特别适合验证模型的工具调用能力。网上天天说“AI程序员”，它们的原理大差不差：读取代码仓库、理解Issue需求、定位相关文件、修改代码、运行测试、如果测试不通过再回去改。其中“运行测试并自我纠错”这一步，就是前面讲的反思机制在起作用。

我自己用AI编程助手的经验是，把任务拆得越小，AI完成质量越高。你别对一个Agent说“帮我优化这个模块”，而是说“给utils.py里的parse_date函数增加对2024-1-1格式的支持，并且补上3个边界测试用例”。这类原子化任务，AI的成功率极高，两天能干完以前两周的活。

这里有个容易被忽略的点：Agent写代码时，也是要“读代码”的。你的工程结构越清晰、命名越规范，Agent的检索效果就越好。代码注释不是写给人的，也是写给AI的。

4.2 AI测试：从“写用例”到“自主执行”

AI在测试领域的Agent化进程非常快。以前我们只能让AI生成单条测试用例，现在可以让一个Agent自主地执行探索性测试、对比预期输出、发现异常就截图记录。特别适合用在接口测试、回归测试和UI冒烟测试上。

我分享一个接口测试的提示词模板，实测效果很好：

你是一个接口测试Agent。针对以下接口文档，请你： 1. 找出所有必填参数，并构造一组正常请求。 2. 找出边界值，构造至少3组异常请求（缺参、类型错误、超长字符串）。 3. 调用接口并比对返回状态码和关键字段。 4. 如果发现未通过的用例，输出到失败列表中，并附上思考和修复建议。 接口文档：{docs}

注意，这里必须要求AI“调用接口”，而不是“猜测接口结果”，否则它容易凭训练数据的惯性脑补结果，产生假阳性。Agent设计的核心价值之一，就是让AI无法偷懒，强制它面对真实世界的反馈。

4.3 AI Native研发范式：从“用AI写代码”到“重设计工作流”

“AI Native研发范式”这个词这两年特别热，我理解它指的是：不是把AI当作偶尔使用的辅助工具，而是从项目一开始就围绕AI的能力重新设计研发流程。比如需求阶段用Agent做用户故事拆解，设计阶段用Agent生成接口定义，开发阶段用Agent结对写代码，测试阶段让Agent自动生成并执行测试，运维阶段再用Agent监控日志。整套流程就是一组Agent在工作，人的角色从“执行者”变成“审核者和决策者”。

这种范式对我们的要求是：你要懂如何训练和配置Agent，而不是只在某个步骤里用一次AI。换个角度说，AI编程和AI测试只是局部切入，但背后需要的是Agent工程能力。所以你在学Agent时，一定要把视野放到“整条工作流”而不是“单个功能点”，这对你未来做任何AI项目都有帮助。

5. 实战中必踩的坑和排查方法

5.1 Token失控：Agent跑着跑着就“烧钱”

不做预算控制的Agent，分分钟让你账单起飞。原因有三个：一是检索或工具返回了超大文本，塞进上下文后每一轮都在重复计费；二是Agent循环轮次多，每次推理都要重新读上下文；三是有些模型在没找到答案时会钻牛角尖，不断重复调用工具。

我的对策很朴素：第一，所有工具返回值都要“限长”，比如只返回前500个Token，超长就截断或摘要；第二，在Agent主循环里加max_steps硬限制，一般3到5轮就要求收尾；第三，合理利用缓存，比如GPT-4o系列有提示词缓存，重复前缀可以省钱；第四，每步打印Token用量，实时观察哪个环节消耗巨大。

你可以在代码里加一条统计：

print(f"本轮结束: prompt_tokens={response.usage.prompt_tokens}, completion_tokens={response.usage.completion_tokens}")

养成观察Token的习惯，比任何优化技巧都重要。

5.2 上下文爆炸：Agent记不住前面的内容

很多Agent跑着跑着行为就“飘”了，不再遵照最初系统提示词，原因是上下文塞了太多中间结果，原始指令被稀释。解决思路有两个方向。

一是“裁剪旧消息”，只保留最近N轮对话，而把更早的内容压缩成摘要放权限最高区域。二是“关键约束前置”，把不可违背的规则放在系统提示词里而非用户消息里，因为有些模型对越靠前的指令权重越高。

我个人喜欢的做法是，每隔几轮做一次“记忆压缩”：把当前消息列表里最早的若干条内容，交给模型生成一段摘要，作为新的系统消息里的“前置记忆”，然后从列表里移除那些原始消息。这个方法只需要你多调一次API，但对稳定性的提升非常明显。

5.3 工具调用失败：模型“幻觉”参数怎么办

模型调用工具时偶尔会编造参数，比如工具要求city参数，它传了一个省份或根本不在列表里的地名。遇到这种情况，先不要急着骂模型，按顺序排查四件事。

首先看温度，温度太高容易导致参数不稳定，降到0.2以内。其次看工具描述，如果描述里没写“必须传入系统支持的标准城市名”，模型就会自由发挥。再有就是看返回结构，确认tools参数里每个函数的required字段都标了哪些必须参数。最后，给模型加个约束“如果用户提供的信息无法满足必填参数，请向用户提问澄清，而不是猜测”，这一句能挡掉大部分幻觉参数问题。

还有一类问题是工具本身的返回结果格式导致模型解析失败。比如工具返回了NaN、null之类的值，模型在推导下一步时容易“晕”。你最好在工具返回层做一次数据清洗，保证返回内容永远是规范的JSON、有限数字、短文本。

5.4 常见问题速查表

我把实战里高频踩坑整理成一张表，方便你直接对照：

这些坑几乎每个人都会踩，早踩早明白。最有效的办法不是追求一次写对，而是给Agent系统加“日志可观测性”：每轮思考、每次工具调用、每步Token消耗都要能打印出来。你能看到它，也就能修好它。

6. 三个月的学习路线与避坑建议

6.1 三个月学习路线规划

很多人问“我只学了Python，能不能三个月学会Agent开发”。能，但要有清晰路线。我拆成三段。

第一个月：打基础。学Token、上下文窗口、提示词工程，至少自己调50次大模型API，各种参数都试一遍。把最上面那段最小Agent代码自己敲一遍，不要复制粘贴，理解每一行在干什么。

第二个月：做项目。用轻量自研方案，完成两个Agent项目，比如“个人知识库问答助手”和“自动周报生成器”，要求至少接5种工具，包含一次多步骤调用。

第三个月：进阶工程化。学习Function Calling的坑、记忆压缩、缓存、多Agent协作，然后用Dify或自研框架把一个Agent部署成Web服务，让其他人能通过网页交互。

6.2 六个练手项目，越做越有感觉

我整理一份由易到难的项目清单：

• 邮件摘要与自动回复Agent：接入邮件API，自动分类、写摘要、生成回复草稿。
• 日报/周报生成Agent：收集开发记录，按模板生成日报并发送到群机器人。
• 商品比价Agent：从几个商品页抓取数据，汇总成对比表格。
• 数据库查询Agent：把自然语言提问转成SQL查询，并解释查询结果。
• API文档问答Agent：把项目API文档放入知识库，支持问答和错误排查建议。
• 测试用例自动生成并执行Agent：根据接口文档生成用例，直接调用接口校验结果。

每个项目做完，你都要写一遍复盘：哪里卡住、怎么用日志找到问题、模型哪些行为超出预期。这些复盘经验比任何课程都值钱。

6.3 不建议一开始就把时间花在这些地方

最后想拦你一下。有三件事我见过太多人沉迷，但性价比其实不高。

一是追着最新的模型发布跑，每出一个新模型就换框架，代码重写三遍，能力没有积累。二是死磕模型内部原理、从头训练语言模型，这类工作需要硬核算法背景，和绝大多数人的Agent应用开发没有直接关系。三是沉迷于“调提示词技巧”，记住一堆所谓高级模板，但没有理解背后的任务设计逻辑，换个场景就不会用了。

学Agent的正确节奏应该是：快速掌握基础原理，马上进入项目实战，在实战中补知识、踩坑、优化。三个月后你会发现，自己的核心竞争力不是“会调API”，而是“能设计一套AI系统帮人解决问题”，这才是今年甚至未来几年最稀缺的能力。

我自己走了不少弯路，从最开始迷信各种新框架，再到回归轻量自研，最深的体会是：Agent系统的复杂度和代码行数没有必然关系，它的关键变量在于你是否理解“模型如何决策、工具如何扩展、记忆如何维护”这组铁三角。只要你把最小的闭环跑通，剩下的都是在这三角上做增强。