企业官网建设流程全解析

1. 从提示词到行为控制：这个转变到底意味着什么

先说结论：如果你的工作还停留在“写 Prompt”阶段，那你的 Agent 开发大概率会遇到瓶颈。我这两年做过不少 Agent 项目，最开始也和很多人一样，觉得 Agent 就是“大模型 + 一段精心设计的提示词”，只要把 prompt 写得足够详细，模型就能按预期工作。直到踩过几次大坑——Agent 在复杂任务里失控、死循环、瞎编、越权操作——我才意识到，真正的 Agent 提示词工程，本质上是在设计一套行为控制系统，而不是单纯在写一段“输入输出说明书”。

这个词不是我发明的，而是我自己在项目复盘时总结出来的。所谓“行为控制系统”，指的是围绕大模型构建的一套约束、反馈、分工、容错机制。Prompt 只是这个系统的“宪法”，但光有宪法远远不够，你还需要流程控制、记忆管理、工具权限、异常处理等配套机制，才能让 Agent 稳定地完成目标行为。

很多人会把 Agent 和普通 ChatBot 混为一谈，这是最大的误区。ChatBot 的 prompt 是“对话风格控制”，Agent 的 prompt 是“行为逻辑控制”。ChatBot 只需要回答得好，Agent 却要做得好——这意味着它要能拆解任务、调用工具、感知环境状态、从错误中恢复。两者的复杂度不在一个量级。

这篇文章就是想把我在 Agent 提示词工程这条路上的完整方法论拿出来分享，不管你是在做客服智能体、自动化工作流，还是研究多 Agent 协作框架，这套思路都能直接套用。我会从最核心的编排模式讲起，再到 prompt 的具体结构、上下文管理、错误恢复、记忆设计，最后给一份可以直接用的避坑清单。保证你看完能从“写得一手好 prompt”升级成“能设计一套稳定的行为控制方案”。

说白了，Prompt 工程的第一性原理是：你不是在跟模型对话，你是在给一个“员工”写岗位职责说明书、SOP 和白名单。想清楚这层，你的 Agent 才算是真正入了门。

2. 核心编排：提示词在 Agent 行为控制里的角色

2.1 为什么“单一超长 Prompt”撑不起 Agent 行为控制

我在早期做 Agent 时，最喜欢干的事就是把所有规则塞进一个超长 prompt 里。任务拆解步骤、工具使用说明、输出格式、注意事项，恨不得写个 3000 字。结果模型经常“忘事”——不是它真的忘了，而是超长上下文里信息相互干扰，关键约束被淹没。后面我才悟到，Agent 的行为控制不能靠“一段话”，要靠“一套编排”。

这是我在大量 Agent 项目里反复验证过的结论。拆开来看，一个完整的 Agent 行为控制系统至少包含四层：

• 角色与目标层：定义 Agent 是谁、要完成什么目标、遵循什么价值观。
• 流程控制层：定义任务拆解方式、执行顺序、决策分支、终止条件。
• 工具与权限层：定义能调用哪些工具、调用时有什么限制、哪些动作绝对禁止。
• 反馈与学习层：定义如何从结果中得到反馈、出错后如何修正、记忆如何更新。

这样的分层，本质上和公司管理一样：老板（用户）定目标和方向，经理（编排框架）拆任务和盯进度，员工（模型）执行具体动作，HR 制度（反馈机制）确保员工不跑偏。如果只给员工一份超长岗位说明书而不做过程管理，他很快就会在复杂任务中迷失。

我常常用一个很生活化的类比：把 Prompt 想成“宪法”，但一个国家光有宪法是不能运转的，还得有具体的法律、执法流程、监督机制。同理，你的 Agent 也要有“法律”层面（具体 Tool Prompt）、“执法”层面（Agent Loop）、“监督”层面（安全审核）。“写 Prompt”只是立宪，而“设计行为控制系统”是立国。

2.2 三种编排模式的取舍：Plan-and-Execute、ReAct、反射式工作流

在 Agent 提示词工程里，最核心的选择题是——用哪种编排模式来管控 Agent 的行为。我实际用下来，主流就是三种，各有各的适用场景。

Plan-and-Execute（先计划后执行）：把“想”和“做”分离。Agent 拿到任务后，先把完整计划写出来，比如步骤一、步骤二、步骤三，然后再逐步执行。这种模式最大的好处是行为可控，因为计划本身可以被人类审查、被额外校验。缺点是灵活性差，如果中间出现意外，整个计划可能作废。

ReAct（Reasoning and Acting）：把“思考”和“行动”交替进行，模型每思考一步，就行动一步，看到结果再接着想下一步。这种模式灵活很多，特别适合任务路径不明确的场景。缺点是容易陷入死循环——模型反复“思考 → 行动 → 思考”，就是不收敛。所以我一般会在 System Prompt 里明确“连续失败 3 次必须切换策略”之类的硬约束。

反射式工作流（Reflexion）：在任务过程中把过往的错误总结成反思笔记，供后续行为参考。这种模式本质上是用“记忆”来修正“行为”，特别适合同类型任务反复执行的场景。比如我做的客服 Agent，每次处理完客户投诉，都会把这次对话里犯的错误总结成一条教训，存进记忆库，下次遇到同类问题就不再犯。

实际项目里，我不会只用一种模式，而是做混合编排：外层用 Plan-and-Execute 做任务拆解，内层用 ReAct 做单步执行，再用反射机制把错误教训沉淀进记忆。这三层组合起来，就是一套很完整的行为控制系统。你如果刚起步，我建议从 Plan-and-Execute 开始，因为行为最可控，等业务跑顺了再逐步加灵活性。

2.3 单 Agent 与多 Agent 协作的编排差异

单 Agent 的场景相对简单：一个模型实例，一套 prompt，一个任务目标。多 Agent 协作则完全换了一副面孔——你得面对任务分配、通信协议、信息共享、冲突仲裁这些问题。我最初做多 Agent 时，就是让两个 Agent 共享同一个 prompt 模版，结果它们互相不知道怎么配合，任务做得一塌糊涂。

后来我把 prompt 按角色拆分：导演 Agent（负责任务拆解和进度跟踪）、执行 Agent（负责具体操作）、审查 Agent（负责检查输出质量）。每个 Agent 的 prompt 都要明确写出“你是谁、你从哪里拿输入、你往哪里送输出、你遇到问题找谁”。

这里有个关键细节：多 Agent 的 prompt 之间要有明确的接口约定。比如导演 Agent 的输出格式必须包含“任务编号、执行者、目标、验收标准”，执行 Agent 的输入解析就依赖这个格式。接口一旦混乱，整个系统就崩了。你可以在单个工区内先手动模拟多 Agent 协作，跑通了再上框架。

3. 系统提示词与上下文工程：行为控制的两根支柱

3.1 System Prompt 的结构化写法：岗位说明书式设计

如果说 Prompt 是“宪法”，那 System Prompt 就是宪法里“总纲”那一部分。很多人的 System Prompt 只是一段描述性格的话，但对于 Agent 行为控制来说，它应该是一个结构严谨的“岗位说明书”。我在写 System Prompt 时，遵循五个模块：

• 角色定义：你是谁？你的专业领域是什么？你服务的对象是谁？
• 目标声明：你存在的目的是什么？你衡量成功的标准是什么？
• 行为准则：你要遵循什么原则？什么事情绝对不能做？
• 能力边界：你能做什么？不能做什么？工具范围是什么？
• 输出规范：你应该以什么格式输出？输出要包含哪些信息？

举一个我做客服 Agent 时的实际例子。System Prompt 里角色定义是“资深客户服务专员”，目标声明是“在保证用户满意度的前提下高效解决用户问题”，行为准则是“不能编造订单信息、不能承诺无法执行的售后政策、对待用户情绪要同理心优先”，能力边界是“只能查询订单状态、修改物流偏好、提交退货申请”，输出规范是“每次回复必须包含处理结果、下一步动作、预计时间”。

这样一写，模型就会被“束缚”在可控的行为边界内。你会发现，它不再随心所欲地回答，而是像一个经过培训的员工一样，走标准流程。更重要的是，当模型面对一个超出能力边界的请求时，它会因为 System Prompt 里明确写了“不能做什么”，而主动拒绝或转人工，而不是瞎编一个答案。这就是行为控制真正的力量。

我见过很多人写 System Prompt 只写“你是一个友好的助手”，这叫对话风格设置，不叫 Agent 行为控制。如果你想做一个能稳定执行任务的 Agent，这套结构化写法是第一步。

3.2 上下文工程的三个关键动作：压缩、检索、注入

其实 Agent 跑起来以后，System Prompt 反而不是最常改的，真正的瓶颈在上下文管理。你给模型喂多少上下文、喂什么格式的上下文、怎么在长任务中保持上下文不膨胀，这些都直接影响行为控制的稳定性。我把上下文工程拆成三个关键动作：

压缩：Agent 执行任务过程中会积累大量中间结果、工具返回、历史对话。如果不压缩，上下文迟早溢出。我常用的策略是把中间结果做摘要化处理——不是把全文塞给模型，而是把“关键事实 + 当前状态 + 未完成事项”提取出来。比如执行一个网页抓取任务，抓了 100 条数据，我不会把 100 条全部放回上下文，而是先让模型生成一个结构化摘要，只保留有效信息和待处理项。

检索：RAG 是 Agent 记忆的重要补充。但我想强调的是，Agent 里的检索和普通问答里的检索不一样——它要服务于当前行为决策。比如用户问“我的订单什么时候到”，Agent 不是去检索一段百科知识，而是去检索用户订单状态、物流轨迹、售后政策这三类数据。所以检索的关键是“检索什么”而不是“检索多全”。我会在 Prompt 里明确定义“当你想知道 X 时，你应该查 Y 数据源”。

注入：有时候模型缺少的是关键知识或实时数据，这时候需要主动把外部信息注入上下文。注入要注意格式化和时效性——我一般会把外部数据转成 JSON 或表格，让模型能快速解析。另外，注入的信息要带时间戳，防止模型把旧信息当新信息用。

这三个动作背后有一个共同逻辑：上下文不是无限仓库，而是“工作台”。你往工作台上放什么，模型就越会围绕什么进行行为决策。放太多杂物，模型就会分心；放错了重点，模型就会做错事。上下文工程，本质上就是在精确控制“模型做决策时眼前放着什么”。

3.3 Prompt 里的“无效标记”问题：flagged 错误排查实录

做 Agent 最让人头大的错误之一，就是模型返回 invalid prompt: your prompt was flagged as potentially violating our usage p... 之类的结果。我最初遇到这个报错时一脸懵——我明明写的 prompt 是纯业务性质的，为什么会被标记为违规？后来排查下来，原因基本集中在这几类：

一是关键词触发。业务术语里有时会包含某些敏感词，比如“获取”、“攻击”、“绕过”、“隐私”等，即使词义完全中性，也会被内容审核系统误判。二是指令注入。如果你的 Tool Prompt 里包含“忽略之前的指令”“现在执行……”这类字眼，审核模型会认为你试图穿透安全边界。三是越权动作描述，如果你的 Prompt 里暗示了模型不应该做的操作，也会被标记。

面对这类问题，我的排查思路是三步：先看是哪一层触发的（System Prompt、User Prompt 还是 Tool 返回），隔离测试；再用同义词替换敏感关键词，保持原意；最后给被标记的指令加上“仅在用户授权场景下执行”这类限定词，降低误判概率。实测下来，只要把这三个动作做到位，绝大多数 flagged 问题都能解决。

我还有个习惯：所有 Agent 的 prompt 都会过一遍“自问自答”——我会问自己：“这段 prompt 如果被一个严格的审核者看到，它会不会觉得我想做坏事？”如果有一点可疑，我就主动改掉。别等到上线了才被审核系统打回来，提前自查是一种职业素养。

4. Agent 开发中的关键技能：安全、记忆与工具控制

4.1 Agent 安全设计的核心原则：最小权限与白名单思维

做 Agent 行为控制，绕不开一个话题：安全。这不仅是网络安全意义上，更是行为安全意义上。一个 Agent 如果没有做好行为约束，它可能“好心办坏事”——比如客服 Agent 为了安抚用户，擅自承诺了公司政策不允许的赔偿。这种问题单靠 prompt 正面引导是防不住的，必须做防护机制。

我的核心原则是“白名单思维”和“最小权限”。白名单思维很简单：模型可以做白名单里的事，其他的一律不许做。比如我的 Agent 能调用 5 个工具，那 System Prompt 里就明确标注“你的可用工具只有 A、B、C、D、E”，任何不在列表里的请求一律拒绝。最小权限则是：在能完成任务的最小范围内，尽可能减少模型可调用的资源和可执行的操作。

更进阶一点，我会用安全 Agent（审查 Agent）对执行 Agent 的输出做二次校验。执行 Agent 调用工具后，产出可能有问题，审查 Agent 负责核查“这个输出是否符合行为准则、有没有越权、有没有编造”。这在多 Agent 架构里是一个非常有效的安全网。你可能觉得多一道审查会拖慢速度，但实测下来，审查带来的稳定性提升远大于速度损耗。

4.2 Agent 记忆框架选型：从短期上下文到长期向量记忆

Agent 的记忆是行为控制系统里最能拉开差距的部分。我见过的 Agent 项目，十有八九是“一次性执行力强、连续性差”——换个话题或者隔几天再跑，之前的经验全丢了。原因很简单：大家只关注了 prompt 和上下文，忽视了记忆框架的设计。

记忆分三层：

• 会话记忆：单次任务内的上下文，基于模型自带的上下文窗口，通常会做摘要压缩。
• 工作记忆：跨步骤执行时的状态缓存，比如任务进度、中间结果、当前决策。
• 长期记忆：跨会话的经验沉淀，一般基于向量数据库存储，通过语义相似度检索取回。

选型上，我的判断标准是：记忆框架不是越复杂越好，而是越匹配你的任务模式越好。如果你的 Agent 每次任务都从零开始，只需要会话记忆就够；如果你的 Agent 需要处理用户历史偏好，那必须上长期记忆；如果你的 Agent 要跟用户连续聊一周，那工作记忆和长期记忆都得做，并且要做分层管理。

我常用的长期记忆方案是：把重要的交互经验、用户偏好、领域知识向量化后存入向量数据库，每次任务开始前，根据当前任务描述召回 Top-K 条相关记忆，注入到 prompt 上下文里。这样做能让 Agent 表现出“越用越懂你”的效果，而不是每次都是第一次见面。

4.3 Agent 框架与编排工具选型：手写 Loop 还是用框架

做 Agent 工程时，另一个关键选择是：底层编排是自己写 Agent Loop，还是直接用开源的 Agent 框架。这两个方案我都试过，各有优劣。

手写 Loop 的好处是完全可控：你能精确控制每一步的推理、行动、反馈，也能针对业务做深度定制。缺点很明显：开发量大、边界情况多，尤其是重试机制、上下文管理、状态维护这些，写起来很容易漏。而直接用框架，比如 LangGraph、CrewAI、AutoGen 这类，能让你快速搭建起标准流程，社区生态也帮你踩了很多坑。但框架有一个天然的劣势——它是通用的，如果你要做高度自定义的行为控制，框架默认的 prompt 和流程往往不够精细，你得学会“改框架”而不只是“用框架”。

我的建议是：早期项目用框架，跑通后再考虑手写关键环节。先用框架把流程捋顺，把业务验证清楚，然后当你发现框架成了瓶颈，再针对具体环节手写替换。我自己的项目就是这么演进的：早期用框架做 MVP，后期把决策循环改成自己写的 ReAct Loop，稳定性反而更好。

4.4 Agent 排查技巧：execution terminated 类错误的定位思路

Agent 开发有个高频报错，就是 agent execution terminated due to error. 我最早看到这个错误时非常慌，后来才明白，这种“终止”错误通常不是单一故障，而是系统对某个异常状态的“兜底反应”。排查思路我总结成四步：

• 第一步：看日志，定位是“模型层”还是“工具层”还是“流程层”出错。
• 第二步：逐层缩小范围，可以先把 Tool 调用注释掉，只跑模型层推理，看是否正常。
• 第三步：检查是否有提示词注入或输出格式不匹配问题，这是 Agent 框架里最常见的“隐形炸弹”。
• 第四步：查看上下文是否过于冗长或混乱，必要时做压缩或重试。

这四个步骤看起来简单，但实际排查时非常管用。我之前有个 Agent 每次跑到第 5 步必挂，最后定位到是某个 Tool 返回的结果格式和下游解析逻辑不匹配，而不是模型本身的问题。所以我要特别强调：遇到 execution terminated，先别急着改 prompt，先用二分法把故障层定位清楚。很多问题根本不是模型的问题，而是你“控制管道”的某个环节漏了。

5. 实战：从零搭建一个带行为控制的 Agent 项目

5.1 需求拆解与行为目标定义

前面讲了大量的方法论，这一节我们落到实操：如何从零开始搭建一个带行为控制系统的 Agent 项目。我用一个真实做过的案例来讲——电商客服售后退款智能体。这个 Agent 的目标非常明确：用户在咨询订单售后问题时，Agent 能自动查单、判责、给出退款处理方案，并且在能力范围外时转人工。

我在动手前，会先拆解需求，输出三张卡片：

• 用户故事：用户在“我的订单”里发起退款申请，Agent 需要判断是否符合条件、计算退款金额、告知退款时效。
• 行为目标：准确判定退款资格；不承诺超出政策的赔偿；无人工介入时也能完成标准退款流程；无法判定时主动转人工。
• 边界条件：不处理超过售后周期的订单；不处理金额大于 500 元的申请（需人工）；不修改订单物流信息。

这三张卡片本质上是把业务规则翻译成了 Agent 行为控制的需求。没有这一步，你后面写的 prompt 就会很虚，模型根本不知道自己要实现什么。我强烈建议，所有 Agent 项目开始之前，先把这三张卡片写出来——它就是你整个系统的“合同文本”。

5.2 System Prompt 落地示例

需求拆解完后，我会正式落一份 System Prompt。这里贴一个经过脱敏的实际版本，你可以直接抄作业再按自己业务改：

你是“微微售后助手”，一位严谨、耐心的电商平台售后专员。 目标：在合法合规的政策范围内，高效解决用户的退款、退货、换货类问题。 行为准则： 1. 只依据系统返回的订单信息进行判断，不得编造订单状态或金额。 2. 售后政策优先级：平台通用政策 > 商家自定义政策 > 客服经验判断。 3. 当订单状态不支持退款，或用户诉求超出当前权限，必须转接人工客服。 4. 任何话术不得承诺“一定退款”“马上到账”等绝对性表述。 能力边界： - 可调用工具：查询订单、查询售后政策、提交退款申请、修改退款地址。 - 不可调用工具：订单删除、赔偿金发放、优惠券创建。 - 当用户提出边界外需求，应回复“这个需求我需要转人工协助处理”。 输出规范： - 每次回复必须包含：处理结果、政策依据、下一步动作、预计时间（如适用）。 - 若需要用户补充信息，一次只问一个问题，避免信息轰炸。

这份 Prompt 看起来不长，但它涵盖了前面讲过的五个模块：角色、目标、行为准则、能力边界、输出规范。关键是，它把“什么能做、什么不能做”写得清清楚楚，这比单纯让模型“友好一点”有效得多。当模型面对模糊请求时，它会被 Prompt 里的“边界外需求转人工”拽回来，而不是自由发挥。

5.3 工具链接入与权限配置

Prompt 定了，就要接入工具链。我的工具接入流程是三步：

• 第一步，定义工具清单。比如“查询订单”这个工具，需要传入订单号，返回订单状态、商品清单、金额；“提交退款申请”这个工具，需要传入订单号、退款原因，返回申请结果和预计到账时间。
• 第二步，给每个工具写 Tool Prompt。Tool Prompt 的作用，是让模型知道“这个工具是干什么的、怎么用、参数是什么、会返回什么”。写 Tool Prompt 时我会特别注意：不要写太长，突出参数和返回格式即可，否则模型容易被冗余信息带偏。
• 第三步，配置权限边界。这一步是安全控制的核心。我在代码层会给每个工具打上“权限标签”，比如“可自动执行”“需人工确认”“禁止调用”。对于那些有一定风险的操作，比如提交退款申请，我会在代码层面要求 Agent 先输出一个“操作确认预览”，等用户确认后才真正执行。

特别是在脆弱场景下，工具权限配置比 Prompt 本身更能决定 Agent 的可靠性。你可以想象，如果模型只有“查询”权限，它最多泄露点数据；但如果模型有“写入”权限，它就能造成真实损失。所以设计 Agent 时，我问自己的第一个问题永远是：它最坏情况下能做多少破坏？答案直接决定我的权限池怎么设计。

5.4 测试与调优：从 70 分到 95 分的迭代路径

Agent 发布前，我一定会做一轮系统测试，而不是只靠几个示例对话来验证。我自己的测试矩阵包括五个方面：流程覆盖测试（所有正常流程是否跑通）、异常注入测试（故意输入模糊、超权限、恶意指令，看 Agent 是否守住边界）、目标漂移测试（让它执行一个长期任务，看它是否偏离初始目标）、工具故障测试（模拟某个工具返回异常，看 Agent 是否能恢复）、多轮一致性测试（同一问题换不同问法，看它是否回答一致）。

第一次测试下来，Agent 往往只有 70 分——某些流程能跑通，但边界防守时松时紧。这时候我开始“目标靶心式调优”：不是全盘改 prompt，而是先定位分数最低的测试项，针对性地改。比如异常注入测试得分低，我会在 System Prompt 里加强“不可调用工具”的描述，并在代码层加一道硬校验，双管齐下。迭代几轮后，分数基本能稳定到 95 分以上。

调优过程中，我最大的经验是：别在一轮里改太多变量。一次只改一个维度，跑一轮测试，记录变化。如果多个点一起改，出了问题你根本不知道是哪个改动引起的。这跟调试普通软件是一样的逻辑，只不过调试对象从一个函数变成了一个智能体系统。

6. 常见问题与避坑清单

6.1 高频问题排查速查表

我把这个领域最常见的坑整理成了一张表，你可以直接当速查手册用：

这张表的价值在于，它把所有问题都收敛到了“行为控制系统的四个层级”上——角色、流程、工具、反馈。当你遇到问题，先用这张表定位层级，再去改对应层级的配置，而不是盲目调整 prompt 措辞。这条经验，是我无数次在深夜 Debug 中换来的。

6.2 新手最容易踩的三个隐形坑

除了上面那张表，我还想特别提三个新手几乎必踩的隐形坑，因为它们不会直接报错，但会悄悄拉低你的 Agent 质量。

第一个坑是**“过度设计 Prompt”**。一开始我把所有东西都写进 prompt，结果模型反而频繁误判，因为信息太多、优先级不清。后来我做减法：把最重要的行为准则放在 prompt 前三分之一，辅助信息放后面，效果立竿见影。Prompt 是“说明书”，不是“百科全书”，你要让模型一眼就能抓到最重要的约束。

第二个坑是**“忽略输出格式校验”**。Agent 框架里，模型输出通常是结构化 JSON，如果格式不匹配，系统就会把它当成无效结果。我见过太多人只检查 prompt 正确，却从不校验输出格式，导致 Agent 在线上莫名其妙跑不动。现在我在所有 Agent 后面都加一层“输出解析与重试机制”，格式不对就自动重试一次，成功率能提升不少。

第三个坑是**“没有做 Agent 监控”**。上线的 Agent 不是一劳永逸的，业务规则在变、用户提问方式在变、模型版本在变。如果不监控 Agent 的失败率、人工转接率、超时率，出了问题根本发现不了。我的做法是给 Agent 加一套“行为日志”系统，记录每一次任务的输入、输出、决策路径、终止原因，定期复盘，看有没有行为异常。没有日志，就没有改进的依据；没有监控，就没有安全感。

6.3 关于内容安全与合规的底线经验

最后想严肃聊一个问题：Agent 提示词工程必须把内容安全和合规放在第一优先级。很多人只关注功能实现，忽略了 Agent 的输出可能是公开的、面向真实用户的，一旦越界，后果不是“多跑一个报错”能比的。

我的底线经验有这么几条：

• 所有 Prompt 中不包含任何诱导模型突破安全边界的指令，不写“绕过”“隐藏”“忽略规则”这类词汇。
• Agent 的可执行动作必须受限，绝不开放无法追踪的危险操作。
• 所有决策和操作必须可审计，保留完整日志，方便事后追溯。
• 当不确定某项操作是否合规时，默认拒绝，并转人工处理。

而且我特别强调一条：不要把安全设计当成“上线前最后一步”，这会极大抬高返工成本。我见过一个团队，Agent 逻辑全做完了才补安全校验，结果发现底层工具权限设计根本不符合安全模型，推倒重来，浪费了三周时间。安全应该从需求拆解那一步就参与进来，跟功能同步设计，两条腿走路，才能走稳。

在做 Agent 提示词工程这几年，我最大的体会是：你的产出物不应该叫“提示词”，而应该叫“一套行为控制系统”。当你用系统的视角去看待它，不懂的地方自然就会浮现出来——工具该收多紧、上下文该放什么、失败该怎么恢复、记忆该怎么沉淀。想明白这些，你的 Agent 就不再是一个容易失控的“对话玩具”，而是一个真正能交付业务价值的“数字员工”。

如果你正卡在“写 Prompt”阶段，不妨先跳出来，试着把问题换成：“我怎么设计一套系统，让模型稳定地表现出我想要的长期行为？”思路换了，做法自然就换了。