aiagent怎么写？从提示词到工具调用的搭建步骤

想知道“aiagent怎么写”，不要一开始就纠结框架或模型。一个能用的 AI Agent，核心不是“会聊天”，而是能围绕目标理解任务、拆分步骤、调用工具、读取结果、继续决策，并在失败时给出可控处理。最小可行版本可以按这条线搭建：定义任务边界 → 写系统提示词 → 设计工具接口 → 让模型决定何时调用工具 → 执行工具并回填结果 → 加入状态、权限和错误处理。

先判断：你要写的是哪一种 AI Agent

很多人搜索“aiagent怎么写”，真实需求并不一样。有的人想做一个客服机器人，有的人想让 AI 自动查资料、写报告，有的人想接入内部系统完成下单、查询、生成代码。不同场景决定了 Agent 的复杂度。

常见类型可以这样分

• 问答型 Agent：主要负责回答问题，可接知识库检索，适合客服、文档助手、学习助手。
• 工具型 Agent：能调用搜索、数据库、API、计算器、文件读写等工具，适合查数据、生成报表、处理工单。
• 流程型 Agent：按固定业务流程执行，例如线索录入、订单查询、售后分流，强调权限和稳定性。
• 编程型 Agent：能读代码、改代码、运行测试，适合研发辅助，但对沙箱、安全和回滚要求更高。

如果只是做演示，提示词加几个工具就够了；如果要放到业务系统里，重点应放在边界控制、日志追踪、失败兜底、人工确认，而不是让模型无限自主发挥。

第一步：把 Agent 的任务边界写清楚

写 AI Agent 前，先用一段普通话描述它能做什么、不能做什么、遇到不确定信息怎么处理。边界越清楚，后面提示词和工具设计越容易。

建议先回答 5 个问题

• 目标是什么：例如“根据用户问题查询知识库并生成回复”，不要写成“帮用户解决所有问题”。
• 输入是什么：用户自然语言、表单字段、文件、数据库记录，还是多轮对话。
• 输出是什么：一段回答、一个 JSON、一次 API 请求、一个工单处理结果。
• 可用工具有哪些：搜索、数据库、企业接口、邮件、日历、代码执行器等。
• 哪些动作必须确认：付款、删除、发送消息、修改数据库、提交订单等通常不应自动执行。

一个实用判断标准是：如果这个动作执行错了会造成损失，就要加确认；如果只是查询或草稿生成，可以让 Agent 自动完成。

第二步：写系统提示词，不要只写“你是一个智能助手”

提示词是 Agent 的行为说明书。很多失败的 Agent，不是模型不够强，而是提示词没有规定角色、目标、步骤、工具使用条件和输出格式。

一个可复用的提示词结构

• 角色：说明 Agent 的身份，例如“你是企业知识库问答助手”。
• 目标：说明最终要达成的结果，例如“根据资料回答问题，不确定时说明缺少依据”。
• 工作流程：先判断问题类型，再决定是否检索，再生成答案。
• 工具规则：什么时候调用工具，什么时候不要调用，调用后如何使用返回结果。
• 限制条件：不能编造政策、不能越权操作、不能泄露内部字段。
• 输出格式：要求用自然语言、JSON、表格字段或固定模板输出。

例如，一个查询型 Agent 的系统提示词可以写成：

你是一个售后知识库助手。用户提问后，先判断是否需要查询知识库。涉及具体规则、价格、流程、故障代码时必须调用 knowledge_search 工具。回答时只基于工具返回内容，不确定时说明“资料中未找到明确说明”，并建议用户联系人工客服。不要编造不存在的政策。

这类提示词比“请认真回答用户问题”更可靠，因为它明确了什么时候查资料、如何处理不确定信息，以及不能做什么。

第三步：设计工具调用，让 Agent 真正能做事

AI Agent 和普通聊天机器人的关键区别，是能调用工具。工具不一定复杂，可以是一个搜索函数、数据库查询接口、HTTP API、文件解析器，也可以是一个内部业务服务。

工具设计要包含 4 个要素

• 工具名称：简短清晰，例如 search_docs、get_order_status、create_ticket。
• 功能描述：告诉模型这个工具适合解决什么问题。
• 参数结构：字段要少而明确，例如 keyword、order_id、user_id。
• 返回格式：尽量结构化，方便模型继续判断，而不是返回一大段杂乱文本。

以订单查询 Agent 为例，工具可以这样规划：

• get_order_status：根据订单号查询订单状态，参数为 order_id。
• search_policy：查询售后政策，参数为 keyword。
• create_service_ticket：创建售后工单，参数为 order_id、problem_type、description。

注意，工具不是越多越好。工具过多会增加误调用概率。建议先从 2-3 个高频工具开始，跑通流程后再扩展。

第四步：搭建最小可行流程，从单轮调用开始

如果你在用大模型 API 或 Agent 框架，最小流程通常是：用户输入给模型，模型判断是否需要工具；如果需要，返回工具名和参数；程序执行工具；再把工具结果发回模型；模型生成最终答复。

推荐搭建步骤

1. 准备模型接口：选择支持工具调用或函数调用的大模型接口。若模型不支持原生工具调用，也可以让模型输出固定 JSON，再由程序解析。
2. 定义工具清单：为每个工具写名称、描述、参数和返回示例。
3. 写系统提示词：把角色、任务边界、工具规则、输出格式放进去。
4. 接收用户输入：保留必要上下文，但不要把无关历史全部塞进模型。
5. 解析模型意图：如果模型请求调用工具，检查工具名和参数是否合法。
6. 执行工具：调用数据库、搜索服务或业务 API，并记录日志。
7. 回填工具结果：把结果作为工具消息发回模型，让它继续推理或生成回复。
8. 输出最终结果：如果涉及敏感操作，先给用户确认，不要直接执行。

替代方案也可以更简单：如果只是知识库问答，可以先做 RAG 检索增强，不必一开始做复杂 Agent；如果只是固定流程客服，可以用“规则流程 + 大模型改写话术”，稳定性通常更好；如果是研发测试项目，再考虑多工具、多轮规划和自动执行。

第五步：状态、记忆和权限，比“聪明”更重要

真正上线后，Agent 最大的问题往往不是答不出来，而是乱记、乱调工具、越权操作或无法追踪。因此需要给它加状态管理和权限控制。

状态管理怎么做

• 短期上下文：保存当前对话必要信息，例如用户刚提供的订单号、问题类型。
• 长期记忆：只保存经过用户同意或业务允许的信息，例如偏好设置，不要随意存敏感数据。
• 任务状态：记录 Agent 处于“待补充信息、已查询、待确认、已完成、失败”等阶段。

权限控制怎么做

• 查询类工具：可适度自动调用，但要校验用户身份和参数。
• 写入类工具：如创建工单、修改资料，建议加入确认步骤。
• 高风险工具：如支付、删除、发送外部邮件、执行代码，应使用白名单、沙箱和人工审核。

如果是编程类 Agent，还要特别注意代码执行环境。不要让模型直接操作生产数据库或服务器。更稳妥的做法是使用隔离沙箱、只读权限、测试分支和可回滚机制。

常见坑和排查方法

很多人在问 aiagent怎么写时，会卡在“能跑但不好用”。这时不要急着换模型，可以按下面几个方向排查。

• 模型总是乱调用工具：检查工具描述是否过于模糊，提示词里是否说明“不确定时先询问用户”。
• 参数经常填错：减少参数数量，增加格式示例，并在程序侧做校验。
• 回答像编的：要求模型基于工具结果回答，并在没有依据时明确说明无法确认。
• 多轮对话混乱：把任务状态结构化保存，不要完全依赖模型记忆。
• 调用成本太高：先用规则判断简单问题，复杂问题再交给模型；长文档先检索再喂给模型。
• 上线风险大：先做只读查询，再开放写入操作；先内部试用，再小范围灰度。

还有一个常见误区：把 Agent 设计成“什么都能做”。这会让提示词膨胀、工具混乱、结果不可控。更好的方式是先做一个垂直 Agent，例如“订单售后 Agent”“合同检索 Agent”“代码评审 Agent”，让它在清晰边界内稳定工作。

适合的工具类型与选型建议

不同开发能力和业务目标，对工具选择也不一样。没有必要一开始就堆最复杂的 Agent 框架。

• 低代码平台：适合快速验证客服、知识库问答、表单自动化，优点是快，缺点是定制能力有限。
• 大模型 API：适合有开发能力的团队，自由度高，可接内部系统，但需要自己处理日志、权限和异常。
• Agent 框架：适合多工具、多步骤任务，例如自动研究、代码处理、复杂工作流，但学习和调试成本更高。
• RAG 检索系统：适合文档问答、制度查询、客服知识库。如果需求主要是“查资料并回答”，它往往比复杂 Agent 更稳。
• 工作流引擎：适合审批、工单、营销自动化等固定流程，可让大模型负责理解和生成内容，流程由系统控制。

决策时可以用一个简单标准：如果任务步骤固定，用工作流；如果主要查资料，用 RAG；如果需要根据结果动态选择工具，再写 Agent；如果涉及核心业务写入，必须加权限、确认和审计。

写 AI Agent 的关键不是让模型“自由发挥”，而是把目标、工具、规则和边界写清楚。建议先做一个最小版本：一个明确场景、一个系统提示词、两个工具、一个确认机制、完整日志。跑通后再逐步加入记忆、多轮规划和更多工具。这样搭出来的 Agent 更容易调试，也更适合真正落地。