企业官网建设流程全解析

这半年我一直在折腾AI Agent，准确说是在做Agent的工程落地。圈子里聊Agent的人很多，但大多数讨论都停在概念层：什么“智能体是AI的终极形态”“Agent会取代工作流”，听起来很热闹，真正动手搭的时候却不知道该先做什么。我接过不少类似“用AI Agent开发Django项目”“让Agent自动发小红书内容”的需求，最后发现一个共同点：大家缺的不是大模型，而是把Agent“工程化”的那套骨架。

这篇文章我想用两条线把AI Agent的工程实现讲透。第一条线是“七要素”，回答“一个Agent到底由什么构成”；第二条线是“七个决策点”，回答“你真要动手搭的时候，每一步该怎么选”。两条线走完，你会发现Agent并不神秘，它就是一个带着目标和工具的循环程序，难点全在细节落地。文章适合正在搭第一个Agent的开发者、要给团队选型的技术负责人，以及被LangChain、Dify、CrewAI这些框架绕晕了还没开始写代码的朋友。

1. 先用一句话说清楚：Agent 到底是个什么东西

1.1 不是在聊模型，而是在聊一套执行循环

很多人把Agent误解成“一个更聪明的模型”，这是一个挺大的误区。模型只是Agent的大脑，真正让Agent“活”起来的，是一套感知、规划、行动、观察的循环，英文圈叫Agent Loop，中文社区有人叫“控制循环”，有人叫“执行回路”。你可以把它理解成一个人：脑子负责想（大模型），手负责干活（工具调用），眼睛负责看结果（读取返回值），记性负责记住前因后果（上下文与记忆库），这几样东西串起来，才叫Agent。

所以如果有人问我“Agent是不是套壳”，我的回答是：只调一次模型接口生成一段文本，那确实是套壳；但当你把目标拆解、工具调用、记忆写入、失败重试、权限控制都串起来之后，你会发现Agent真正的工作量在模型以外的部分。现在你能看到的各种Agent产品，从OpenAI的Codex命令行助手，到桌面端的Hermes这类个人助理，再到企业内部跑批任务的自动化机器人，底层都是同一个思路：给定一个目标，让模型在不断“试错—观察—调整”的循环里把任务做完。

1.2 七要素是哪七个，对应工程里哪些模块

我在带项目的时候习惯先把“Agent具备什么”讲清楚，也就是标题里说的七要素。这七样东西分别是：目标（Goal）、环境感知（Perception）、记忆（Memory）、规划（Planning）、工具与行动（Tools/Action）、知识与技能（Knowledge/Skills）、安全与治理（Governance）。七要素不是学术定义，是我从一堆实战项目里倒推出来的“能力清单”。任何一个Agent，无论用的是LangGraph还是Dify，无论跑在云端还是本地，最后都会被拆成这七个模块。

这套清单最大的价值是“查缺补漏”。很多人搭Agent只做了模型加工具，跑起来以后发现要么记忆混乱，要么规划失败后不会恢复，要么工具乱调没有管控，出问题的时候根本不知道短板在哪。把七要素对着自己的项目过一遍，基本就能定位问题出在哪个环节。

2. 七要素逐项落地：一个真正的 Agent 需要装哪些“器官”

2.1 目标与规划：把大任务拆成可执行的小步骤

先说说目标。目标在工程上不是一个空泛的词，它要变成“可验证的中间产物”。你在系统提示词里写“帮我把这个Python项目重构一遍”，这不算目标，算愿望。真正可执行的目标，至少要拆成类似“先读目录结构”“定位核心模块”“生成重构方案”“执行改动”“跑一遍测试”这样的小步骤。这就是规划要素的活：让模型先生成一份计划，再逐项执行。

工程上常见的做法是让模型输出一个结构化任务列表，形式可以是JSON数组，也可以是有依赖关系的DAG。我习惯让模型先产出Plan，然后进入Plan-Do-Review循环：执行一步，看结果，决定下一步是继续还是修正计划。这里有个重要的工程细节：规划结果不要只存内存，要落盘或存数据库。因为一次Agent任务可能跑几分钟甚至几小时，中间进程崩了，如果计划没保存，就得从头再来。把计划序列化成JSON存起来，是成本极低但收益很高的一步。另一个容易被忽略的问题是规划损耗：模型每次生成计划都要消耗Token，拆得越细，消耗越大，响应越慢，所以规划粒度要根据任务复杂度动态调整，别让Agent为了写个邮件先列20步。

2.2 记忆：短期、长期和偏好，三类记忆分开存

记忆是Agent工程里最容易被做坏的部分。很多人的第一版Agent只有上下文窗口，也就是把对话历史和工具返回一股脑塞给模型。这在任务短的时候没问题，一旦任务拉长，上下文就爆了，模型开始“忘事儿”，这其实是上下文长度到了上限，而不是模型变笨了。

我习惯把记忆拆成三层。第一层是短期工作记忆，对应的就是上下文窗口，只保留“当前任务正在执行的那几步”。第二层是长期事实记忆，存那些跨任务需要记住的信息，比如用户的偏好、项目背景、历史决策结论，一般用向量库存，检索后按需注入。第三层是执行记忆，记录“上次任务做到哪一步、用了哪些工具、结果如何”，用Redis或者普通数据库存结构化记录都行。

三类记忆的关键区别在于“生命周期”。工作记忆跟任务走，任务结束就清空；长期记忆跟用户走，索引和向量做好之后可以长期复用；执行记忆跟项目走，主要用来支持断点续跑。另外，Token和记忆是强绑定的，很多人问“AI Agent token是什么意思”，其实就是在问一次执行消耗了多少Token。你往上下文里塞的内容越多，Token消耗就越大，所以记忆管理的本质是“在有限的Token预算里，放最值得放的信息”。

2.3 感知与行动：工具调用是 Agent 的“手和脚”

感知和行动在Agent里通常是同一个动作的两面：调用工具，拿到结果。工具可以是搜索引擎、数据库查询接口、文件读写、命令行执行，甚至是一个浏览器自动化脚本。工程上要做的事情是“把工具描述清楚，让模型知道什么时候该调、调的时候填什么参数”。

这就要用到Function Calling机制。你把每个工具写成一个JSON Schema，描述清楚工具名、功能说明、参数列表和必填项，模型在对话过程中会判断“当前该调工具了”，然后输出一次结构化的工具调用请求。你的程序接到请求后执行真正的函数，把返回值再以工具消息的形式发回给模型。这个来回就是Agent循环里最核心的数据流。

在实际项目里，工具描述的质量直接影响成功率。描述写得含糊，模型就乱调；参数类型写错，模型就报错。我见过太多项目把工具描述写得像给自己看的技术注释，结果模型完全不知道这个工具在什么场景下该用。写工具说明要像写产品说明书：解释适用场景、给出参数示例、标明返回内容的格式。另外，工具不一定要单独暴露，可以把多个工具组合成一个“技能包”，比如“代码分析技能”里面包含读文件、搜依赖、查Git记录三个工具。这种“工具→技能”的分层，正是现在Agent Skills这类设计想解决的问题，本质上是让模型减少一次决策负担。

2.4 知识与资源：RAG 只是其中一种输入通道

知识要素解决的是“模型不知道但业务需要的资料从哪来”。最常见的工程化方案是RAG：把文档切块、向量化、存入向量库，在模型回答或规划前先做一次相似度检索，把最相关的片段拼进上下文。但我想提醒一点：RAG不是万能的，它只是“知识输入”的一条通道。

还有一种输入通道是“结构化查询”，直接查业务数据库，比如让Agent查库存、查订单，这种场景用向量检索反而是错的，正确做法是给Agent配一个查询工具，让它自己去数据库里执行SQL。第三种通道是“技能内置”，把某些行业规则直接写进提示词或者工具逻辑里，不经过检索。比如一个负责写Python代码的Agent，PEP8规范这种稳定知识可以内置，没必要每次去检索。

配置知识的时候最怕“什么都往里塞”。知识不是越多越好，注入无关内容会稀释模型注意力，还白白烧掉Token。我一般会先问一句：这条知识是稳定的还是变化的？稳定的，写成提示词或代码；变化的，走RAG或数据库查询。把知识的时效性分清，工程复杂度会下降很多。

2.5 安全与治理：约束要写在代码里，不能只靠提示词

安全是七要素里最不性感但最容易出事故的一项。Agent一旦能调工具，就等于给了模型一双能干活的手，这双手如果不受管控，轻则调错接口，重则删错文件、发错消息、泄露敏感数据。

工程上的安全策略有几个层级。第一层是权限最小化：给Agent只开它完成任务必需的权限，能读就不给写，能看指定目录就别给整盘访问。第二层是沙箱隔离：工具执行放在Docker容器、独立子进程或者云函数里，网络权限、文件系统权限都做限制。第三层是行为白名单：明确列出“可以调用哪些工具、不可以调用哪些工具”，这个约束要写死在代码里，不能指望模型靠提示词自觉。第四层是执行前确认：对删除、发送、支付这一类高影响操作，强制走人工审批或二次校验。

我在项目里见过最典型的事故，是Agent拿到了一个带写权限的数据库账号，在生成SQL时把一张业务表清空了。从那以后我定了一条铁律：Agent能做什么、不能做什么，必须在系统层面硬编码，任何“请小心一点”的提示词都是无效约束。另外，审计日志一定要留：每一次工具调用、谁触发的、传了什么参数、返回了什么结果，全量记录。出了问题能追溯，这比什么都重要。

3. 七个决策点：从想法到能跑的 Agent，中间隔着这些选择

3.1 决策一：模型选型，别只看通用能力，要看工具调用稳不稳

很多人在第一步就纠结选哪个模型。我的建议是：通用能力当然是基础，但Agent场景最重要的是“工具调用”和“指令遵循”能力。什么是工具调用能力？就是模型能不能稳定的输出符合Schema的JSON格式，能不能在对话中准确判断“此刻应该调工具”，能不能在拿到工具返回值后正确理解并继续下一步。

实测下来，不同模型在这方面的差距比想象中大。某些通用对话模型聊天很强，但一让它输出结构化的函数调用参数就会漏字段或者格式错乱；有些旗舰模型在函数调用上更稳，但成本和延迟也上去了。选型的时候我建议做一组专门的“Agent压测”，设计几十个工具调用场景，统计成功率、格式错误率、平均延迟和Token消耗，用数据说话，而不是看谁的聊天效果好。私有化部署场景还有一层考虑：开源权重模型能不能在你的硬件上流畅跑，工具调用能力打不打折，都需要提前验证。

顺带说一句，模型能力迭代太快，“该用哪个模型”是一个动态问题。最稳妥的工程做法是在Agent框架里把模型调用层抽象出来，支持随时替换，别把模型写死在业务代码里。

3.2 决策二：工具协议，Function Calling、MCP 还是自建协议

工具调用得有个协议，就像两个人协作得有个沟通格式。当前主流的方案有两类：一类是模型厂商自带的Function Calling格式，比如OpenAI风格的工具调用；另一类是标准化协议MCP（Model Context Protocol），它把工具的能力描述、调用接口、认证方式都规范成一个统一标准。

如果只是内部系统自己用，工具数量就几个，直接用Function Calling最省事，模型厂商把解析和编排都做好了，你不用自己折腾。但如果你要接入的工具有很多个，或者希望Agent生态里的工具能被复用，那MCP是更合适的选择。MCP的价值在于“一次接好，到处能用”，它把工具封装成统一接口，Agent只需要按MCP协议去发现和调用工具，不需要为每个工具单独写适配代码。

还有个经常被问到的问题是：能不能完全自建协议？能，但我不建议小团队这么做。自建协议看起来灵活，实际上你要处理参数校验、错误码规范、鉴权透传、超时重试，这些坑MCP和Function Calling都已经替你趟过了。我的建议是：先用厂商原生的Function Calling跑通闭环，当工具数量超过十几个、需要生态互操作的时候再逐步迁移到MCP。

3.3 决策三：编排框架，LangGraph、Dify、CrewAI 怎么选

框架选择是大家问得最多的，热搜里就有“agent框架如LangChain、Dify、CrewAI等哪个好”。这类问题没有标准答案，关键看你的使用场景和团队构成。

我的选型逻辑是这样的：如果你要做一个长期的、复杂的Agent产品，里面有很多自定义逻辑、状态切换和异常分支，我推荐LangGraph。它把Agent流程当成一张图来管理，节点之间的状态流转看得很清楚，调试和扩展都方便。如果你是要给业务部门快速搭一个能用的工具，团队里没有太多专业开发者，Dify的可视化编排会顺手得多。CrewAI适合做“多个Agent角色协作”的原型验证，但真要上生产，你还是要考虑底层状态控制能hold住多大规模。

还有一个选择是先不用框架，手写循环。我自己带新手入门Agent，通常建议先手写一个最小循环，走通之后再上框架。原因很简单：框架封装了很多东西，你直接上手容易“会用了但不懂为什么”，出了问题完全不知道从哪里排查。先把裸循环跑明白，再去看框架，你会瞬间明白框架里每个抽象是在解决什么问题。热词里“agent harness”说的其实就是这一层控制逻辑：Agent外围那套循环、状态、资源限制和生命周期管理，就是你手写时最先接触的那部分。

3.4 决策四：状态管理，Agent 不能丢三落四

状态管理是Agent工程里非常容易被低估的一环。一个长任务Agent的执行过程是：拿到目标、做计划、调工具、看结果、再决定下一步。这个过程中每一环都有状态，模型的执行状态、工具的返回状态、计划的完成状态、上下文的累积状态。如果你不做状态管理，Agent跑着跑着就会“断片”。

工程上的做法是给Agent定义一套State Schema，把关键状态结构化存起来。最简单的版本是下面这样的结构：

{ "task_id": "20240512-001", "goal": "重构用户模块", "plan": [], "current_step": 3, "completed_steps": [1, 2], "tool_history": [], "last_result": "success" }

这套状态有三个用途。第一是支持失败恢复：进程崩了、API超时、网络断开，只要状态还在，重新拉起Agent就能从current_step继续跑，不用整锅重来。第二是支持并发控制：多个Agent任务同时执行时，状态隔离是基本前提，不然任务A的上下文污染任务B，会出现“串戏”。第三是支持审计和计费：状态记录里存Token消耗和执行时长，项目复盘和成本核算都有据可查。把状态管理做好，你的Agent才能从“能跑”升级到“能稳定跑”。

3.5 决策五：记忆存储，什么时候用向量库，什么时候用 KV

前面聊七要素的时候讲了三层记忆，这里把它落到存储选型上。很多人的惯性思维是“记忆=向量数据库”，这是不对的。向量库适合存“需要语义检索”的内容，比如文档片段、聊天记录，根据语义相似度召回。但有些记忆用KV存储更合适，比如用户的偏好设置、上一次任务的执行状态、某个场景下固定的决策规则，这些都是精确键值，直接按Key取就行，硬塞向量库反而复杂。

我常用的组合是：短期工作记忆放上下文，长期语义记忆放向量库，结构化执行记忆和用户偏好放Redis或PostgreSQL。这里补充一个容易踩的坑：往向量库写入数据的时候，一定要带上metadata，至少要包含来源、时间、任务ID。不然检索出来的内容你都不知道是哪个任务、什么时候写进去的，上下文会越来越糊。另一个关于记忆的工程建议是：要给记忆做“遗忘机制”。不是所有信息都值得长期保存，定期清理过期内容、对旧记忆做摘要压缩，能显著减少上下文注入时的Token开销，也能避免过时信息误导Agent。

3.6 决策六：可观测性，没有日志的 Agent 根本没法调

我接触过好几个项目，Agent跑出错误结果，第一反应是“换模型”，第二反应是“调提示词”。但症结根本不在那里。模型推理是黑盒，但只要你的Agent工程有日志，型行为是可观测的。可观测性做不好，Agent就是一台没有仪表盘的发动机，你只能看到它跑，不知道它哪儿过热。

日志设计至少要覆盖四个层面。第一层是模型调用日志：每次请求发出去的消息序列、模型返回的内容、Token消耗，全记。第二层是工具调用日志：哪个工具被调了、参数是什么、返回了什么、耗时多久。第三层是状态转移日志：Agent从哪个步骤跳到了哪个步骤，为什么跳，是正常流转还是被异常打断。第四层是错误日志：重试了几次、什么原因导致重试、最终是成功还是放弃。有了这四层日志，排查问题的时候你就能按图索骥。

很多Agent卡死的问题，看日志一眼就能定位：工具返回格式异常、模型一直没有输出终止信号、循环不知道停止条件。热词里“agent execution terminated due to error”这类错误，本质就是某一步执行抛了异常，没有优雅降级，整个循环被中断。如果日志做好了，你会看到异常发生在哪一次工具调用上，而不是对着一个错误提示干瞪眼。

3.7 决策七：部署形态与沙箱，给 Agent 戴上镣铐再放出去

最后一个决策点是部署，很多人等代码写完了才想这事，这是不合适的。Agent和普通后端服务最大的区别在于：它会主动执行动作，而且执行结果不可完全预测。所以部署形态必须考虑“放出去之后怎么兜底”。

常见的部署形态有三种：在线Agent服务，跑在API网关后面，通过任务队列接收用户请求，适合客服助手、运营助手这类实时交互场景；批量Agent任务，按定时器触发，处理日报生成、报表分析、批量分发这类离线任务；桌面端/本地Agent，像Hermes这类常驻个人电脑，读写本地文件、管理笔记和知识库，这种形态更强调资源占用和本地安全边界。

沙箱是部署里最关键的环节。工具执行最好放在独立沙箱里，比如Docker容器，这样Agent就算模型犯傻、工具写坏了，它破坏的也只是容器内部环境。容器里做好网络白名单，数据库连接只授权必要的账号，文件系统只挂载必要的目录。整套做下来，Agent的能力边界才是可控的。我见过有些团队把Agent服务直接部署在生产服务器上，还给了root权限，这就等于把一把没有保险栓的枪交给了一个随机行为模型。听话的Agent不需要你时刻盯着，但失控的Agent必须被沙箱拦在笼子里，这是原则问题。

4. 手写一个最小可用 Agent：ReAct 循环从零跑通

4.1 最小闭环的核心数据结构与代码骨架

理论讲再多，不如直接跑一个最小闭环。下面这个例子用OpenAI风格的Function Calling实现了一个极简ReAct循环，麻雀虽小，但“模型、工具注册、循环、状态”四件套都有了。

import json from openai import OpenAI client = OpenAI(api_key="YOUR_API_KEY") TOOLS = [ { "type": "function", "function": { "name": "search_web", "description": "用关键词搜索网页，返回相关摘要。当需要最新信息、用户提到某件事但你没有把握时使用。", "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "搜索关键词"} }, "required": ["query"], }, }, }, { "type": "function", "function": { "name": "read_file", "description": "读取当前工作目录下的文本文件。处理代码项目或文档任务时使用。", "parameters": { "type": "object", "properties": { "path": {"type": "string", "description": "文件路径"} }, "required": ["path"], }, }, }, ] def execute_tool(name: str, args: dict): if name == "search_web": return {"result": "这是模拟搜索结果，关键词：" + args.get("query", "")} if name == "read_file": return {"result": "这是模拟文件内容，路径：" + args.get("path", "")} return {"error": "unknown tool"} def run_agent(user_task: str, max_iterations: int = 5): messages = [ {"role": "system", "content": "你是一个任务执行Agent。你的工作方式：分析任务、调用可用工具、观察结果，最终给用户一个完整回答。"}, {"role": "user", "content": user_task}, ] for i in range(max_iterations): resp = client.chat.completions.create( model="gpt-4o", messages=messages, tools=TOOLS, ) msg = resp.choices[0].message if msg.tool_calls: messages.append(msg) for tc in msg.tool_calls: args = json.loads(tc.function.arguments or "{}") result = execute_tool(tc.function.name, args) messages.append({ "role": "tool", "tool_call_id": tc.id, "content": json.dumps(result, ensure_ascii=False), }) else: return msg.content raise TimeoutError("Agent reached max iterations") if __name__ == "__main__": print(run_agent("帮我搜索AI Agent的最新架构，然后读取本地README.md做一个总结"))

这段代码有几个细节值得看。工具描述那两段话不是随便写的，我特意加上了“什么时候该用”的提示，这会直接影响模型调用工具的正确率。循环上限设置为5次，防止Agent陷入无限循环。角色消息也做了约束，告诉模型它的工作方式，这就是Agent的“目标要素”在代码里的最小形态。

4.2 执行细节：工具注册表、异常捕获和循环上限

上面的骨架跑通了，但要让它更健壮，还得补几个关键细节。第一是工具注册表要独立出来，不要像示例里散落在TOOLS列表和execute_tool函数里。用字典结构注册“工具名→处理函数”，然后自动生成JSON Schema，这样加一个新工具的成本就是写一个函数加一行注册。

第二是异常捕获一定要放在循环里面，不能放在循环外面。工具执行是易错点：网络超时、参数不合法、返回数据解析失败都常见。我的做法是在execute_tool外面包一层wrapper，捕获所有异常，把错误信息转成结构化返回给模型，让模型决定“是修正参数重试，还是换一个策略”。这样循环就不会被一个异常直接打死，Agent才有“临场应变”的能力。

第三是循环上限的设置在真实项目里要根据任务复杂度动态配置。简单问答可能两三次循环就结束了，复杂的代码任务可能要跑几十轮。上限设太死，任务完成不了；设太宽，模型可能在错误方向上空转，白白消耗Token。我通常在上限之外还会加一个“连续失败次数”的阈值，比如连续三次工具调用都没有产生有效进展就直接终止，把控制权交回人工。这些看起来琐碎的细节，才是Agent能不能稳定跑的真正分水岭。

4.3 从最小闭环到生产级：还差哪几块拼图

跑通最小闭环之后，对照七要素再回头看看，你会发现它缺的东西一目了然。记忆要素在骨架里只用了上下文窗口，生产环境要补上向量库和KV存储；安全治理要素完全没有，工具执行没有沙箱，也没有审计日志；状态管理也缺失，tasks执行一半进程挂了就丢了。

所以从最小闭环到生产级，我的经验是分三步走。第一步补状态管理，把计划、当前步骤、工具历史结构化存起来，这是后续一切能力的地基。第二步补记忆和知识，接上向量库和检索逻辑，让Agent能在长任务里不迷路。第三步补安全和可观测性，上沙箱、上日志、上权限控制，让Agent从实验玩具变成可信赖的任务执行者。每一步都有一个明确目标，比一上来就套一个重框架稳妥得多。我反复跟团队强调的核心认知是：框架解决的是通用问题，你自己的Agent解决的是特定问题，搞清楚两者的边界，你的架构才是健康的。

5. 常见问题与排查技巧实录：先看这几张表，能少走很多弯路

5.1 高频问题速查表

下面这些问题是Agent项目里出现频率最高的，我按“现象—可能原因—排查思路”整理成了速查表，方便你对着排查。

5.2 RPC 报错这类“非模型问题”怎么查

网上经常有人遇到类似“agent rpc error (-1): empty sid and service name”的报错，一看就懵，以为是Agent逻辑写错了。我的建议是先把这类报错分类：它大概率不是模型问题，也不是提示词问题，而是你底层的执行服务、任务网关、或者工具服务之间的RPC调用出了问题。报错信息里“empty sid”翻译过来就是“会话标识是空的”，说明你的服务在调用远程工具时，没有正确传递或创建会话ID。

排查思路分三步。先看链路：是哪个服务调哪个服务报的错，打开日志定位到具体调用方和被调方。再看会话初始化：检查RPC请求里session ID是不是真的存在，是不是在某个异步分支里漏传了，或者网关在负载均衡时把上下文丢了。最后看配置：服务注册中心的路由是否正常，服务名是否匹配，超时和重试参数是否合理。这类错误本质上是分布式系统的问题，别一头扎进提示词里去调Agent，先确认底层的调用链路是通的，Agent的循环才有可能正常。我建议所有Agent项目从第一天就统一打好服务调用的日志和链路追踪，不然后期排查这类问题会非常痛苦。

5.3 几条保命的实操纪律

最后分享几条我在实际项目里反复踩坑后定下来的纪律，你可以当成检查清单用。

第一，先跑通流程再谈优化。很多团队一上来就研究该上LangGraph还是Dify，该用哪种记忆策略，结果连最基础的“模型能不能稳定调工具”都没验证。先用最笨的代码把闭环跑通，验证业务逻辑成立，再逐步引入框架和复杂架构。

第二，日志先行。Agent代码还没写完整，先设计好日志格式。每次模型调用、工具执行、状态转移都有记录，后面调试能省下成倍的时间。

第三，给Agent设预算。不光是Token预算，还包括执行次数预算、单次工具超时时间、单任务总耗时上限。没有预算的Agent就像一个没有额度上限的信用卡，你永远不知道月底要还多少。

第四，安全约束硬编码。不要相信任何提示词层面的“请你小心”，Agent的权限边界、可调用工具白名单、敏感操作审批流程，全部写成代码逻辑。

第五，建立回归测试集。Agent项目改动频率高，今天调好的效果可能明天就被新功能破坏了。准备一组覆盖核心场景的回归用例，每次改完框架或模型都跑一遍，能避免很多“莫名其妙变差”的问题。

最后说点我在实操里越来越强烈的体会：做Agent，本质上是在做一个“带自主权的系统”，而带自主权的系统最大的工程挑战不是让模型变聪明，而是让系统在模型不聪明的时候仍然可控。七要素是能力清单，帮你理解Agent需要什么；七个决策点是选型指南，帮你决定怎么落地。两套框架合在一起，Agent工程也就没那么玄了。如果你正在写自己的第一个Agent，就拿上一节那几十行代码动手试试，跑通了，你对这篇文章里所有概念的理解都会深一层。