企业官网建设流程全解析

做 Agent 工程一年多，最深的感受是：网上聊 AI Agent 的人很多，但能把“这玩意儿到底怎么落地”讲清楚的人太少。概念满天飞，什么 ReAct、记忆、规划、工具调用，听起来都懂，一上手就懵。所以我一直想找个方式，把 Agent 的工程实现拆成一块一块能落地的东西，让正在做技术选型或者刚入门的开发者，能在一篇文章里把骨架搭起来。

这篇文章我想基于一个我自己梳理的框架来展开——七要素 + 七个决策点。七要素回答“一个 Agent 到底由什么组成”的问题，七个决策点回答“从零到一到底怎么选、怎么做”的问题。今天把这个框架完整地讲一遍，顺带把我实际开发中踩过的坑和验证过的方案一并交代清楚。

无论你是准备用框架快速搭原型，还是想从底层逻辑自己写一个可用的 Agent，这篇都能给你一个相对完整的参考。

1. 为什么需要“七要素”和“七个决策点”两个框架

1.1 概念太散，缺一个统一的结构来装

我们每天会看到大量和 Agent 相关的讨论，有人强调规划能力，有人死磕记忆机制，有人觉得工具调用才是灵魂。这些说法单独看都对，但拼在一起就变成了一堆零散的碎片。你问一个做过 Agent 的人“你的系统架构是什么”，他说出的往往是一个“大概的样子”，而不是一个完整的结构。

我整理七要素，就是因为需要给 Agent 找一个能对应到代码模块的拆解方式。就像盖房子要先有图纸，照着图纸知道哪里是承重墙、哪里是走线管，做 Agent 也要先知道哪些部分缺一不可。七要素不是学术定义，是我在实践中从代码里反推出来的——每做一个 Agent，我都会记下自己写了哪些模块，最后发现绕不开的，就是这七个。

1.2 七要素告诉你“有什么”，决策点告诉你“怎么选”

光有七要素还不够，因为它只告诉你结构，没告诉你怎么做决定。同样是记忆模块，是直接用简单的列表记住对话，还是引入向量数据库？同样是模型调用，是用一个主流大模型还是多模型路由？这些选择直接影响整个项目的走向。

所以我后来又梳理出七个决策点。七要素是静态的骨架，决策点是动态的岔路口。一个是地图上的地点，一个是走到每个路口时该转哪个方向。两个框架配合，才能把一个 Agent 从概念变成可运行的工程系统。

提醒一下：这两个框架并不是学术界某个论文里提出的标准，而是我在多个项目里沉淀出的一套方法论。如果你有自己的组织方式，完全可以沿用你自己的，这套框架的意义在于提供一个经过验证的参照系。

2. 七要素拆解：Agent 到底由什么组成

2.1 目标定义：没有目标，Agent 就是个空壳

做 Agent 最容易犯的错，就是上来就写提示词，然后让模型自己“发挥”。结果模型确实在努力发挥，但充分发挥了五分钟之后，你发现它压根不知道自己要解决什么问题。

目标定义是 Agent 一切行为的起点。它不只是说“帮用户查天气”这种粗粒度目标，而是要把目标拆成可执行的范围、边界和验收标准。比如“帮用户查天气”这个目标，工程上要明确：支持的天气信息粒度是小时级还是天级；查询失败时是直接报错还是走兜底逻辑；是否需要主动提醒用户带伞，还是只展示气象数据。这些不明确，Agent 的规划、工具调用全是空中楼阁。

实操上，我习惯在系统初始化时把目标定义成结构化的配置，而不是散落在一大段自然语言提示词里。比如用 JSON 描述任务描述、关键约束、输出格式要求，再把这份结构化配置注入到模型的系统提示词中。这样后期迭代时可以针对性地调整某个字段，而不是每次整体重写一段话。

2.2 上下文管理：决定模型“看得见什么”

模型本身是无状态的，它每次推理都只依赖你喂给它的上下文窗口。所以上下文管理决定了 Agent 能“看见”什么，也就直接决定了它的回答质量。

上下文管理最少包含三个层面：当前对话轮次里的信息、从外部检索回来的知识、系统自身携带的规则和约束。我刚做 Agent 时吃了大亏，把所有内容一股脑塞进上下文，结果模型窗口一爆，早期信息全被“挤”出视野，Agent 表现得像个失忆症患者。

后来我学乖了，把上下文管理分成两层来做。一层是动态裁剪，控制每轮对话保留多少历史信息，超过阈值的部分要么压缩成摘要，要么丢进记忆系统存储；另一层是结构化组织,把所有上下文按“系统指令、历史对话摘要、实时观察结果、外部检索片段”分区块管理。这样做既保证了关键信息不被稀释，也方便调试时定位模型到底是基于哪部分内容做出的判断。

2.3 模型调用：Agent 的“大脑”接口

模型调用这个要素，很多人觉得不就是一个 API 请求吗？确实简单，但在 Agent 系统里，模型调用比单轮对话复杂得多。

首先，Agent 跑一次任务往往需要多次调用模型。一次规划要调用，执行一次工具要调用，分析工具返回结果又要调用。这些调用之间还有依赖关系，上一次的输出是下一次的输入。所以在工程上，模型调用不只是一个函数，而是一个调用管理器，负责统管请求频率、超时重试、模型切换、Token 控制和结果校验。

其次，模型选择直接影响 Agent 的成败。在实际项目中，推理能力强但响应慢的模型，和推理一般但响应快的模型，适用场景完全不同。我的经验是：复杂任务的主推理链路用强模型，简单分类或信息抽取等子任务用轻量小模型，通过一个路由层做分发，成本和效果能得到不错的平衡。

2.4 工具调用：Agent 连接世界的“手脚”

如果模型只有大脑没有手脚，那它再聪明也只能纸上谈兵。工具调用是 Agent 和外部系统交互的通道，也是“ Agent 能做什么”的天花板。

工具不只是“调用外部 API”，它包括搜索、代码执行器、数据库查询、操作第三方软件、调用其他模型等。每个工具都对应一个明确的能力抽象。工程实现上，我强烈建议每个工具都定义成标准的函数描述结构，包含工具名称、功能描述、输入输出参数、调用示例。这样模型才能准确理解工具能干什么、该怎么用。

真正复杂的是工具选择的决策逻辑。当你有十几个甚至几十个工具时，模型如何在合适的场景下选对工具？这需要工具描述写得足够清晰，避免歧义。比如两个工具都能查数据，但一个查的是用户行为日志，一个查的是业务交易数据，描述里必须把边界写清楚，否则模型就会张冠李戴。我在实践中吃过好几次这样的亏。

2.5 规划与推理：把大任务拆成可执行步骤

Agent 和普通聊天机器人最本质的区别，就是规划能力。普通聊天机器人只会“回答问题”，Agent 得会“解决问题”——把一个大目标拆成一个个小步骤，按合理的顺序执行。

规划层面的工程实现，常用的思路是 ReAct 模式，也就是让模型在“思考 → 行动 → 观察”之间循环：先思考当前状态需要什么行动，然后调用对应工具，再观察工具返回的结果，决定下一步动作。这个循环一直持续到任务完成为止。

但 ReAct 不是万能的，它有明显的缺陷——在长任务中容易陷入重复动作的怪圈。模型可能反复调用同一个工具，得到同样的结果，然后继续重复同样的调用。所以我在做规划模块时，会额外加一个任务进度追踪器，记录已经执行过哪些步骤、取得了什么结果、剩余哪些待办。一旦发现模型开始重复执行相同动作即未产生新信息，就强制中断，让它重新评估计划或者直接告知用户。

2.6 记忆系统：跨会话保持“连续性”

记忆是让 Agent 从“一问一答”升级为“持续协作”的关键。没有记忆的 Agent，每次对话都是第一次见面，用户必须反复重申自己的偏好和历史信息，体验极差。

工程上，记忆通常分为短期记忆和长期记忆。短期记忆就是当前会话上下文，刚才提到的上下文管理处理的就是这部分；长期记忆则是跨会话存储的用户偏好、历史决策、过往对话摘要，一般存在向量数据库或者结构化数据库里。

我在项目里常用的做法是混合记忆方案：会话进行中，用上下文窗口保存细粒度对话信息；一轮会话结束后，把整轮对话浓缩成摘要，存入长期记忆库。当用户开启新会话时，先从长期记忆库检索与本轮任务相关的记忆内容，注入上下文。这套方案实现起来不复杂，但体验提升非常明显。

一个人要做记忆系统，最容易踩的坑是做精确匹配检索，然后抱怨“明明用户上次说过，为什么这次没想起”。你要清楚，记忆系统本质是“模糊关联”而不是“精确查找”，要用语义相似度检索，而不是简单的关键词匹配。这就是为什么长期记忆几乎都会和向量化检索放在一起讲的原因。

2.7 反馈与反思：让 Agent 能“自我修正”

最后一个要素，也是最容易被忽略的一个——反馈与反思机制。没有反馈闭环，Agent 就像蒙着眼睛开车，一路跑偏也不自知。

反馈机制在工程上体现在两个层面。第一层是结果验证，Agent 执行完步骤后，要主动验证结果是否满足预期。比如执行完代码后检查运行是否报错，访问完网页后确认是否拿到有效信息。第二层是反思修正，当验证发现结果不对时，Agent 能读取错误信息，调整下一步策略，而不是一条路走到黑。

我在做代码生成类 Agent 时深有体会。刚开始没有反思模块，模型生成代码报错就报错了，任务直接终止。后来我加入了一个“执行反馈循环”：让 Agent 读取报错信息，把报错细节注入上下文，带着错误信息重新规划修正方案，再生成一次代码。成功率直接提升了几个档次。这个机制做起来不难，但收益极其可观。

3. 七个决策点：从设计到上线的关键选择题

3.1 框架选型：自研还是用框架，这是第一个岔路口

做 Agent 的第一个决策，是用现成框架还是从零搭建。市面上有 LangChain、AutoGPT、Semantic Kernel 等一系列开源框架，也有各云厂商的 Agent 平台方案。

我的建议是：如果目的是快速验证原型，直接上框架；如果目的是深入理解 Agent 机制、要对系统做深度定制，那就别偷懒，自己搭一遍核心模块。实际上，即使用了框架，你最终也要理解每个模块的原理才能排查问题。

我自己的经验是“半自研”路线：核心的规划循环、工具调用协议自己实现，模型的调用、向量存储等底层能力借助成熟库。这种组合灵活性和开发效率都能兼顾。框架选型没有标准答案，但有一点非常确定——不要在项目初期就绑死某个框架的专有概念，优先选择抽象层次适中、社区活跃度高的方案，给自己留出切换空间。

3.2 模型选择：性能、成本和响应速度的博弈

模型选择是做 Agent 时最头疼的决策之一。市面上模型很多，性能强弱、价格高低、响应快慢差异巨大，而这三者往往是互斥的，你想要强性能，就要接受高成本和慢响应。

我的实践思路是按角色拆分模型，而不是全局用同一个模型。主规划角色，负责理解目标、拆解任务、判断下一步动作，用推理能力强的模型；工具调用角色，负责把自然语言指令转化为具体的 API 调用参数，用支持函数调用且格式稳定的模型；轻量角色，负责摘要、关键词提取、信息分类等窄任务，用小模型。

这样拆分之后，整体 Token 消耗甚至可能比单纯用一个大模型更省，因为大量高频的窄任务被小模型承担了，而强模型只需要处理低频高难度环节。模型拆分是个系统工程，前期要花点心思设计提示词和调用逻辑，但长期回报非常明显。

3.3 工具协议：定义 Agent 与工具之间的“接口语言”

当 Agent 需要调用外部工具时，和工具之间的交互协议就变成一个关键决策点。这个决策直接决定了工具接入的复杂度、扩展的便利性以及调试的难度。

目前比较主流的方案是Function Calling风格的结构化调用。模型直接输出一个结构化的函数调用对象，包含函数名称和参数。这套方案的优点是稳定、可控，主流模型都原生支持，是我首选的方案。另一种方案是用MCP（Model Context Protocol）这类标准化协议，好处是工具接入可以标准化、低成本共享，适合工具数量多且跨越团队边界的情况，但引入额外协议层后，出问题时要排查的点也更多了。

我个人给小团队的建议是：从 Function Calling 开始，先把业务跑通，再考虑要不要引入更重的协议标准。工具协议选型不追求“最先进”，追求“最省心”。

3.4 记忆策略：短期窗口、向量库还是结构化摘要？

记忆策略是所有决策点里最能拉开体验差距的环节。选不好，Agent 要么健忘，要么拖着沉重历史包袱越来越迟钝。

我实际用下来，记忆策略可以分三层来决策。第一层是滑动窗口，保留最近几轮对话原文，适合大多数场景，简单有效；第二层是滚动摘要，当窗口放不下时，把早期的对话改写为摘要，压缩成本低且信息保留度高；第三层是向量化长期记忆，跨会话沉淀知识和用户偏好，要配合检索模块使用。

三层策略成本递进，效果也递进。我建议按需选择，不要一上来就上向量数据库。很多场景用滚动摘要就够了，向量库反而增加部署复杂度。我见过不少开发者把简单项目搞复杂，最后陷入维护泥潭的例子。

3.5 执行模式：单步执行、多步循环还是人机协同

Agent 执行任务时，是让它一口气把所有步骤都执行完，还是每执行一步就停下来征求用户确认？这个决策关乎用户体验、任务成功率和容错能力。

完全自动执行听起来很酷，但在真实业务中风险很大——Agent 一旦执行错了方向，可能已经造成了不可逆的影响。单步执行又太繁琐，用户会被频繁打断，失去 Agent 的意义。目前比较理想的是人机协同模式，允许 Agent 自主处理低风险、可自动化的步骤，但在关键操作、高成本调用、不可逆操作等预设环节，停下来向用户确认。

实际项目里，我会给每个工具定义一个“危险等级”。高等级操作需要用户确认，低等级操作只管自动执行。这套策略实现成本不高，却能大大提升用户对系统的信任感，是非常值得做的一个决策点。

3.6 部署形态：API 服务、定时任务还是本地脚本？

同样一个 Agent，部署形态不同，工程复杂度天差地别。做技术方案时，很多人都忽略了这一步。

如果你的 Agent 是给业务系统提供能力，比如聊天机器人、智能客服，那就要部署成API 服务，需要考虑并发、限流、负载均衡和日志监控；如果你是做一个数据采集或内容自动生成的工具，可以做成定时任务，按固定周期运行，处理完就退出，部署压力就小很多；如果只是个人工具，跑在本地脚本里，断开网络也能执行，运维成本几乎为零。

我见过很多开发者把 Agent 一律部署成 Web 服务，明明业务只是定时汇总几条信息发出来，却要维护一堆服务组件，属于过度设计。部署形态的决策原则很简单：按实际调用方式来决定形态，能脚本解决的就不要上服务。

3.7 评测与迭代：怎么知道 Agent“到底行不行”

最后一个决策点，也是很多开发者的盲区——评测方式。Agent 是生成式系统，每次输出都有随机性，你怎么知道这次改动是变好了还是变差了？

我建议至少从三个维度建立评测体系。任务完成率是最核心的指标，让 Agent 在预设任务集上跑，统计成功完成的比例；执行效率是次要指标，记录完成一个任务平均要调用多少次工具、多少轮模型请求；稳定性也很重要，同一个任务反复跑多次，看结果是否保持一致。

评测体系搭建之后，每次改动模型、提示词或工具定义，都要跑一遍回归测试。这个习惯能让你的 Agent 项目从“感觉还行”升级到“有数据支撑的稳定系统”。我在项目里维护了一套内置评测用例，每次迭代跑一下，几分钟就能知道新改动有没有引入回归问题。

4. 实操过程与核心环节实现

4.1 场景设定：从一个“技术内容摘要 Agent”说起

前面讲了不少理论和决策，这一节拿一个我之前做的实际项目来跑一遍流程。这个项目是一个“技术内容摘要 Agent”：给它一个 RSS 链接或者网页 URL，它能自动抓取文章内容，提炼核心观点，输出结构化摘要，并且按用户的兴趣偏好进行重点标记。

这个场景不算复杂，但完整覆盖了七要素和七个决策点，非常适合用来做案例拆解。我下面按实际开发顺序，把关键实现环节一一列出。

4.2 环境准备与基础框架搭建

我选用的是一套“半自研”的实现方式：

• 语言：Python 3.11
• 核心循环：自己实现，不依赖重框架
• 模型调用：通过 OpenAI 兼容接口调用
• 网页内容抓取：readability 库做正文提取
• 记忆存储：轻量级 SQLite 加向量检索（用 embedding 模型生成向量）

先做一个最简可运行版本，把“读取链接 → 提取正文 → 调用模型 → 输出摘要”这条主链路跑通。这一步的核心是让 Agent 具备最基本的行为能力，不涉及太多复杂机制，但一定要把每个模块的接口都留好。

from dataclasses import dataclass from typing import List, Dict, Any @dataclass class ToolResult: success: bool data: Any = None error: str = "" class BaseAgent: def __init__(self, model_config: Dict[str, Any]): self.model_config = model_config self.memory = [] self.tools = {} def register_tool(self, name: str, func, description: str): self.tools[name] = { "func": func, "description": description } def run(self, task: str) -> str: # 子类实现主循环逻辑 raise NotImplementedError

这段代码虽然简陋，但它定义了整个 Agent 的骨架——工具注册机制和任务入口。后续所有模块都往这个框架里填。

4.3 核心模块实现：工具注册与调用链路

接下来要做的第一步，是给 Agent 注册一个“抓取网页”的工具。这个工具接收一个 URL，返回清洗后的正文文本和标题，是内容摘要场景下最核心的能力。

def fetch_webpage(url: str) -> Dict[str, str]: """抓取网页并提取正文内容""" import requests from readability import Document try: resp = requests.get(url, timeout=15, headers={ "User-Agent": "Mozilla/5.0 (compatible; AgentBot/1.0)" }) resp.raise_for_status() doc = Document(resp.text) return { "title": doc.title(), "content": doc.summary(html2text=False) } except Exception as e: return {"error": str(e)}

工具注册完成后，模型如何知道这个工具的存在？关键在于把工具能力描述转换成模型能理解的 JSON Schema，随请求一起发送给模型。这个设计非常重要，因为模型能否准确调用工具，直接取决于工具描述的质量。我要求所有工具描述里必须写清楚功能的边界、参数类型、必填项和返回值。

4.4 主循环实现：一个简化版的 ReAct 推理引擎

有了工具，还得有让 Agent 自主决定“什么时候调用工具、怎么用结果”的引擎逻辑。下面这个简化版的 Agent 主循环，完整实现了“思考 → 调用 → 观察 → 再思考”的 ReAct 模式。

class ContentSummaryAgent(BaseAgent): def _call_model(self, messages: List[Dict[str, str]]) -> str: # 实际项目中替换为对模型的 HTTP 调用 # 返回模型输出文本，或结构化函数调用指令 pass def run(self, task: str) -> str: # 系统提示词：说明 Agent 的职责、可用工具、行为规范 system_prompt = "你是一个技术内容摘要助手。请使用 fetch_webpage 工具抓取内容，然后输出结构化摘要。" messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": task} ] max_steps = 5 for _ in range(max_steps): response = self._call_model(messages) messages.append({"role": "assistant", "content": response}) # 解析模型输出中的函数调用指令 action = parse_function_call(response) if action is None: break # 模型没有调用工具，视为任务完成 if action["name"] == "fetch_webpage": result = fetch_webpage(action["arguments"]["url"]) messages.append({ "role": "tool", "tool_call_id": action["id"], "content": json.dumps(result, ensure_ascii=False) }) else: # 工具不存在时，告知模型错误，让其修正 messages.append({ "role": "tool", "tool_call_id": action["id"], "content": f"工具 {action['name']} 不存在，请检查可用工具列表。" }) return messages[-1]["content"]

这个主循环里有两个关键点。一是最大步数限制，防止 Agent 陷入无限循环；二是工具不存在时的兜底提示，强制模型回到正确路径。这两个机制虽然简单，却是保证 Agent 工程稳定性的基础保障。

4.5 加入记忆与反馈：从“能跑”到“好用”

基础版本能跑通之后，我再加入两层优化：长期记忆和结果反馈。

长期记忆的实现思路是：当用户给 Agent 指定摘要偏好（比如“关注架构设计部分”“忽略广告软文”）时，系统把这些偏好向量化，存入 SQLite 表中。下次同一用户再做摘要任务时，先检索匹配的偏好记录，和当前任务一起注入上下文。

def save_preference(user_id: str, preference: str, embedding: List[float]): # 将用户偏好存入记忆库 pass def load_relevant_preferences(user_id: str, task_embedding: List[float], top_k: int = 3): # 从记忆库中召回与当前任务最相关的偏好 pass

结果反馈的实现则放在摘要输出之后。Agent 会先自我检查摘要是否覆盖了用户指定的偏好点，如果发现遗漏，就带着“自查发现未覆盖某个要点”的反馈信息，重新调整摘要内容，直到满足条件或达到最大尝试次数。这一步让 Agent 从“生硬执行”变成了“有质量意识”，体验上的差距非常大。

5. 常见问题与排查技巧实录

5.1 模型“乱调用工具”：工具描述需要更严格

做工具调用时，最常遇到的问题就是模型在无关场景下调用工具，或者调用了错误的工具。排查思路很简单：去检查工具描述里是否有歧义词或者边界说明缺失。

比如你有一个查天气的工具和一个查日历的工具，模型分不清也正常，因为这两个都和时间相关。我的解决办法是在工具描述里明确加上“本工具仅用于查询气象信息，不处理日程安排”这类负向约束。描述越明确，模型的调用准确率越高，这个投入产出比极高。

5.2 Agent “失忆”：上下文被截断

很多开发者反馈，Agent 在长对话后突然“忘记”前面的内容。这一般不是模型的问题，而是上下文管理策略出了问题——你只是简单地把消息按时间顺序堆叠，超出窗口的部分被系统直接截断，而你没有做任何摘要或者压缩处理。

解决办法是引入消息压缩机制。当消息数量超过阈值时，触发一次摘要操作，把早期的多条消息浓缩成一条摘要消息，再替换掉原来的消息列表。这样既保留了关键信息，又在不增加 Token 负担的情况下实现了长对话记忆。

5.3 重复执行同一动作：缺少进度感知

Agent 在复杂任务里容易陷入“循环怪圈”：反复调用同一个工具，拿到同样的结果，再发起同样的调用。这是因为你的系统只给了模型“当前状态”和“可用工具”，却没有告诉它“已经尝试过什么”。

排查这个问题，要检查你的提示词或系统状态里，是否注入了任务进度信息。我给 Agent 的每一次循环都会维护一个“已执行步骤列表”，并把它注入提示词中，明确提示“你已经执行过以下动作，请勿重复”。这个方法在大多数场景下都能有效遏制重复执行。

5.4 工具报错后任务终止：缺少错误恢复策略

当工具调用返回错误时，Agent 如果直接终止任务，用户体验会非常糟糕。很多开发者以为这是模型能力不足，实际上是你没有给模型一个“恢复路径”。

正确的做法是：工具报错时，把错误信息完整返回给模型，并提示模型可以尝试替代方案。比如抓取网页超时了，可以让 Agent 尝试另一个镜像地址，或者提示用户内容获取失败并要求换一个链接。让 Agent 带着错误信息重新思考策略，而不是终止任务，这是把“玩具 Agent”升级为“可用 Agent”的关键一步。

5.5 常用排查速查表

6. Agent 工程化的下一步扩展方向

这套七要素和七个决策点的框架，帮我把 Agent 项目从“一团乱麻”逐步理顺成了一块块可迭代的积木。但如果你的目标不止于做一个演示原型，那还有几个方向值得继续探索。

第一，多 Agent 协作架构。当单个 Agent 的能力上限无法满足需求时，可以拆分成多个各司其职的 Agent，一个负责规划、一个负责执行、一个负责审查，通过消息机制协作。这种架构的关键在于任务的拆分和结果的整合，复杂度比单 Agent 高一个量级，但能力上限也高一个量级。

第二，更细粒度的可观测性。Agent 的执行链路天然就是一条链条，每个环节都可能出错。我强烈建议为你的 Agent 系统建立完整的日志链路追踪，记录每一次模型调用的输入输出、每个工具的调用参数和返回结果、每一轮的思考内容。调试 Agent 时，一份完整的执行记录比什么工具都好用。

第三，更健壮的评测体系。如果你的 Agent 要用于生产环境，一定不能停留在“冒烟测试”阶段，要用一个覆盖各种边界场景的评测集来做自动化回归。我在实际项目中维护了一个“坑集”，专门收录历史出过问题的案例，每次改动模型或提示词就全量跑一遍，确保新增逻辑没有破坏已有能力。这个习惯帮我避掉了无数隐性回归。

我在实际开发中的体会是，Agent 工程和传统后端开发一个很大的不同在于——它的行为本身带有不确定性，你没法用传统的“输入 A 必定输出 B”的思维来对待它。你需要做的就是通过结构化的设计，把不确定性约束在一个可控范围里，然后给系统加上足够的反馈和修正机制，让它在大部分情况下能自己兜住自己的错误。

这七个要素和七个决策点，本质上就是我在这个“约束不确定性”的过程中沉淀下来的工具箱。框架本身不复杂，真正复杂的是每一个细节里的权衡和取舍，这些只能靠多做项目慢慢积累。希望这篇文章能帮正在做 Agent 的你，少走一些我走过的弯路。