企业官网建设流程全解析

1. 为什么大家都在谈 Agent，但真正能做好的没几个

AI Agent 这个词，最近一年几乎被说烂了。你随便打开一个技术社区，都能看到类似“用 Agent 自动写周报”“基于 Agent 的智能客服”“Agent 帮你管项目”的帖子。但说真的，能把 Agent 从 Demo 做成可靠工程的人，比例并不高。问题不在大模型能力不够，而在很多人把 Agent 想简单了——以为给大模型套一层 Prompt 循环就是 Agent，结果一上线就四处漏风。

我理解的 AI Agent，是一个能感知环境、做出决策、采取行动，并利用外部工具完成目标的智能体系统。它不是一个模型调用，而是一个完整的工程系统。这里面有状态管理、有记忆读写、有工具调度、有失败恢复、有成本控制。任何一环掉了链子，整个 Agent 就变成一个只会空转的聊天机器人。你问它问题它答得头头是道，但让它真的去干活——订个会议、查个库存、批量处理个文件——它就崩了。

这篇文章要做的，就是把这些工程问题彻底拆开。我准备用“七要素”帮你理解 Agent 系统里必须有的核心组件，再用“七个决策点”帮你搞清楚落地时每一步该怎么选、为什么这么选。这个框架是我自己在多个 Agent 项目里反复打磨出来的，不是教科书理论，是真正上过生产环境的东西。

如果你是正在做 Agent 开发、或者准备从概念验证往工程化走的人，这篇文章应该能帮你少走不少弯路。我不打算堆概念，所有内容都按实操来写，像两个工程师坐下来聊方案一样，直给、不绕弯。

2. 先看大局：Agent 不只是“给大模型套个壳”

聊七要素之前，得先把 Agent 的整体架构视图立起来。不然你一上来就去抠细节，容易只见树木不见森林。

2.1 从单轮对话到自主决策：Agent 的本质区别

普通的大模型应用，是一个“请求-响应”模型。用户说一句话，模型回一段话。整个过程是同步的、一次性的、无状态的。Agent 不一样，它要在一个目标驱动下，自主地决定“下一步做什么”。这就像实习生和正式员工的区别——实习生等你安排一件事他做一件事，正式员工你给他一个目标，他自己拆解步骤、协调资源、推进执行，遇到问题还会自己想办法绕过去。

这个转变带来一个工程上的核心难题：控制流不再是线性的。传统软件是程序员写好的分支逻辑，Agent 是模型在运行时动态决定分支。这赋予了极大灵活性，也带来了极大的不确定性。同一个任务，同一套配置，跑十次可能有八种不同的执行路径。这种不确定性就是所有 Agent 工程问题的根源——你无法用传统软件的测试方式去验证它，也无法用传统软件的上线方式来保证它稳定。

2.2 我见过的三种主流 Agent 架构

先说结论：Agent 架构没有银弹，只有适不适合。

第一种是单循环内核架构。一个 Agent 实例，内部有一个“思考-行动-观察”的循环。模型每次生成决策，调用一个工具，拿到结果，再继续思考。这是最简单、最经典的架构，OpenAI 的早期函数调用应用、LangChain 的 Agent 都是这种范式。它的优点是好理解、好调试，缺点是所有逻辑都在一个上下文里，上下文一长就发飘。

第二种是双循环架构。外循环负责任务拆解，内循环负责子任务执行。你可以理解为一个项目经理带着一个执行团队。外循环把大目标拆成小任务、安排顺序、检查完成度；内循环针对单个小任务做具体的工具调用。这种架构适合复杂任务，但状态同步是个大坑，内外循环之间怎么传递进度、怎么处理部分失败，都要仔细设计。

第三种是多 Agent 协作架构。按角色拆成多个 Agent，比如一个 Planner、一个 Researcher、一个 Coder，各自有独立的系统提示词和工具集，通过消息队列或共享黑板来通信。这种架构的想象力最大，但复杂度爆炸得也最快——Agent 之间的“对话”谁来保证一致性？会不会出现 A 等着 B 的结果、B 又等着 A 的结果这种死锁？如果没想清楚，就别急着上多 Agent。

理解这三种架构之后，你再去看七要素，会发现每个要素在不同架构里的落点是不一样的。但不管哪种架构，核心组件基本一致——这就是我下面要拆的“七要素”。

3. 拆解 Agent 的核心骨架：必须先想清楚的七个要素

我给它起名叫“七要素”，是因为一个能完成真实任务的 Agent，至少要有这七个组件协同工作。缺一个，系统就跑不完整。我用一个买房子装修的例子来类比：目标是装出一套能住的房子，声音传感器是感知，户型图是记忆，装修方案是规划，找施工队是行动，电钻是工具，验收是反思。没有哪个环节可以省。

3.1 要素一：目标拆解器——没有目标，Agent 就是无头苍蝇

你给 Agent 的任务，往往是模糊的自然语言，“帮我整理这份客户资料”“优化这段代码”。但 Agent 内部需要一个清晰的结构化目标，才能开始干活。我把这部分叫 Goal Decoder，它负责把用户的模糊需求翻译成可执行的任务描述。

实操里我会把目标拆成三个字段：任务描述、成功标准、约束条件。比如用户说“整理客户资料”，目标拆解后变成：

• 任务描述：从这批 Excel 中提取客户名称、联系方式、最近联系时间字段，按行业分类。
• 成功标准：输出一个结构化 CSV，包含 5 个字段，数据完整率超过 98%。
• 约束条件：只处理表格文件，不读取 PDF；不得修改源文件。

这个拆解的过程，本质上是用一个 Prompt 模板做一次大模型调用。很多人忽略这一步，直接把用户的原始输入丢给 Agent 主循环，结果模型做着做着就忘了原始需求是什么了。目标越早结构化，后续的规划和执行就越不会偏。

3.2 要素二：感知模块——Agent 怎么“看见”外界

Agent 不能只活在模型的世界里，它得感知环境。这个环境可能是数据库里的某个记录、用户上传的文件、网页返回的状态、或者另一个系统的 API 响应。感知模块负责把环境信息转换成 Agent 可以理解的文本描述。

实践中有个容易踩的坑：感知模块拿到的原始数据太脏。比如工具返回的 JSON 里有大量无用字段，直接全塞给模型，上下文瞬间被污染。我的做法是每个工具返回结果之前做一层 extraction 处理，只保留对当前决策有意义的字段，再统一转成 Markdown 或紧凑 JSON 格式。这让模型读起来更轻松，决策准确率也会明显提升。

有一种更进阶的感知模式：让模型主动决定“我要去查什么”。传统做法是外部逻辑把数据推给模型，进阶做法是 Agent 自己发请求去拉数据。后者更灵活，但需要你给 Agent 暴露一个可控的查询接口，并限定查询边界，不然模型会胡查。

3.3 要素三：记忆系统——短期、长期和工作记忆要分开

Agent 的记忆是最容易被轻视、又最容易翻车的部分。很多人以为记忆就是把历史对话存进向量库，这完全是误区。我的经验是把记忆分成三种：短期记忆、长期记忆、工作记忆。

短期记忆是当前任务内的对话历史，通常直接放在上下文窗口里。它的管理核心是窗口策略——满了怎么裁剪、怎么压缩、哪些消息优先保留。长期记忆是跨会话的，用向量库做相似度检索，存的是历史任务的关键信息、用户的偏好、领域知识等。工作记忆是当前任务执行过程中的临时状态，比如“我已经处理到第三批文件了，下一批是 .csv 格式”。

三个记忆各管各的。短期讲究快，长期讲究准，工作讲究稳。如果你把三样东西混在一个库里，检索结果会非常混乱——模型可能搜到上次任务的中间状态，当成当前任务的事实来用，这是记忆污染的高发场景。

3.4 要素四：规划器——把一个大目标拆成能执行的小步

规划器是 Agent 的“策略大脑”。它要做的事是把目标分解成有序步骤，并且根据执行反馈动态调整。规划结果可以是：

• 一个固定序列：先做 A，再做 B，再做 C。
• 一个有依赖关系的 DAG：B 依赖 A 的结果，C 可以并行。
• 一个循环策略：反复执行“查数据-分析-更新计划”直到满足成功标准。

我最常用的是第二种思路——先让模型输出一个工作分解结构，再用代码去检查依赖关系，最后循环执行。纯靠模型一步步走，容易在中途跑偏；纯靠代码硬写流程，又丢掉了大模型的灵活性。折中方案是“大框架用代码保证、微步骤用模型决策”，这也是我后面要提到的规划策略选型的基础。

规划器还有一个隐藏功能叫“重新规划”。当执行过程中发现环境变化或者失败出现时，模型应该能主动回到规划阶段，而不是埋头继续执行原来的计划。这个能力的实现取决于你的循环结构里是否给模型保留了“返回规划状态”的出口。

3.5 要素五：行动器——让 Agent 真正去改变世界

有了计划，就必须有执行。行动器就是 Agent 的“手”。它负责调用工具、发送请求、操作文件、执行代码，总之是把决策变成现实动作。

这里工程上最重要的一个概念是幂等性。同一个动作执行两次，结果应该是一样的。比如“给用户发邮件”这个动作就不是幂等的——发两次就是两封邮件。在设计行动器时，我会给每个可写操作加上防重机制：任务 ID + 动作 ID 做去重键，类似“我处理过了就不会再处理”。这个细节在大模型场景下尤其重要，因为 Agent 可能因为工具超时然后重试，重试本身没错，错的是没有去重逻辑，结果就是重复动作落到了真实世界里。

行动器的异常处理也很关键。每一次工具调用都必须有超时控制，并且要把超时当成一个正常的工具返回结果传回给模型，而不是在代码层直接抛异常。这样模型才能知道“这个工具没响应”，从而调整执行策略。如果你在代码层吞掉了异常，模型的思考链就断了。

3.6 要素六：工具库——Agent 的能力边界就是工具边界

工具决定了 Agent 到底能干什么。没有好工具，Agent 就是一台只会说不会做的电视机。工程上的工具管理涉及注册、描述、参数校验、权限控制几个方面。

工具描述极其重要。模型是在阅读了工具描述之后，才知道“这个工具是干嘛的、什么时候该用”。我见过太多人写工具描述特别敷衍，比如“def send_email(params) 发送邮件”，模型根本不知道邮件好不好发、怎么发。好的工具描述应该写清楚：工具用途、输入参数含义、适用条件、返回格式、以及一个典型示例。这相当于你在给一个同事写交接文档，交得越清楚，他干得越利落。

参数校验也别全指望模型。大模型生成的参数偶尔会超出枚举范围，或者漏掉必填字段。工具层必须有 schema 校验，不合格就返回一条格式化的错误消息，告诉模型哪里错了、应该怎么改。这样模型就能在下一次调用时自己修正，成功率会大幅提升。

3.7 要素七：反思与评价器——Agent 进步的引擎

最后这个要素最容易被忽略，但它恰恰是决定 Agent 能不能从“玩具”变成“工具”的关键。反思与评价器的职责是：在每个行动之后，判断结果是否符合预期，要不要调整策略，要不要结束整个流程。

最简单的方式是让模型在每次工具返回后写一个 summary：这步做了什么、结果是否符合预期、下一步计划是否需要调整。别小看这一步，它能显著降低 Agent 跑偏的概率。因为大模型在思考的时候，如果不能明确知道“结果怎么样”，它就会盲目继续执行。加一个强制反思步骤，等于给 Agent 装了一个方向盘。

更进阶的做法是对照成功标准来评估：任务开始时定义的成功标准，在这里要被逐条检查。比如“数据完整率超过 98%”，完成率是 95%，反思器就应该判断为“未满足标准”，并决定进入“修正模式”而不是“宣布完成”。没有这个把关，Agent 经常会在 80% 完成度时就自己说“搞定了”。

4. 工程落地的七个决策点：每一个选择背后都有代价

七要素解决的是“Agent 里有什么”，七个决策点解决的是“具体该怎么做”。这是两个层面：前者是架构组件，后者是选型与实现策略。下面这七个决策点，是我在工程中每次都要反复权衡的地方。

4.1 决策点一：记忆架构，怎么选轻量方案和重量方案

记忆架构与你的场景规模强相关。我见过有人做了一个简单的客服 Agent，数据集只有几千条，却搭了 Milvus + 混合检索 + 重排序全链路，纯粹自虐。

决策表我一般这样给：

我实际踩过的坑是：一上来就用向量库，结果 embedding 模型选得不对，召回质量反而不如关键词检索。如果你的场景是“按订单号找历史记录”这种精确匹配，千万别上向量库，SQL 一个 WHERE 就解决了。向量检索适合的是“找意思相近的内容”这类语义模糊匹配，场景不对，方案再高级也是白搭。

另外，记忆写入也要有策略。不是什么对话都值得写进长期记忆。我常用的过滤规则是：信息必须包含实体（人名、时间、项目名），且被模型判定为“值得长期保留”才能入库。全量写入长期记忆的后果是，检索时翻出来一堆噪音，模型很容易被误导。

4.2 决策点二：规划策略，ReAct 还是 Plan-and-Execute？

规划策略上，最主流的两个选择是 ReAct 和 Plan-and-Execute。这俩不是互斥关系，但多数人没搞懂什么时候该用哪个。

ReAct是“思考-行动-观察”交叉进行的策略。模型每走一步都做一次推理，再调用工具，再看结果，再推理。它的优点是灵活性超高，适合探索型任务——比如排查问题，边查边试。缺点是上下文消耗大，因为每一轮思考+工具返回都会留在上下文里，走多了容易超长，还容易在中间步骤里绕圈子。

Plan-and-Execute是“先拆计划、再逐条执行”的策略。模型先把完整计划列出来，然后系统按计划一步步执行，每步之间不需要复杂的思考。它的优点是省 token、执行路径可控、好评估。缺点是灵活性差，万一计划列错了，后面全跟着跑偏。

我的建议是：任务边界清楚、步骤可预见的，比如批量文件处理、定时报表生成，直接 Plan-and-Execute；任务模糊、需要探索的，比如技术调研、复杂排障，用 ReAct。混合策略也可以做，但工程量会上去——你需要在执行过程中动态判断“当前步骤需要直接行动还是先思考一下”，这个动态判断本身也需要模型决策。

4.3 决策点三：工具调用的技术路线，函数调用还是 MCP

Agent 和工具之间怎么通信，这也有路线之争。目前主流是两条路线：模型厂商的函数调用协议（Function Calling）和开放协议 MCP。

如果你用的是 Claude 或者 GPT 系列模型，直接用官方的 Function Calling 是最省事的。模型会按协议输出结构化参数，你只需要做参数校验和后端执行。这个方案的缺点是绑定模型厂商，切模型就得重写一遍工具接口层。

MCP 我最近用得越来越多。它的思路是标准化工具暴露协议——服务端把工具封装成 MCP Server，Agent 作为 MCP Client 去调用。好处是工具可以一次封装、多个 Agent 复用，生态里现成的 MCP Server 也越来越多。缺点是调试链路变长，MCP server 本身的稳定性会成为新的故障点。

我建议项目初期用 Function Calling 优先，先跑通业务逻辑。等工具数量超过 20 个、或者多个 Agent 要共享一批工具时，再迁到 MCP。别一开始就全上 MCP，香是香，坑也是真的多。

还有一个技术细节：开源模型的话，Function Calling 支持参差不齐，我经常用“提示词约定 JSON 输出 + 解析器兜底”的方式。模型在 Action 字段里输出一个 JSON，你解析之后做 schema 校验，不合格就报错重试。这样用开源模型也能把 Agent 跑起来，只是需要你多做一些工程上的规矩。

4.4 决策点四：要不要上多 Agent，复杂度的边界在哪

多 Agent 是现在最火的方向，但我劝你谨慎。单 Agent 跑不动的任务，不代表多 Agent 能救场；多 Agent 能跑的任务，一个 Agent 加几个专用工具往往也能搞定，只是你可能没想清楚怎么设计。

我先说说什么场景真正适合多 Agent：

• 角色专业化需求强：比如“市场分析 + 产品文案 + 数据逻辑”三个能力领域，拆分给不同角色，Prompt 互不干扰。
• 任务能并行化：多个子任务之间没有强依赖，可以并发执行缩短总时长。
• 上下文隔离诉求高：一个超长文档研究任务，单个 Agent 的上下文窗口装不下，拆给多个 Agent 各读一段。

不适合的场景也明确：子任务强依赖、频繁需要共享状态、单 Agent 本身已经能稳定跑通的场景。强行上多 Agent，只会引入新的问题：消息传递延迟、状态不一致、调试困难。

我的工程建议是：先从单 Agent 起步，当上下文窗口成为唯一瓶颈时再考虑拆分。拆的时候按“能力域”拆，不要按“任务步骤”拆。按能力域拆出来的 Agent 边界清晰、功能内聚，按步骤拆出来的 Agent 有一半时间在互相要数据。

4.5 决策点五：确定性与自由度，你想要的到底是什么

Agent 系统的矛盾在于：模型天生有随机性，而工程系统天生需要确定性。你要在这个矛盾里找到自己的平衡点。

高自由度模式（temperature 高、无强约束）适合创意类任务，比如头脑风暴、写文案。但这模式下别让它操作实盘业务——它随时可能干出意料之外的事。高确定性模式（temperature 低、带固定流程约束）适合交易、审批、数据清洗这类场景。

我常用的实现手段有三个：

• 把核心业务分支用代码写死，模型只在分支内部做决策。比如审批流程里，“我的权限表”决定谁能批，模型只负责解释业务背景。
• 系统提示词里声明“严格按流程执行，禁止跳过步骤”，配合反思器强制检查。
• 对所有可写操作做二次确认——特别是涉及钱的、删数据的、发外部信息的，都要有一个人工审批或者规则闸门。

这里有个很大的误区：很多人以为确定性是模型参数调出来的，其实是工程架构调出来的。模型自由度只是其中一个变量，大部分确定性来自你给它设置的流程轨道和安全护栏。

4.6 决策点六：评估体系，怎么证明你的 Agent 是可靠的

做 Agent 工程最难回答的问题就是拉别人来验收：“你的 Agent 到底行不行？”如果说“我觉得行”，那毫无说服力。必须有评估体系。这个决策点决定你的 Agent 能不能从前置测试走向生产环境。

我的做法是搭一套三层的离线评估：

• 第一层是单步评估：给固定的输入，看模型输出是否满足预期。适用于验证工具调用正确性。
• 第二层是任务评估：给一个完整任务，看最后的结果有没有达到成功标准。适用于验证端到端能力。
• 第三层是批量回归：攒 200 条典型任务，每次改 Prompt 或代码之后跑一遍，看成功率有没有下降。

指标上我盯三个：任务完成率、平均步数、失败模式分布。完成率是总指标，平均步数是成本指标，失败模式分布用来指导优化方向。比如有一半的失败发生在“读取本地文件”这一步，说明你文件处理工具的鲁棒性有问题，该集中修工具而不是反复调 Prompt。

评估数据从哪来？第一版可以手工标注五六十条典型任务，后续用生产日志里的真实失败案例反哺补充。每一次线上翻车都是一条金贵的回归测试用例，别丢。

4.7 决策点七：生命周期与可观测性，Agent 上线之后怎么管

Agent 上线不是终点，是运维的起点。传统软件的日志是按接口路径记录的，Agent 的日志得按“任务 + 步骤 + 思考链”的维度记录。我强烈建议你至少记录这些内容：每次模型调用的输入输出、工具调用的请求和响应、每一步执行耗时、每次反思摘要、最后的结果状态。缺了这些，出了问题你根本无从查起。

可观测性工具方面，商业方案可以考虑 Langfuse、LangSmith，开源自建也可以。关键不是用什么工具，而是你是否能回答这三个问题：这个 Agent 现在在干什么？上一个动作是什么？如果失败了，卡在哪一步？

我的经验是主动加一层“流程事件总线”：Agent 每执行一个关键步骤，就往总线里推一个事件。运维面板上能看到实时的“任务-步骤状态流”，像看送外卖订单一样看你的 Agent 跑到哪儿了。这在调试多 Agent 或者长链路 Agent 时几乎必备。

还有一个生命周期问题：Agent 的状态怎么持久化。长任务跑一半进程重启了，能不能从断点续跑？这要求你定期快照工作记忆。我给出的最低要求是：每完成一个子任务就存一次 Agent 状态快照。这样真出问题，还能从最近一次快照恢复，而不是整个任务重来。

5. 七要素与七个决策点的映射：先看懂结构再谈选型

我经常被问到：“要素和决策点到底什么关系？”简单说，要素是 Agent 系统的构成零件，决策点是每个零件在生产环境中的落地选择。要素提醒你“别忘了什么”，决策点提醒你“这里要权衡”。

下面这张映射表，是我在设计 Agent 时反复参考的：

拿一个实际项目来走一遍：假设你要做一个“自动整理跨部门周报”的 Agent。目标拆解器把“整理三份 Excel 文档，产出一份汇总报告”结构化；感知模块负责读取 Excel，但只提取部门名、任务、进度字段；规划器先拆三个子任务——读文件、汇总、生成周报，只需一个简单的 Plan-and-Execute 流程；行动器调用 pandas 处理脚本；工具库暴露三个工具：读表、更新状态、生成模板；反思器在最后检查汇总数据是否和源文件一致。这个场景轻量，记忆架构用 SQLite 就够，工具调用用 Function Calling 就行，不需要多 Agent——你看，整个决策链路一下子清晰了。

6. 真实环境下踩过的坑：Agent 常见问题与排查思路

这部分我写点真实的东西。Agent 工程实践的坑，外面文章很少系统总结，都是一线开发用时间换来的。

6.1 Agent 陷入死循环

这是最高频的故障，表现是模型在同一两个工具调用之间反复横跳，或者反复说同样的思考内容。排查步骤：先看日志里工具返回是不是有问题——很多时候是工具返回的错误信息不明确，模型看不懂，只能重试。解决方法是让错误消息更可读，告诉模型“为什么失败、参数应该是怎样的”。其次是设置最大步数限制，比如单任务最多 20 步，超过就强制终止并上报。这和控制不住暴走的人要先拉走一样，别让他无限折腾下去。

6.2 记忆污染导致决策错乱

表现是 Agent 突然引用了一个与当前任务无关的“历史信息”。这是长期记忆检索质量差，或者短期记忆和长期记忆混在一起放的典型症状。排查时看这次的输入上下文里，有没有带入不该出现的旧信息。解决方法是把短期和长期记忆分开存储，同时给长期记忆检索加一个相关性截断：相似度低于阈值的直接丢弃，别塞进上下文。

6.3 工具调用失败集中在某个固定环节

日志一拉，80% 的失败都在同一个工具调用上，这是工具本身的鲁棒性问题。别以为调整提示词能救，问题大概率在工具实现层。比如你给模型一个 JSON Schema 参数，模型填错了格式，但你校验时只做了“格式不对就报错”，没告诉它正确的格式长什么样。好的做法是校验不通过时，返回一个改造过的示例，让模型能看到“你的参数离正确参数差在哪里”。

6.4 Token 成本爆炸

Agent 每执行一步都要调模型，上下文越来越长，成本像水龙头没关紧。最有效的控制手段是：“只让必需的共享上下文长期保留，中间步骤的内容及时压缩”。我习惯在每三轮行动之后做一次上下文压缩，用一个小模型把历史对话摘要成一段话，替代原始消息。这个方案我实测能把 token 消耗降 40% 以上，代价是有少量细节在摘要中丢失，所以关键信息要在行动器里另外保存，不让它进上下文摘要的增长链。

6.5 幻觉导致错误行动

模型在不确定的时候会把“不确定”写成“确定”，然后去执行一个错误的工具调用。这是 Agent 最危险的行为。我的防范措施是给工具层加严格参数约束，降低模型胡来的空间，同时用反思器强制复查“你刚才基于哪些事实做出了这个行动”。更有效的一层是“事实校验”，对任何写操作先要求输出依据，由另一个模型判断依据是否充分。当然这会增加成本，通常只用在最重要的写操作上。

7. 一点个人体会

做了这么多 Agent 项目，我的核心感悟只有一条：Agent 的工程化，本质上是给大模型的自由度装上轨道。不要让模型什么都自己决定，而是让它在你设计好的边界里做决策。边界越清晰，Agent 越可靠；边界越含糊，你越觉得它在“乱来”。

很多刚刚接触 Agent 的开发者，第一步就是去找最复杂的架构、最炫的工具，这其实是本末倒置。我在实际项目里，第一个版本永远是最简单的——单 Agent、ReAct、Greptile 式的循环就够了，验证了业务价值再考虑是不是要上记忆库，复杂一点的控制流，多 Agent 协作，这些是我后面才逐步加进去的东西。把最小闭环跑通，永远排在“用尽所有新技术”前面。

另外一个非常现实的经验是：不要追求一个通用 Agent。垂直场景里的 Agent，成功率远比通用 Agent 好做。先在一个狭窄的领域里做到 90% 的准确率，再考虑扩场景，这比一开始就要一个什么都能干的“万能助手”靠谱得多。

关于 Agent 的未来，我不做太多预测。但从工程角度看，真正能落地的 Agent 一定会越来越像一套精心设计的软件系统，而不是一团到处摸索的模型调用。希望这篇文章的七要素和七个决策点，能帮你更早地看到这一点，少踩几个我已经踩过的坑。