一个人搞 AI 项目，最容易卡住的不是模型本身，而是“怎么让模型动起来”。模型只会对话，不会帮你查天气、订机票、读写数据库——你需要一个能自己决定“下一步该干什么”的程序，这就是大模型 Agent。

我最早接触 Agent 是在一个内部提效项目里，要求让模型自动完成“拉取订单—清洗数据—生成报表—发送邮件”这条全流程。一开始我想偷懒，直接写死流程让模型填空，结果字段一多、条件一变，代码就崩。后来才明白：Agent 的核心不是“调用模型”，而是“把模型当成决策大脑，外围接上工具和记忆，让它在循环里自己规划、自己纠错”。

这篇内容面向刚入门大模型开发、想把 Agent 真正跑起来的开发者。我会从一个最小可用的 Agent 讲起，拆解工作循环、核心组件、提示词结构，再给出实际代码和排错经验。你不需要有很深的前端或算法基础，只要会写 Python、懂一点 HTTP 调用，就能跟着做出来。

1. Agent 到底是什么：先搞清楚它在解决什么问题

1.1 从“指令执行”到“目标驱动”的思维转变

传统程序是“我告诉你每一步怎么做”，Agent 程序是“我告诉你终点在哪，你自己找路”。这两者的差别，是理解 Agent 的第一步。

举个很朴素的例子。你想让程序帮你查“上海明天会不会下雨，如果下雨就提醒我带伞”。传统写法是：调天气 API → 判断天气字段 → 打印提示。这段逻辑你自己写，十分钟搞定。但如果你再加一句“如果不下雨，顺便推荐一个适合散步的公园”，逻辑就开始分叉了：需要再调一个公园 API，还需要把“天气好”这个条件翻译成参数。再加一句“如果有雨，再帮我看看附近哪家咖啡店可以躲雨”，你就得继续堆条件判断。条件多了，代码就会变成一团乱麻。

Agent 的思路完全不同。你只需要告诉模型：你有天气查询工具、有公园推荐工具，目标是“根据上海明天的天气，给出一个可行的一日安排”。模型自己决定先查天气，再根据结果决定调哪个工具，然后组织语言输出。即使某次结果异常，它也具备基于上下文重新规划的能力。

这种“目标驱动 + 动态规划”的模式，解决的是固定流程无法覆盖的长尾问题。看起来只是思路上的改变，实际落地后维护成本大幅降低——新增一个工具、调整一个逻辑，往往只需要改提示词，不需要改代码。

1.2 Agent 工作循环：观察、决策、行动、反思

Agent 能“自己找路”，离不开一个闭环循环。我把这个循环总结为四步：

1. 观察：接收用户输入，或读取上一次工具返回的结果。
2. 决策：由大模型基于当前上下文，决定下一步该做什么，是调用某个工具，还是直接生成最终答案。
3. 行动：程序执行模型选中的工具调用，把真实数据返回给模型。
4. 反思：模型看到工具结果后，判断是否达成目标，未达成则继续循环，直到满足退出条件。

这个循环和人类解决问题的过程几乎一样。你看一眼冰箱（观察），决定做西红柿炒蛋（决策），拿鸡蛋切西红柿（行动），尝了一口发现咸了（反思），再加点糖（新的行动），直到味道满意（退出）。

下面是一个典型 Agent 循环的时序例子，场景是“帮我查北京今天的天气，并推荐合适的穿搭”：

你看，模型在第2轮不是直接回答，而是“请求调用工具”。程序拿到这个请求，去真实执行 API，再把结果塞回给模型。模型看到真实天气数据后，才开始组织回答。这一来一回，就是 Agent 工作的最小单元。

初次接触的人很容易踩一个坑：以为“模型能直接联网获取天气”。实际上，模型的知识截止到训练时刻，它自己没有任何实时信息获取能力。所有实时信息，都必须通过工具调用拿回来。工具是 Agent 的“手脚”，模型只是“大脑”。这一点想通了，后面学习会顺畅很多。

1.3 为什么选择 LangChain 这类框架，而不是自己写循环

刚才描述的循环，自己用 Python 写也就几十行：拼提示词、调模型接口、解析工具调用、执行工具、把结果拼回去。那为什么还要用 LangChain 这样的框架？

我的答案是：框架帮你解决的是“边缘但致命”的问题。比如对话历史的长度控制，模型上下文窗口有限，多轮工具调用后，之前的对话和工具返回结果会撑爆上下文，需要做裁剪或摘要；再比如工具调用的格式解析，不同模型返回的工具调用格式不同，有的是 JSON 字符串，有的是特殊标记，你要做兼容；还比如多步调用的稳定性，工具返回的结果往往很长，直接塞回模型会严重干扰后续推理，需要做结果压缩。

这些逻辑自己写，第一版能跑，但遇到真实场景里的并发、重试、超时、格式异常，就会不断踩坑。LangChain 把这些沉淀成了抽象组件，虽然学习曲线陡一点，但长期维护省心。如果只是跑通概念，也可以先手写一个极简循环，理解清楚了再换框架。

2. Agent 的核心组件：模型、提示词、工具、记忆

2.1 模型选型：能力边界决定 Agent 的上限

Agent 对模型的要求，比普通对话要高不少。我个人的经验是，至少需要满足三个条件：

• 工具调用能力：模型能按约定格式输出“我要调用某个工具”，而不是把工具名称混在自然语言里。
• 指令跟随能力：模型能理解系统提示词里的约束，比如“只能使用工具获取信息，不能编造数据”。
• 长文本理解能力：模型能处理多轮工具返回的长内容，并保持主线不偏。

目前主流的选择有 OpenAI 的 gpt-4o 系列、Anthropic 的 Claude 系列，以及开源的 Qwen、GLM 系列。个人学习阶段，我强烈建议先跑通模型 API，再考虑本地部署。原因很简单：本地部署需要显卡资源和环境配置，容易把注意力从 Agent 逻辑转移到“模型怎么启动”上，学习效果反而打折扣。

有一个费用极低的学习方案：用国内厂商的免费额度或低价模型，比如智谱、通义、Kimi 等开放平台的新用户额度，足够你做十几个小实验。刚开始不必追求最强模型，先把工具调用流程跑通。

注意：模型对工具调用的支持程度差异很大，建议先查看官方文档确认你所选模型是否支持 function calling。不要用一种模型的经验直接套用到另一个模型上，容易翻车。

2.2 提示词结构：系统提示词里的“游戏规则”

Agent 的行为很大程度由系统提示词决定。我总结了一套比较稳定的提示词结构，有四层：

• 角色定位：告诉模型它是一个“智能助手”，可以调用工具完成任务。
• 工具列表描述：列出所有可用工具的名称、功能、参数格式。模型决策时就是靠这些描述知道“有哪些牌可以打”。
• 调用约束：明确哪些信息必须通过工具获取，哪些可以直接回答，以及遇到错误时怎么处理。
• 输出格式要求：规定最终回复的口吻、结构，是否需要包含引用来源等。

比如一个“订单查询助手”的系统提示词，可以这样写：

你是一个订单查询助手。你可以使用以下工具： - get_order_status(order_id): 根据订单号查询订单状态，返回字符串。 - get_logistics_info(order_id): 根据订单号查询物流轨迹。 你必须遵守以下规则： 1. 用户询问订单状态时，必须调用 get_order_status；只有该工具返回异常时，才可以直接告知用户系统异常。 2. 如果用户同时询问物流信息，先获取订单状态，再获取物流轨迹。 3. 所有回答使用中文，保持简洁。 当用户的问题与订单无关时，直接拒绝回答。

你可能会问：模型真的会严格遵守这些规则吗？不一定。大模型的“规则”更像是一种强倾向，而不是硬编码。所以提示词要写得具体、可验证，而不是笼统的“要准确”。规则越清晰，模型跑偏的概率越低。

2.3 工具定义：如何把现实世界的操作告诉模型

工具是 Agent 与现实世界交互的接口。一个工具可以是一个函数、一个 API 调用，甚至一个数据库查询。关键在于，你要把“这个工具是干什么的、需要什么参数、返回什么结构”描述给模型，模型才能正确发起调用。

以 Python 函数为例，最简单的工具定义就是一个普通的函数加上类型注解和 docstring：

def get_weather(city: str, date: str) -> str: """ 获取指定城市和日期的天气信息，返回格式如下： {'city': '北京', 'date': '2025-06-01', 'condition': '晴', 'temp_max': 34, 'temp_min': 22} """ # 这里实际调用天气API result = fake_weather_api(city, date) return result

在 LangChain 中，可以用@tool装饰器快速包装，框架会自动读取函数名和 docstring，生成工具描述给模型。这里有个容易被忽略的细节：工具描述里的返回格式一定要写清楚。模型看到工具返回的是一串 JSON 后，才能正确提取condition字段、temp_max字段来组织回答。如果返回格式模糊，模型会瞎猜，导致回答牛头不对马嘴。

工具不是越多越好。我给初学者的建议是：一开始只挂两个工具，跑通整个流程，再逐步增加。工具多了，模型选择的困难会上升，出错率反而更高。

2.4 记忆管理：上下文窗口是 Agent 的“工作记忆”，但有限

Agent 与模型之间的每一次交互，都是把“系统提示词 + 历史对话 + 当前用户输入 + 工具返回”全部塞进模型。上下文窗口有限，所以记忆管理是 Agent 工程化绕不开的话题。

有一个很形象的比喻：Agent 的上下文就像人脑的工作记忆，只有保持“当前正在处理的任务”时是最清晰的，一旦任务变多、信息过载，记忆就会“遗忘”或“混淆”。

我常用的记忆管理策略有三种：

• 滑动窗口截断：只保留最近 N 轮对话。简单粗暴，适合工具调用较少的场景。
• 关键信息摘要：每轮结束后，用模型把对话压缩成摘要，保留关键状态。比如“已查过订单状态，结果为已发货，等待查询物流信息”。
• 向量数据库检索：把历史对话或知识库切成碎片存进向量库，每次对话前检索相关片段拼入上下文。适合知识密集型 Agent。

第一种最简单，第三种能力最强但复杂度也最高。对于一个入门项目，先用第一种就够。等遇到上下文溢出、行为漂移的问题时，再考虑升级。

3. 动手实现：最小可用 Agent 的完整实操

3.1 前置准备与环境搭建

实操部分用 Python 3.10 以上版本，配合 LangChain 和一个兼容 OpenAI 协议的模型接口。我以 OpenAI SDK 风格为例，国内模型服务一般也都支持这种接口，只需改 base_url 和 api_key。

安装依赖：

pip install langchain-openai langchain-core python-dotenv

创建.env文件：

MODEL_BASE_URL=https://your-api-endpoint MODEL_API_KEY=your-api-key MODEL_NAME=gpt-4o-mini

然后写一个最基础的环境检查脚本，确认环境变量能被正常加载：

import os from dotenv import load_dotenv load_dotenv() print("base_url:", os.getenv("MODEL_BASE_URL")) print("model_name:", os.getenv("MODEL_NAME"))

这里我想强调一个习惯：永远不要把 api_key 写死在代码里。尤其是在写博客、上传 GitHub 时，key 一旦泄露，费用损失是个坑，更重要的是容易被人拿去滥用。环境变量 +.env文件是入门阶段最稳妥的做法。

3.2 定义两个简单工具：天气查询与推荐穿搭

为了演示工具调用的完整链路，我定义两个工具：一个负责查天气，一个负责根据天气推荐穿搭。注意，第二个工具本身没有真实外部 API，但它能展示 Agent 的多工具协作。

from langchain_core.tools import tool @tool def get_weather(city: str) -> str: """获取指定城市的实时天气信息。 返回 JSON 字符串，包含字段：city, condition, temp_max, temp_min, wind。 """ # 这里应该替换为真实天气 API，此处用 mock 数据便于示例 data = { "city": city, "condition": "晴", "temp_max": 34, "temp_min": 22, "wind": "微风" } return str(data) @tool def get_clothing_advice(condition: str, temp_max: int) -> str: """根据天气状况和最高温度，给出穿搭建议。 参数 condition 是天气状况，temp_max 是最高气温（摄氏度）。 """ if temp_max >= 30: advice = "天气炎热，建议穿短袖、短裤、凉鞋，注意防晒。" elif temp_max >= 20: advice = "天气舒适，可以穿长袖衬衫或薄外套。" else: advice = "天气偏凉，建议穿厚外套或毛衣。" return advice

这里有一个设计要点：get_clothing_advice的入参是condition和temp_max，而不是直接接收get_weather的结果。模型需要从天气工具返回的 JSON 中提取这两个字段，再传给穿搭工具。这个过程能让你看到模型是如何“解析—提取—组装调用”的，对理解 Agent 工作方式很有帮助。

3.3 装配 Agent 并跑通完整对话

LangChain 4.x 版本里，推荐用create_agent来组装 Agent。这个 API 把模型、工具、系统提示词绑定到一起，调用起来很简洁。我先展示核心代码，再逐步解释。

from langchain_openai import ChatOpenAI from langchain.agents import create_agent from langchain_core.prompts import ChatPromptation # 初始化模型 llm = ChatOpenAI( base_url=os.getenv("MODEL_BASE_URL"), api_key=os.getenv("MODEL_API_KEY"), model=os.getenv("MODEL_NAME"), temperature=0.2, ) # 构造系统提示词 prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个天气助手。你可以查询天气，并根据天气提供穿搭建议。" "请先查询天气，再根据天气结果推荐穿搭。回答保持简洁。"), ("human", "{input}") ]) # 创建 Agent agent = create_agent( llm=llm, tools=[get_weather, get_clothing_advice], prompt=prompt, ) # 运行 response = agent.invoke({"input": "北京今天适合穿什么？"}) print(response["output"])

运行之后，你会在终端里看到类似这样的输出：

北京今天天气晴，最高34℃，最低22℃，微风。 天气炎热，建议穿短袖、短裤，出门记得防晒。

这个结果背后发生的事情是：模型先请求调用get_weather，拿到返回数据后，提取出condition=晴、temp_max=34，再请求调用get_clothing_advice，拿到穿搭建议后，组织成最终回答。整个过程是自动的，你不必手动拼接任何中间结果。

提示：如果你使用的 LangChain 版本较老，create_agent可能不存在。建议使用新版，或改用AgentExecutor配合create_react_agent的写法。不同版本的 API 差异比较大，查文档时第一件事就是确认版本。

3.4 加一点调试信息：看清每一步模型在做什么

刚接触 Agent，最难受的是“不知道模型到底在想什么”。模型直接给出最终结果，中间的工具调用过程被封装起来了，出了问题也很难查。这里分享一个小技巧：开启 verbose 调试。

agent = create_agent( llm=llm, tools=[get_weather, get_clothing_advice], prompt=prompt, verbose=True, )

运行后，控制台会打印模型每一步的思考过程、工具调用参数、工具返回结果。你会看到类似这样的日志：

> Entering new Agent run... Thought: 我需要先获取北京的天气信息，再根据天气给出穿搭建议。 Action: get_weather Action Input: {"city": "北京"} Observation: {"city": "北京", "condition": "晴", "temp_max": 34, "temp_min": 22, "wind": "微风"} ...

这个输出是学习 Agent 最好的教材。我强烈建议你第一次跑通时，务必开启 verbose 观察几轮，搞清楚“模型在哪一步决定调用工具”“工具返回什么样的内容影响下一轮决策”。这一步能帮你省掉后面大量的排错时间。

4. 进阶功能：给 Agent 接上真实 API 与更复杂的工作流

4.1 从 Mock 到真实 API：替换天气服务

示例里的天气工具用的是 mock 数据，真实场景下需要替换成真实 API。这里用国内常见的聚合天气接口来示范，接口通常需要 appKey 和城市 ID。

改造get_weather工具，使其支持真实 HTTP 请求：

import requests import os @tool def get_weather(city: str) -> str: """获取指定城市的实时天气信息。 返回 JSON 字符串，包含字段：city, condition, temp_max, temp_min, wind。 """ app_code = os.getenv("WEATHER_APP_CODE") url = f"https://your-weather-api.com/v1/weather?city={city}&appCode={app_code}" resp = requests.get(url, timeout=5) data = resp.json() # 把接口原始返回映射成统一格式 result = { "city": data["result"]["city"], "condition": data["result"]["condition"], "temp_max": data["result"]["tempMax"], "temp_min": data["result"]["tempMin"], "wind": data["result"]["wind"], } return str(result)

真实接口的字段名千奇百怪，有的叫tempMax，有的叫high，有的把城市 ID 当作入参而不是城市名。务必在封装时，统一转成自己定义的输出格式。这样，后续 Agent 的逻辑不需要改，只需要改工具内部实现，就实现了“工具更换、上层无感”。

这也引出一个设计原则：“面向接口编程”。对 Agent 而言，工具描述和返回格式才是契约，具体实现是黑盒。你后续切换天气服务、换短信服务、换数据库，都不动 Agent 核心逻辑，只需要替换工具函数内部。

4.2 让 Agent 支持多轮追问：保持对话状态

上一步的示例中，Agent 只能单纯处理单次输入。实际场景里，用户往往会追问：“那明天呢？”“换成深圳呢？”这就要求 Agent 具备多轮会话能力。

LangChain 中，你可以把历史消息一并传入 Agent。改造后的调用方式：

from langchain_core.messages import HumanMessage, AIMessage chat_history = [ AIMessage(content="北京当前天气晴，最高34℃。"), HumanMessage(content="那深圳呢？"), ]

再把这些历史信息传入agent.invoke：

response = agent.invoke({ "input": "那深圳呢？", "chat_history": chat_history, })

在 LangChain 的create_agent中，历史消息会自动注入交给模型。实现上，模型看到之前的对话内容后，会推断“那深圳呢”指的是“深圳的天气怎么样”，然后自动发起get_weather(city="深圳")调用。

如果你希望 Agent 在长对话中能记住用户偏好，比如“我比较怕冷”，可以把这类信息写回历史中，让模型在后续对话中主动考虑。更高级的方案是引入记忆模块，比如MemorySaver，但入门阶段用“消息历史拼接”已经能解决 80% 的问题。

4.3 多工具协作：模型如何自己决定调用顺序

复杂的 Agent 往往不只挂两个工具。比如搞一个“行程规划助手”，可能要挂：天气查询、航班查询、酒店预订、餐饮推荐、地图导航五个工具。模型在多工具场景下，需要自己决定调用哪个、按什么顺序调。

我做过一个“周末短途游规划”的 Agent，工具包括：查天气、查高铁票、查景点开放时间、生成路线。运行前我担心模型会乱，结果发现只要工具描述足够清晰，模型大概率能走出合理顺序：

• 第一步，查目的地天气，判断适合什么类型活动。
• 第二步，根据活动类型，查景点开放时间。
• 第三步，查高铁票。
• 第四步，组装路线。

这里有一个值得注意的细节：模型自己“规划”和“执行”的结果，与工具描述里的措辞高度相关。如果你的高铁票工具描述是“查询车次信息”，模型可能不知道“车次信息”包括出发时间、座位余量、价格；但如果你描述为“查询某日期某两个城市之间所有高铁车次，返回出发时间、到达时间、二等座余票和票价”，模型就能正确处理。工具描述写得好不好，直接决定 Agent 聪明不聪明。

4.4 用结构化输出收口：为什么最后一步最好走“固定格式”

大多数 Agent 的最终回答是自然语言，这很自然，但也容易出问题。比如用户问“帮我查这个订单到哪了”，模型可能回复一大段解释，虽然包含信息但不好解析。如果你希望后续流程继续处理这段结果，比如存入数据库或展示在卡片上，就需要模型输出结构化数据。

LangChain 提供了一组with_structured_output的用法，可以强制模型输出符合 Pydantic 模型定义的结构：

from pydantic import BaseModel, Field class OrderInfo(BaseModel): order_id: str = Field(description="订单号") status: str = Field(description="订单状态") logistics: str = Field(description="物流信息")

通过结构化输出，Agent 最终返回的对象就是一个OrderInfo实例，字段齐全，可以直接转 JSON、存库、渲染。这样后续环节完全不需要正则表达式去“猜”模型输出里的字段。

不过要注意，结构化输出对模型的指令跟随能力要求更高。如果模型偏弱，可能需要多轮校验或退化为“JSON 字符串 + 不断重试”的方案。初学者先跑通自然语言输出，再上结构化，没必要一上来就追求完美格式。

5. 常见问题与排查技巧实录

5.1 模型不调用工具，直接编答案

这是新手最容易遇到的问题。模型可能面对“查询订单”这类需求直接回答“已发货”，但实际根本没查库。

排查思路分三步：

• 第一步，检查系统提示词：是否明确写了“你必须调用 get_order_status 工具获取订单状态后才能回答”？模糊的提示词（比如“你可以使用工具”）给了模型“偷懒”的空间。
• 第二步，检查工具描述：模型看不到工具函数体，只看到描述。如果你的描述是“订单状态查询”，它可能认为这是可选项。改成“获取订单状态，用户询问订单状态时必选”效果会好很多。
• 第三步，降低温度参数：temperature 过高会放大模型的随机性，建议预测与决策类任务调到 0.2 以下。

5.2 工具返回内容太长，把上下文撑爆了

真实工具返回的可能是几十行日志、一长串数据库记录。全量塞回模型，不仅费 token，还可能让模型“迷失在细节里”，忘记原任务。

我的做法是：在工具返回前做一层“后处理压缩”。只提取对当前任务有意义的关键字段，丢弃无关数据。比如查询订单详情时，接口可能返回一百多个字段，但 Agent 只关心订单状态、物流单号、发货时间，压缩后就变成：

订单号: 20250101 状态: 已发货 物流单号: SF1234567890 发货时间: 2025-06-01 10:30

这样既节省 token，又降低模型解析错误。如果数据模式不固定，可以再加一层“工具结果摘要”：用一个小模型把长文本压缩为摘要，再把摘要发给主 Agent。代价是多一次模型调用，但效果很好。

5.3 工具箱选择“犹豫不决”，来回调用浪费很多轮

有时候模型会“抽风”，明明第一轮拿了天气，第二轮又去查一遍，甚至反复查同样参数。日志里能看到它不断调用同一个工具，就是不出结果。

这类问题多半出在“工具返回结果没有进入足够清晰的上下文”。模型拿到工具结果后，如果结果过于冗长，它可能没“注意到”该结果已经满足条件，继续尝试新的调用。解决办法：一是精简返回，二是检查系统提示词里是否明确写了“拿到结果后直接总结，不需要重复调用”。如果还不行，就检查模型对不对这个工具调用格式有误解，尝试在工具描述里补充“该工具参数固定，当用户没有明确变更参数时，不需要重复调用”。

另外一个经验之谈：给 Agent 设置最大迭代轮次限制。LangChain 的AgentExecutor有max_iterations参数，建议设成 5~8，防止异常情况下无限循环烧 token。

5.4 Agent 并发调用时频繁超时或限流

Agent 上线后，一个绕不开的问题是并发。模型 API 普遍有 QPS 限制和并发数限制，一旦发起大量工具调用，很容易被限流。我踩过最痛的一次坑：活动大促时，Agent 服务同时被几十个用户调用，每个 Agent 循环里还有多次模型请求，瞬间触发限流，用户全部看到“服务繁忙”。

排查和优化的路径有这些：

• 加缓存：对于相同参数的工具调用，比如“北京的天气”，加一层 Redis 缓存，TTL 设成 10 分钟，能砍掉大量重复请求。
• 控制并发：不要无脑用线程池，根据模型 API 的 QPS 上限做信号量控制，超出的请求排队或快速失败。
• 降级方案：当模型服务不可用时，返回预置的提示语句，而不是让用户等待超时。

这些属于 Agent 工程化的内容，入门阶段可以先有这个概念，等真正上线再深入。

5.5 速查表：常见问题与解决方案

个人经验补充：新手进阶的实践路线

根据我自己的学习过程，给刚入门的朋友一个建议：从场景出发，而不是从框架出发。先选定一个你真正想自动化的小事，比如“查物流并播报”“整理每日热点新闻并生成摘要”“自动分类微信收藏的文章”等。然后不用框架，手写一版最朴素的 Agent，哪怕只是“输入→模型→工具→输出”的重复循环。等跑通了，再换成 LangChain 等框架重构。

这个过程能让你真正理解 Agent 设计中的取舍。比如：工具结果要不要压缩？历史消息怎么管理？模型调错的工具怎么办？这些问题只有亲手做过一遍，才会有直觉，而不是机械地套模板。

最后分享一个我在实操中很受益的小技巧：给每个 Agent 项目写一个“调试日志”文件。每次跑完，把 verbose 输出的关键步骤复制下来，标注“这次为什么成功/失败”，攒几个案例后，你对 Agent 行为模式的把握会远超看十篇教程。

Agent 开发确实有一道不低的学习门槛，但一旦跨过去，你会发现它能覆盖的场景远超想象。这个领域的魅力就在于：同一个架构，换一组工具、换一段提示词，就变成了另一个产品。希望大家都能在工作中找到属于自己的第一个 Agent 落地场景，跑起来，就有答案。