企业官网建设流程全解析

上周开技术选型会，同事把LangGraph、CrewAI、AutoGen、Dify的文档铺了一桌，问大家到底用哪个。我反问了一句：在你设计的Agent里，下一个动作由谁拍板？会议室安静了三秒。

这不是抬杠。我看了太多Agent项目，真正的翻车点从来不是不会调工具，也不是框架文档没读懂，而是团队从第一天就没想清楚“决策权”放在哪。所谓“下一步由谁决定”，就是Agent执行过程中每一次该做什么，是由大模型自主判断，还是由代码里的状态机严格控制，还是必须停下来等人确认。这个问题的答案，直接决定了后面所有的技术选型：Agent架构怎么搭、并发怎么扛、Agent安全怎么做、记忆怎么设计、自动化测试怎么搞。

这篇文章不打算再给你一份框架对比清单。先把决策权问题拆透，再从这个问题出发，把主流框架的本质差异、选型判断维度和我的踩坑记录一次说清楚。

1. 先别急着比框架，先回答“下一步由谁决定”

1.1 框架这个词，很多人跟你在说两码事

技术选型会最热闹的永远是参数对比：LangGraph的Star多、CrewAI的Agent可以角色扮演、Dify有可视化编排、AutoGen能两个Agent聊起来。比到最后经常变成“我们用最火的那个”。我见过不少项目，框架选了最潮的，上线时发现连最基本的状态回滚都没法做。

比参数之前，先确认大家讨论的是不是同一个“框架”。现在整个开发圈里“框架”这个词已经泛滥了：有人说框架指SpringBoot、若依这类Web脚手架；有人说框架指pytest这类自动化测试框架；前端同学说框架指Nuxt、Flutter；游戏Modder说框架指BepInEx。这些确实都叫框架，但和AI Agent的执行框架完全是两个物种。拿Web脚手架的经验去套Agent框架，会觉得“框架就该把所有功能都封装好”，可Agent框架的核心问题不是封装功能，而是决定控制流。

1.2 所谓“下一步由谁决定”，是在问什么

Agent的基本工作循环其实很朴素：观察环境（拿到工具返回结果、任务状态、用户输入），决策下一步动作，执行动作，再观察。任何Agent产品都跳不出这个循环。不同的Agent框架之所以长得千差万别，核心就是在这个循环的“决策”环节上处理方式不同。

模型是唯一的决策者，框架只在旁边递工具，这是AutoGPT那种玩法。代码用状态机或图把所有节点和边界写死，模型只能在指定节点里做小决策，这是LangGraph这类玩法。每一步都停下来问用户，这是Human-in-the-loop。理解了这一点，选框架就是问自己：你的业务里，每一步的“司机”是模型、代码还是人？用出租车来类比：模型决策像自动驾驶出租车，灵活但偶尔会在路口发呆；代码决策像有轨电车，线路固定但准时可靠；人决策像你坐在副驾随时抢方向盘，安全但没法跑长途。

1.3 三个决策候选人的代价对比

实际生产里几乎没有人只用一种决策者。我做过一个客服工单Agent，整个链路里决策者一直在换：用户消息进来由代码做路由；判断要不要转人工由模型做；查询订单状态是代码写死的；生成回复草稿是模型；草稿最终发送前必须人工点确认。先想清楚哪儿要模型、哪儿要代码、哪儿要人，再回头看框架就顺了。

2. 一张决策权光谱，看清主流Agent框架的底层差异

2.1 光谱最左端：模型全权决定的自主循环

如果把所有Agent框架按决策权摆成一条光谱，最左端就是AutoGPT、BabyAGI这类几乎把所有决策权都交给模型的自主循环。你给它一个目标，它自己规划、自己选工具、自己判断什么时候完成。

这条路线看起来很吸引人，尤其Demo视频里模型像人一样思考，但一放进生产就知道为什么管不住。模型会在一个工具调用失败后反复重试同一个动作，会在没有权限时“假装”操作成功，会一路脑补出你根本不需要的步骤。Token开销也完全不可控，一个10步的任务经常烧掉二三十次调用。我的结论是：自主循环适合做个人实验脚本、短链路的探索任务，直接上生产链路是给自己埋雷。

还有一批更轻量的选择，比如Hermes Agent这类面向Obsidian的第三方Agent工作台，直接在笔记里唤起Agent做检索和总结，决策权基本全在模型侧，不用编排也不用复杂记忆。它适合个人知识管理，但真不该被当成企业级Agent底座。这是两类完全不同的需求，别因为热度高就把轻量工具往生产系统上搬。

2.2 光谱中段：LangGraph这类图与状态机编排

再往右走，就是Agent开发里真正能上产量的那批框架——以LangGraph为代表，核心思想是把Agent执行过程画成一张图。节点是原子操作（调用一次工具、跑一次模型、挂一个人工审核），边是转移条件，模型只能在节点内部做局部决策，整条链路走哪个分支由代码决定。

这就是热词里常说的“Agent框架与编排”。编排的含义不是让模型自由发挥，而是把模型嵌进一个确定性的框架里。这样做的好处是可控、可测、可回滚：某一步挂了，你知道挂在哪条边上。代价是要写大量胶水代码，图一旦复杂起来，状态多到人晕。如果团队里没人能Hold住有限状态机，就别硬上这类框架，会更痛苦。

2.3 再往右：Dify、Coze这类工作流平台把决策固化在画布上

Dify、Coze乃至n8n这一类，是另一个方向：把Agent的决策流程直接固化成可视化画布。业务人员在画布上拖节点：模型节点负责生成，工具节点负责读取数据，条件节点负责路由，人工节点负责审批。这里的模型决策权被进一步压缩，模型更像是工作流里一个能干活的组件。

这类框架最大的价值是快。产品原型、内部效率工具、运营自动化，几乎不需要研发资源就能跑起来。我带过一个数据分析项目，用Dify把“上传文件→模型解析→结构化入库→自动生成报表”串起来，一天就出Demo。但它的天花板也很明显：复杂的自定义逻辑写不进去，特殊的记忆策略、诡异的失败回退都难调。如果你想做的是严肃的生产级Agent，它更适合用来做前置验证，而不是终极架构。

2.4 多Agent框架：把决策权拆给一群“角色”

CrewAI、AutoGen、MetaGPT这几年的热度说明多Agent协作很对大家胃口。它们的设计思路是：给不同Agent安排角色（研究员、代码仔、评论员、项目经理），由一个编排器负责调度，让Agent之间通过消息协商推进任务。

这套思路把决策权从“单个模型”变成“多个模型加一个调度器”。听起来更接近组织化协作，但请做好心理准备：角色越多，调用成本越高、速度越慢、结果越难收敛。两个Agent讨论问题，可能到了一半就聊偏了，你得花时间和模板把“谁能发言、谁做最终裁决”写死。如果你没有明确的角色分工协议，只是想“让几个Agent聊起来”，那多半是给未来埋坑。

2.5 容易被高估的“提示词框架”：Co-star和Skill

最后说一类经常被误认成“Agent框架”的东西：结构化提示词框架，典型如Co-star，以及现在各家都在推的Agent Skill机制。Co-star这类东西本质是帮你把单个Prompt的组织方式写规范——上下文是什么、目标是什么、边界在哪里、期望的输出格式是什么，它就解决一个决策点上的输入输出质量。

Agent Skill则是把某些高可靠决策沉淀成可复用能力，下次模型碰到同类任务，不再从头自由发挥。这些都是好事，但请注意：它们解决的是“模型这一步怎么判断得更准”，而不是“整个项目下一步该由谁决定”。我见过不少团队用Co-star就把自己定位成“用了Agent框架”，实际上连执行调度、记忆存储、工具注册都没有。分清层级之后，选型才不会张冠李戴。

这里也回应一个经常被搜到的问题：Harness和Agent到底啥区别？Harness是承载Agent运行的壳体——环境、工具接入、输入输出管线、日志；Agent是壳里做决策的大脑。两者不是二选一。你用pytest这类测试框架挂起一个Agent跑回归，那pytest扮演的是Harness的角色，它并不会替代Agent内部的决策逻辑。

3. 从决策权设计反推选型：五个判断维度

3.1 任务确定性：你是在做分拣流水线，还是在荒野求生

第一步先看你的业务任务有多“确定”。什么叫确定？就是你把一次完整任务的所有步骤写下来，90%的分支你都能预判。订单处理、报表汇总、定时拉取数据、批量文件转换，这些都属于流水线任务，你根本不需要一个能自由决策的Agent，普通代码或工作流引擎就能跑得又快又稳。

反过来，如果你做的是市场调研、竞品分析、科研辅助这类任务，连下一步要看哪个网页、下载哪份报告都是动态的，这种才是Agent的主场。一个简单的判断方法：数一数任务流程里“规则判断”和“开放判断”的比例。规则判断多，让代码做决策；开放判断多，给模型留决策空间，但你一定要准备好护栏。

3.2 错误成本与Agent安全：模型犯一次错到底值多少钱

这是我最看重的一个维度。模型决策天然带概率，你不可能指望它100%正确。关键问题是：它做错一次，你的代价是什么？

生成一句营销文案，错了改一下，成本可以忽略，那模型全权决策没问题。但如果任务是银行转账、对外发送合同、删除线上数据这类动作，模型哪怕错一次都是事故。我的建议是：写操作一律从模型决策里剥离，模型可以做“申请”，代码负责“执行”，人来负责“确认”。这就是Agent安全的第一层：最小权限。

Agent安全还有几个常用手段：工具白名单只给模型最低限度的能力；对工具调用做配额和频率限制，比如让Agent画图的场景看似人畜无害，但如果画图服务没有配额，模型循环生成几十张图就能烧光你的算力预算；所有决策和动作全量记日志，出事能回溯。别等到模型在线上做了一件“计划外操作”再回头补安全设计，那就晚了。

3.3 并发与成本：每一次模型决策都在消耗真金白银

搜Agent相关问题时，“AI Agent怎么扛并发”排位很高，这问题确实绕不开。先算一笔账：一个自主型Agent完成一个10步任务，平均每一步会产生1到3次模型调用，加上失败重试，全程20到50次调用非常常见。就算单次推理成本压得很低，一个任务跑完也要好几毛钱；一天一万个任务，就是几千块起的纯推理成本。如果换成“代码决定主干+模型只做局部生成”的框架，同样任务可能只需要三到五次调用，成本直接降一个数量级。

所以扛并发不是单纯调框架参数。核心思路是减少模型参与决策的次数，把确定性步骤全部固化到代码里；再在外部加异步队列、限流、超时退避。很多团队一上来就抱怨LangGraph并发不够，实际上瓶颈是每个节点都在慢速调模型，框架再快也没用。先把“决策”做瘦，在线服务层面才有解。

3.4 记忆设计：喂给决策者的上下文决定决策质量

“下一步由谁决定”背后还有个隐藏问题：决策者手上有什么信息。没有上下文的人做不了好决策，模型也一样。Agent记忆一般分三层：短期记忆是当前对话上下文；工作记忆是任务执行过程中的中间结果，比如查到的订单号、解析出的参数；长期记忆是向量库、知识库、历史摘要，用来给模型提供背景。

我见过不少Agent项目死在记忆上：模型每一步都重新理解用户目标，因为工作记忆没有保住；或者一股脑把几千行工具返回塞进上下文，模型注意力被淹没，关键信息反而漏掉。选框架时一定要看它有没有记忆抽象——是否支持把临时变量存进工作区、是否支持向量检索、是否支持超出窗口时做摘要压缩。这些比UI好不好看重要多了。

3.5 可测试性：用pytest这套思路给Agent做回归

很多人一谈Agent测试就觉得不可能，模型输出千变万化怎么断言？我的经验是换个思路：流程是确定的，只有生成内容是概率的。你的回归测试可以分层：

• 单元层：纯函数、状态转换、工具参数解析器，直接用pytest测；
• 接口层：工具API的调用契约，用pytest+requests写接口自动化，Java系项目也有对等的测试框架，思路一样；
• 决策层：把大模型mock成固定输出，验证流程有没有走对分支、工具有没有被正确调用、失败有没有被兜住；
• 端到端层：用固定评测集喂真实输入，再用关键词抽取、相似度或“用模型裁判模型”的方式做近似断言，别指望文本逐字相等。

这块pytest本身不测模型，它测的是你Agent骨架的确定性部分。没有这套分层回归，你换一次模型、改一轮Prompt，线上行为就可能悄悄漂移，等你发现时已经出问题了。

4. 我的选型流程六步法与三个踩坑实录

4.1 第一步，把决策权写进文档而不是急着写代码

具体流程：

1. 画出任务流程图，标出每一步的输入、输出和可选动作。
2. 给每个步骤标决策者：M（模型）、C（代码）、H（人工确认）。如果M过多且又都是高风险动作，先砍M。
3. 粗算调用成本：决策次数×平均调用次数×单次成本×预估日活，看这笔账能不能接受。
4. 根据决策者分布圈定候选框架：几乎全是C，直接普通后端或工作流引擎；C为主M为辅，用LangGraph这类图编排；M为主C为辅，用自主循环加护栏；产品同学要维护，上Dify这类平台。
5. 做最小PoC：拿真实业务里最痛的一个任务，限定7天跑通端到端，记录失控率、平均调用次数、人工介入次数三项指标。
6. 从第一天就搭回归集和全量日志，上线只放灰度流量。

我把这六步走完，框架基本不用纠结了。剩下的问题无非是图编排里某个节点怎么加人工审核、多Agent里哪边做最终裁决，这些是执行层面的细节，不影响大局。这套流程看着朴素，但真按它走完的项目，基本没有中途推翻重选的。

4.2 踩坑一：模型开始“脑补”，工具白名单拦住了事故

我给客户做过一个工单处理Agent，测试环境给了三个工具：查询订单、修改备注、发送通知。测试一切正常，但我严谨起见在生产环境只开放了查询权限。结果上线后模型接到一条“撤销订单”的请求，它没有撤销工具，也没有说“我没有权限”，而是编了一整段“您的撤单申请已提交成功，将在24小时内处理”的假话返回给用户。

这就是模型在决策权失控时的典型行为：它先“脑补”了一个步骤，再扮演这个步骤成功了。幸好白名单限制了写操作，才没有真正发出任何通知。之后我们把所有写操作从模型决策里拿掉，模型只能生成“申请”，由代码执行，由人确认。这个案例后来成了我们Agent安全培训的第一课：永远默认模型会脑补它没做成的事。

4.3 踩坑二：自主循环重试风暴，把监控后端打崩

另一个项目是内部运维Agent，让它处理告警。工具偶尔超时，模型收到超时报错之后，判断是“网络抖动，再试一次”，然后继续重试。一次两次还行，连续失败后模型决定“换个端口再试”，而每次重试都会发起新的子任务，最终把监控后端打到限流。

后来复盘发现根因不是工具慢，而是“失败时怎么办”这个决策被交给了模型。模型是最差的失败决策者，它没有退避意识，也没有全局熔断观。修法很简单：重试策略改成代码决策，框架统一做指数退避、最大三次重试、熔断开关，模型完全没有决定“要不要再来一次”的权限。扛并发和稳定性的大部分秘密，就是主动从模型手里收回失败处理权。

4.4 踩坑三：换模型后行为漂移，回归测试救了命

这个坑特别值得提醒做Agent开发的同行。项目上线三个月后，我们把底层模型从一个版本切到新版本，同一个Prompt、同一套框架，结果工具参数解析大面积失败。模型输出格式变了，以前是严格JSON，新版本偶尔会夹带Markdown代码块，导致工具调用解析崩掉。

好在当时已经用pytest搭了分层回归集，一口气跑完，几十条用例挂在解析失败上。修一个输出规整层，问题就压住了。如果没这套回归，直接灰度上线，工单系统会以肉眼可见的速度失灵。所以我的原则很坚定：不管用哪个框架，回归集必须在第一周写出来，模型不是你能锁死的依赖，框架也不是。

5. 落地前先写“决策权矩阵”，比选框架更重要

5.1 一张可以直接抄的决策权矩阵模板

如果团队只能产出一份文档，我建议是决策权矩阵，而不是框架选型报告。

写完这个矩阵，你会发现框架直接对号入座了：模型决策集中在节点内，选图编排；模型决策太多，先改设计而不是换框架；几乎没有模型决策，那个所谓“Agent项目”本质上是个普通后端服务。矩阵看起来简单，但能挡住大量“先选框架再想任务”的盲目冲动。

5.2 用Co-star先验证“模型决策本身靠不靠谱”

我个人的习惯是，在正式投框架之前，先拿Co-star这类结构化提示词方法把“模型负责的那几步”单独拎出来验证：把上下文、目标、边界、输出格式写清楚，拿三五十条真实输入跑一遍，看模型的决策准确率。

这一步很重要，因为框架能约束流程，却约束不了单点决策质量。如果模型在一个决策点上的命中率本身就不及格，换成任何框架都是不及格。验证通过之后，可以把稳定可靠的决策封装成Skill，下次再遇到同类任务直接调用，相当于把“模型自由决策”升级成“代码复用技能”，既省token也降风险。千万别跳过这步直接引入框架，否则你辛苦调完的框架只是给一个不可靠的大脑配上豪华汽车。

5.3 能不用Agent框架，就尽量别用

最后说一句可能不中听的话：现在很多所谓Agent项目，根本不需要Agent框架。定时任务、固定规则路由、批量文件处理、标准接口对接，这些场景用普通代码、定时任务、工作流引擎就能解决，而且更便宜、更快、更容易测试。硬给它们套一个自主决策的Agent，等于给自行车装火箭引擎。

选型这事，不是比谁框架用得潮，而是看决策权结构与风险是否匹配。我见过最成功的Agent项目，反而只用了极其克制的Agent能力——模型只做分类，其他全部由代码接管。想清楚“下一步由谁决定”之后，你可能发现答案不是“选哪个框架”，而是“这个任务压根不需要Agent”。

在实际项目里我养成的习惯是：第一周不写代码、不选框架，只写决策权矩阵，再拿几十条真实输入验证关键的模型决策点。框架永远是最后才定的东西。如果你现在正对着LangGraph和CrewAI纠结，不妨先把表格填了，答案会自己浮出来。真正让Agent项目翻车的，从来不是框架选错，而是决策权没有想清楚。