从零构建ai agent大模型智能体怎么做

很多人一上手就问「选哪个框架」，结果模型接上了、工具也挂上了，却说不清这东西到底交付什么、跑一轮要花多少钱、生成的内容能不能对外用。这篇按「先定成品、再定架构、最后定上线」的顺序拆一遍，给的是判断标准和可执行动作，具体数字与型号一律去站内对应页面核对。

很多人一上来就问选哪个框架，结果模型接上了、工具也挂上了，回头却说不清这东西到底交付什么、一轮任务要花多少、生成的内容能不能对外用。顺序反过来就顺了：先定成品，再定架构，最后定上线。

这篇给的是判断标准和可执行动作，不给你写死的数字。凡是涉及价格、型号、跑分、额度的地方，一律到站内对应页面看当时的数字，别拿别人转述的均值当依据。

第一步不是选框架，是定「交付什么」

同样叫智能体，交付形态差一级，后面所有技术选择都不一样。先想清楚它最终交给谁用、在什么场景下用，再决定要不要做多轮、要不要做记忆、要不要做权限。

• 先把输入输出契约写死：用户给什么、智能体必须回什么格式，这决定提示词、工具和评测怎么写
• 再定失败兜底：工具调不通、模型超时、返回格式不合法时，是转人工、重试还是直接报错，这一步不定后面返工最多
• 适用范围：内部自用、容错高的场景可以先跑通再补权限；要对外收费或写进客户流程的，得先做权限与审计，不能边跑边补
• 一个判断标准：如果说不清「哪一类输入算成功、哪一类算失败」，说明成品还没定义完

架构与工具：哪些是必需的，哪些可以先省

最小可用组合是「一个主模型 + 一两个确定性工具 + 一段结构化提示词」。多智能体协作、长期记忆、复杂路由都属于第二期，第一版就上通常是把简单问题做复杂。

工具按「结果是否可校验」排序：查数据库、调计算、读文件这类有明确返回值的先做；开放搜索和开放式生成放后面，因为它们没法用断言判断对错，出了错也很难定位。

确定性工具

有明确输入输出的函数，结果可断言，优先做

开放工具

搜索结果、自由生成，只能人工抽检，放到第二期

会话内记忆

当前请求里带着的上下文，随用随弃，不落库

跨会话记忆

单独存储的持久信息，写入前定谁有权写、写什么、什么时候清

1. 对齐术语把 Token、上下文、温度这几个词的意思统一，去 /ai-dict/category/basics 看，避免团队里对同一个词理解不一样
2. 列候选方案到 /stacks/frameworks 看框架类对照，到 /stacks/agent-apis 看接口类方案，各挑两三个记下差异点
3. 做取舍表按「是否支持结构化输出、是否方便加自定义工具、出错时怎么调试」三列打分，选够用的那个，不追新

提示词与循环控制：让智能体别跑飞

系统提示词只写三件事：角色边界、输出格式、什么情况下必须停下来问人。其余约束尽量交给工具和代码，提示词里堆规则会互相打架，也难维护。

• 给循环设上限：最多几轮工具调用、单轮最长多久、累计消耗到什么程度就中断，避免死循环把额度烧光
• 结构化输出用校验兜底：模型返回不合法就重试一次，仍失败走兜底分支，不把脏数据往下游传
• 把「什么时候必须停下来」写成明确条件，比如涉及删除、付款、对外发送，一律先确认
• 日志要能还原每一次调用：输入、工具名、返回、耗时，出问题时按这条链查

什么情况下不适用：任务本身没有明确结束条件，比如开放式头脑风暴，硬设轮数上限反而会打断有效探索，这类场景改成人工确认节奏，由人来决定继续还是收尾。

计费口径与授权边界：上线前必须问清的两件事

计费按什么算要先对齐口径：按输入输出 Token、按调用次数，还是按订阅包含的额度折算，同一个需求换一种口径总价可能差很多。别只看宣传页的单价，要按自己的实际调用结构算。

通过第三方中转调用时，价格与条款以 /sites 里对应站点当下的说明为准，并且先用 /tools/verify 跑一遍实测，不要只看宣传页。中转站的口径和条款会变，任何写死的数字都不该当成长期依据。

上线前对照清单：能过就算跑通

1. 跑功能核心任务连续跑通多次，输出格式每次都合法，失败路径有明确提示而不是静默出错
2. 量成本单次任务消耗有数、有上限、有告警，不会因为一个循环跑一整夜；具体数字到 /price-watch 核对
3. 收权限智能体能碰的数据范围写清楚，写操作有人确认或日志留痕，敏感操作默认关闭
4. 留后路提示词、工具定义、模型配置分开存，换模型时不用重写全部逻辑；先到 /tools/speed-test 量出接口延迟基线再定超时阈值

这四步里，成本和权限最容易被跳过，也最容易在第一次对外使用后暴露问题。宁可第一版功能少一点，也别在成本和权限上留模糊地带。