企业官网建设流程全解析

最近几个月，我几乎每周都会收到同一种提问：AI Agent到底怎么落地？不少人看完各种白皮书、拆过七要素、跑过示例代码，可一旦要自己做工程实现，还是卡在原地。我仔细观察过这些“卡住”的人，发现他们缺的不是资料，而是一张能把“概念”翻译成“决策”的表格。这篇文章想解决的，就是把Agent从七要素一路拆到七个决策点，说清楚哪些地方必须拍板、每个决策背后有什么代价，以及落到工程代码里应该长什么样。适合正要动手搭建Agent、又不想只是把Demo跑通就完事的读者。

1. 七要素：拆Agent之前先承认它是一台机器

1.1 七要素全景：哪七个零件支撑起一个Agent

Agent之所以让人觉得“玄”，是因为宣传稿总喜欢把它说成一种有自主意识的东西。工程视角下更稳妥的理解是：Agent是一台由七个零件组成的机器，缺了哪一个，行为都会不对劲。我通常按这七个要素拆解：

• 大语言模型（LLM）：Agent的“大脑”，负责理解任务、生成计划、产出动作指令。
• 规划（Planning）：把一个大目标拆成可执行的小步骤，决定先做什么、后做什么、什么时候停。
• 记忆（Memory）：当前任务的上下文叫短期记忆，跨任务沉淀的业务知识和历史结果叫长期记忆。
• 工具（Tools）：模型外部的能力，比如搜索引擎、数据库查询、代码执行器、第三方API。
• 环境（Environment）：Agent感知和操作的真实对象，可以是网页、操作系统，也可以是某个业务系统。
• 行动（Action）：模型最终输出的可执行指令，它需要被翻译成真正的函数调用或界面操作。
• 反馈（Feedback / Reflection）：观察行动结果，判断成功或失败，并把结论带回下一步决策。

这个抽象不是哪一家公司定的标准，而是从各家框架里抽出来的公共结构。无论是Function Calling的调用循环、LangGraph的节点与边、AutoGPT的无限循环，还是各种云厂商白皮书里的架构图，底层都能映射到这套框架。先把七要素认定为一台机器的零件，后面才有真正的工程讨论，否则我们聊的只是“调用大模型接口”。

1.2 用一个“内容发布Agent”把七要素串着讲

概念光靠定义很难有感觉，我用一个具体场景串一遍：假设你要做一个Agent，每周五从素材库里取出原始资料，自动写成一篇带图的短文，定时发布到自己的内容账号上。这里默认一个前提：使用的是平台开放的API、在自己的授权账号范围内操作，发布前有预览和审批。

• LLM负责把素材库里的原始信息改写成通俗文案并起标题；
• 规划要做的是把“读素材→生成文案→生成配图→存草稿→送审→定时发布→记录结果”拆成有序步骤；
• 记忆负责记住历史发布记录，让模型知道“上周已经发过优惠话题，这周不要再重复”；
• 工具包含素材库查询接口、文生图API、内容平台草稿与发布API；
• 环境是执行这些调用的服务器沙箱，以及平台上那个被授权账号的API凭据；
• 行动在代码里表现为一串结构化指令，比如{"type": "draft", "title": "...", "content": "..."}；
• 反馈在发布成功后把文章ID和阅读数据写回记忆，失败时读取错误码并触发重试或降级。

同一个例子，你可以试着把用户点餐、客服工单、数据分析汇报都套进去，会发现结构完全一致。七要素存在的意义不是让你背概念，而是让你在工程上有个检查清单：当Agent乱转的时候，先确认是不是少了一个零件。

2. 七个决策点：要素本身不解决问题，选择才解决问题

2.1 决策总览表：从要素到决策点的一一映射

七要素是静态解剖，告诉我们Agent“由什么组成”。但两个团队用完全相同的七要素写出来的系统，效果可能天差地别，差别全在七个决策点上。我习惯把每个要素对应到一个必须拍板的工程决策：

这张表就是整篇文章的龙骨。后面的内容基本围绕“决策点怎么选、为什么选、选了之后有什么坑”展开。

2.2 决策点一、二：模型选型与token预算管理

模型选型没有万能答案，只有约束条件下的取舍。任务需要大量推理和工具调用时，优先选上下文窗口大、Function Calling稳定的模型；任务简单且实时性要求高时，小模型反而体验更好；数据敏感场景，只能私有化部署开源模型。另一个常被忽视的思路是按任务拆模型：主模型负责规划和成稿，子任务交给更便宜的小模型，例如把长文本摘要单独交给小模型做，成本能降不少。

这时候必须把token这笔账算清楚。很多人问“Agent的token是什么意思”，其实token是模型处理和计费的最小文本单位，英文一个词大约对应1到1.5个token，中文一个字大约对应0.5到1.5个token，具体看词表。Agent场景的token消耗量远高于普通聊天，原因在于模型本身是无状态的，它不会记住上一轮对话。每轮循环，你都得把系统提示、工具描述、历史对话、新观察结果重新全部发送一次。

我常用的估算公式是这样：固定开销等于系统提示加工具描述加已有对话，假设是2000 + 1500 + 3000，也就是6500 token；每执行一个动作，还会产生新的观察结果约500 token。10轮循环下来，总消耗大概是6500乘以10，加上每轮新产生的上下文增长，轻松超过七八万token。所以决策点二真正要回答的不是“选哪个模型”，而是“怎么控制上下文膨胀”。我自己惯用的手段有三个：第一，把旧轮对话压缩成摘要后再放进上下文；第二，长期信息放向量库，按需检索而不是全量塞入；第三，工具描述瘦身，只保留本次任务可能用到的工具schema。三步操作下来，token费用通常能压到原来的三分之一以下。

2.3 决策点三、四：推理策略与记忆分层

推理策略我只会主推三种：ReAct、Plan-and-Execute、树搜索。ReAct是“思考一步、执行一步、观察结果再继续”，适合下一步强依赖工具返回结果的场景，这也是Agent最常用的模式。Plan-and-Execute是先让模型列出完整计划，再按计划逐步执行，适合任务链很长但步骤相对固定的场景，比如周报自动生成。树搜索（Tree of Thoughts）是让模型同时探索多条路径再汇总比较，适合需要多方案择优的任务，但延迟和成本都很高，工程上要慎用。判断依据很简单：任务的每一步是否依赖中间结果？依赖就选ReAct，不依赖就优先考虑Plan-and-Execute。

记忆策略经常被高估。很多Demo里的“记忆”，不过是把历史聊天记录原封不动塞给模型，严格来说这只是话痨的聊天记录，不是记忆。真正的记忆需要分层：短期记忆只保留当前任务的关键上下文，用滚动窗口或KV缓存控制长度；长期记忆存放跨任务生效的业务知识，用向量库或结构化表存储。更关键的一点是，在你完成一个有价值动作之后，要显式地“把结论写回记忆”。没有这个写回动作，长期记忆就是个空库。另外记忆不是越多越好，每一条记忆进入上下文都会挤占token并引入噪声，所以要给记忆打标签、设有效期、按需检索，工程上我习惯把有把握的结论打在“长期记忆”里，把临时过程数据只留在当前会话。

2.4 决策点五、六：工具编排与环境交互

工具不是“在Prompt里写一句你有哪些函数”就完事。每个工具本质是一份元数据：名称、用途描述、参数schema、返回格式示例、所需权限。我踩过的坑是工具描述写得太含糊，模型遇到什么任务都调用同一个工具。后来我的写法是，描述里明确写上“何时用、何时不用、典型输入输出例子”，模型乱选的频率立刻下降。工具之间的失败重试、并行调用、降级链路也要提前定义好。

环境交互方式上，优先原生API，因为稳定、可审计；API覆盖不了时才考虑浏览器自动化或GUI Agent方案，但页面DOM一变就可能崩，需要额外的维护成本。不管选哪种，都要把高风险环境隔离出来：涉及数据库写入的操作先走沙箱，涉及对外发送的操作先进草稿箱。行动审阅的分级我用了很多年，直接说结论：检索和读文件类动作可以全自动；写草稿、发内部通知类动作自动执行但留日志；发布、付款、删数据这类不可逆动作必须人工审批。执行粒度上，宁可把动作拆小，也不要让模型一次生成一大段脚本直接执行，脚本类指令务必在沙箱里先试跑。

2.5 决策点七：行动/审阅与反馈闭环

执行之后必须有反馈，否则Agent容易陷入“原地打转”。我印象很深的一次排错：某个Agent总是重复发同一条消息，查日志发现每一轮它都以为自己是第一次发送，原因是发送成功的返回结果没有写回上下文，下一轮它又从初始状态出发。修复方式很简单，在每次执行后把动作状态加入消息队列，模型就能看到“这个动作已经做过了”。反馈是否成功需要一个可判定的信号，比如HTTP状态码、页面元素是否出现、数据库行是否变化，不要靠模型“猜”。

护栏设计我放在反馈这个决策点一起讲，因为两者是配套的。输出层要加二次过滤，防止模型把数据库里的敏感字段直接吐给用户；调用层要加频率限制和异常熔断，单次任务超过N轮就强制停止；同时准备一份eval回归集，用20到50个历史真实case，每次改Prompt、加工具、换模型都整体跑一遍。没有这套反馈与护栏，Agent在Demo里很聪明，上线之后就变成事故发生器。

3. 主流架构与语言选型：别被白皮书复杂度吓到

3.1 单Agent、编排式、多Agent怎么选

市面上介绍的Agent架构，简化后其实只有三种：单Agent、编排式、多Agent协作。单Agent加工具，一个循环处理所有知识、规划和动作，适合任务边界清晰、决策链短的场景，也是我推荐绝大多数项目起步采用的架构。编排式有一个主Agent负责拆任务和分配，多个Worker各自处理专项技能，适合技能差异很大的任务组合。多Agent协作则是每个Agent都有自己的角色、私有记忆和工具，通过消息通信完成复杂业务流，听上去很优雅，但要处理协议、死锁、上下文隔离、状态同步一堆问题，边际成本很高。

很多云厂商和开源框架画出来的Agent架构图都极其宏大，但真实落地项目里，绝大多数都是从“单Agent加两个工具”开始的。这不是退步，而是控制变量：先把主链路打通，再在压力点长出新结构。我见过一个项目花了三周设计五个Agent的沟通协议，最后发现单Agent加三个工具两天就完成了80%的需求，剩下20%靠人工兜底更划算。

3.2 Rust为什么出现在Agent基建里

热词里经常看到“基于Rust的AI Agent”，这里要泼一点冷水：Rust近年确实越来越多出现在Agent基建层，但用Rust写Agent业务逻辑对多数团队并不划算。它进基建层的理由很实际：Agent runtime是典型的高并发加高IO场景，tokio的并发能力与内存表现比Python更稳；Agent状态机的状态迁移用Rust的类型系统可以在编译期约束，减少状态乱飞的bug；Rust编译成WebAssembly可以当插件沙箱，让Agent安全执行第三方代码。

更合理的工程切分是，Rust负责写网关、运行时、沙箱这类基础设施，业务编排层继续用Python或TypeScript，因为业务层的迭代速度要求远高于执行性能要求。如果你的团队没有性能瓶颈，没有必要为了“Rust”而Rust。技术选型跟着瓶颈走，不跟热度走。

3.3 Django这类Web框架在Agent服务中的角色

热搜词里有“用AI Agent开发Django”，这其实是个很自然的组合。Django适合做Agent服务的HTTP外壳：自带ORM，任务、日志、审批记录、结果数据都落在数据库里；Celery负责消费Agent任务队列，避免同步请求把进程卡死；自带的Admin后台可以快速做成人工审批台。典型的调用链长这样：HTTP请求进入Django API，为了不让请求端等太久，我通常先把任务写入数据库并投递到Celery队列，Worker异步启动Agent循环，每执行一个动作就写一条日志，Agent里的每一步对用户可见，这对调试和排障帮助很大。

一个最小可用的Django工程里，Agent相关代码建议这样组织：

myproject/ apps/ agents/ # Agent定义与编排逻辑 tools/ # 工具集合与参数schema tasks/ # Celery任务：启动、重试、熔断 evals/ # 回归集、评分脚本

白皮书里的架构图往往很长，落到Django项目里，核心其实就是一个循环加一张状态表。把循环里的每一步都做成可观测、可恢复、可审阅，比画出一张漂亮的架构图重要得多。

4. 从搭建到部署：一条可复现的实现路线

4.1 第一步：跑通最小闭环

我搭建Agent的固定顺序，第一原则是“先闭环，再完善”。最小闭环的定义是：一个任务、一个工具、三轮以内能完成。具体做法是选一个窄任务，比如“把这段素材改写成周报要点”；定义一个工具函数，比如从素材库按ID读取内容；然后固定执行顺序：加载系统提示，调用工具拿到素材，让模型生成结果，返回。跑通三个真实case并记录输出，这个闭环就算成立。

这一步不要碰向量库、不要上多Agent、不要接WebSocket，这些都是后补项。没有闭环之前，任何花哨组件都会变成排查问题的干扰项。我见过太多人第一周就在纠结“用哪个向量数据库存记忆”，结果核心的Agent循环还没跑通。

4.2 第二步：按什么顺序补齐要素

闭环跑通之后，后续要素按这个顺序补齐，每一步都做回归验证：

每个阶段加的东西不能太多。加完规划之后，先把前20个case跑一遍，确认没有把已经能用的闭环跑坏，再加反馈。跳步是Agent工程里返工率最高的原因。

4.3 部署测试阶段的高频坑

部署环节有几个高频坑，几乎每个Agent项目都会遇到，我直接列出来：

• 状态必须外置。Agent循环不能依赖进程内变量，否则进程一重启，任务就断了。任务状态、上下文消息、工具结果都要持久化到数据库或Redis。
• 外部API会超时。模型响应和工具调用都有可能超过HTTP网关超时时间，所以Agent任务必须异步化，别在同步请求里跑完整个循环。
• token预算突然爆炸。常见原因是某个工具返回了超长内容，比如把整个网页全文塞给模型。对工具返回值要做截断和摘要，并在代码里设上限。
• 日志不完整排错要命。每条动作至少记录：模型名、输入token数、动作类型、请求耗时、返回结果、错误码。没有这些，出问题时只能靠猜。
• 输出要二次过滤。模型可能把数据库里的原始字段直接吐给用户，输出层必须做脱敏和内容合规检查。
• 防重复执行用幂等键。重试机制必须携带幂等键，否则一次网络抖动可能导致重复下单、重复发布。这个坑在内容发布场景尤其致命。

5. 完整案例：用Agent驱动内容自动发布

5.1 从一句需求到一张要素决策表

案例回到第1章那个内容发布Agent。需求是：内部知识库每周沉淀一篇“本周技术周报”，Agent自动把素材改写成推文草稿并定时发布。这里必须强调合规前提：使用平台开放API、账号已授权、发布前人工预览确认，且在测试账号做完灰度再放量。

我先画一张要素决策表，让每个决策落到具体选项：

• 模型选型：主模型负责成稿和工具调用，小模型负责素材摘要，控制成本。
• 推理策略：采用ReAct，因为每一步是否继续取决于前面素材读出来的内容和草稿生成结果。
• 记忆策略：短期记忆只保留当前素材、当前草稿、审阅意见；长期记忆记录历史标题风格和往期阅读数据。
• 工具边界：只暴露素材库查询、文生图、草稿存取、定时发布、数据统计五个工具。
• 环境交互：素材库与内容平台都走原生API，执行容器放在内部沙箱；发布动作走审批后定时任务。
• 行动与审阅：生成草稿自动执行，发布动作强制管理员审批，统计拉取全自动。
• 反馈闭环：发布成功后的文章ID、阅读数据写回记忆；失败重试最多2次，再失败降级为人工任务并通知管理员。

5.2 核心代码：Agent循环、记忆与审批

下面这段代码是Agent循环的精简版，刻意省略了具体模型厂商的参数，方便你迁移到自己的项目。它的重点在于：每轮都把工具执行结果追加进消息列表，让下一个动作能看到上一个动作的后果；遇到禁止直接执行的动作就停住等待审批。我用Python风格写：

MAX_LOOP = 10 task = load_task(task_id) messages = build_initial_messages(task, memory.recall(task)) for step in range(MAX_LOOP): resp = llm.chat(messages=messages, tools=tool_schema) action = parse_action(resp) # 解析结构化动作 log_action(action, step=step) # 记录模型名、token数、耗时 if action.type == "finish": break if action.type in APPROVAL_REQUIRED: # 发布、删除等动作必须人工审批 save_awaiting_action(task_id, action) notify_admin(task_id, action) break result = dispatch_tool(action) # 真正调用工具 messages.append(observe_message(action, result)) # 关键：把反馈写回上下文 save_state(task_id, messages, step) # 状态外置，宕机可恢复

代码里最容易忽略的是observe_message(action, result)这一行。它把“你刚刚做了什么、结果是什么”显式放进模型可见的消息列表。很多Agent原地打转，就是因为少了这行，模型总以为自己什么都没做。审批逻辑也值得注意：APPROVAL_REQUIRED集合里放的是发布、删除这类不可逆动作，遇到就停下来存库，而不是继续往下走。

5.3 调优记录：一个“反思型Prompt”带来的改变

上线第一周，这个Agent生成的草稿总被用户反馈“太像模板”。我一开始以为是模型能力不够，后来在eval集上做了对照，发现问题出在Prompt结构：系统提示只有一句“写一篇技术推文”，模型没有检查标准。我加了一段反思指令，要求模型成稿后自己检查三个问题：标题是否指向具体对象而不是空洞形容？正文是否把最关键结论放在前三句？行动指引是否明确、能否直接执行？

这个“反思”本质上多了一次自我检查的LLM调用，token成本增加了一轮，但对内容质量的影响很直接。不过我也要提醒：不是所有任务都适合加反思。我把它用在另一个数据清洗Agent上，效果反而变差，因为数据清洗需要的是确定性规则，不是自由发挥。决策点七的正确用法，是在eval集上做A/B验证，而不是照搬别人的Prompt。这个案例做下来，最有价值的收获也不是那篇Prompt，而是那张要素决策表——它让每一次调优都有据可查，知道改的是哪个决策点，影响了哪些环节。

我自己有一个坚持了很久的习惯：接手任何Agent项目，第一件事不是看它用了什么框架、调了什么模型，而是先画一张表，左边写七要素现在各是什么，右边写七个决策点分别怎么选的。画不出来的地方，就是整个架构里最危险的地方。等你动手画完第一版，通常会发现自己根本不需要一上来就上多Agent，也不需要把工具堆到二十个。先把那一条从行动到反馈的闭环跑通，让每次失败都能被看见、被修正，比什么都重要。这才是Agent工程实现里最硬的一条经验。