1. 先别急着写代码：Agent 到底是什么
这两年做 AI 应用开发，没被 Agent 这个词轰炸过的人应该不多。从各种白皮书到个人开发者的玩具项目，大家都在谈 Agent，但真被问一句“你项目里的 Agent 到底怎么实现的”，能讲清楚的人反而不多。我自己的感受是，大部分人对 Agent 的理解停留在“能自己干活的大模型”这个层面，真落到工程上就抓瞎了。
我打算换个思路来聊这件事：先把 Agent 拆成零件，再把工程实现拆成决策点。零件就是所谓的七要素，决策点就是你在做技术选型和架构设计时绕不开的七个岔路口。把这两层东西理清楚，Agent 对你来说就不再是黑盒了。
先说结论：Agent 本质上不是一个全新的技术，它是大模型能力的“外接扩展”。大模型本身只会做一件事——根据输入预测下一个 token。它坐在那里，你问它答，你不问它不动。而 Agent 干的活，是给这个“问答机器”配上目标、工具、记忆和执行循环，让它从一个被动的对话系统，变成一个能主动推进任务的执行体。
所以别再被各种酷炫的 Demo 唬住，Agent 的工程实现，归根结底就是在回答几个朴素问题：它怎么理解目标？它怎么拆解任务？它调用什么工具？它怎么记住上下文？它怎么知道自己做完了？这背后每一步都是一堆工程细节，也就是我要说的决策点。
2. 拆掉 Agent 的七个要素
七要素这个提法有很多版本，有的叫法不一样，但核心内容基本趋同。我自己在项目里复盘过多次，最顺手的划分是七个：大模型底座、规划、记忆、工具、行动、感知、协作。你可以把它们理解成一个人干活时需要具备的能力——有脑子、会想办法、记得住事、有手有脚、知道外界发生了什么、知道怎么跟人配合。
这七个要素不是独立存在的，它们在一次完整的任务执行里是串成一条线的。后面我会逐个说明，但建议你先记住这条主线：模型是底座，感知负责从环境拿信息，规划负责想怎么做，工具和行动负责真正去做，记忆负责把过程串起来，协作负责扩展单体的能力边界。
2.1 大模型：整个 Agent 的“大脑皮层”
大模型在 Agent 里的角色经常被低估。很多人以为它就是被调用的 API，其实它是整个 Agent 的“调度中枢”——几乎所有决策和判断都靠它完成。你得先想清楚一件事：你用的这个模型，推理能力够不够，上下文长度够不够，指令遵循能力强不强。
我在早期项目里犯过一个典型错误：用一个小参数模型去做 Agent 的规划模块，结果模型根本理解不了复杂的工具调用指令，经常凭空捏造工具参数。后来换成了更强的模型，问题立刻消失大半。所以我可以给你一个直接的建议：Agent 的规划核心，尽量别省模型的钱，这是整个系统里最不应该抠成本的地方。另外，上下文长度直接影响 Agent 能“记住”多少过程信息。之前我们做长链路任务，一个任务跑下来中间信息特别多，如果模型的上下文短，就只能不断压缩历史，效果打折非常明显。
大模型的另一层作用被很多人忽视，就是它以 token 为载体的输入输出，本质上决定了 Agent 每一步的“思维长度”。你给它多少空间去思考，它就能想多细。这也是为什么有的 Agent 产品要做“思维链优化”（也就是让模型在推理时不急着输出结果、先输出中间推理过程），因为这能显著提升复杂任务的准确率。
2.2 规划：从目标到行动的拆解
规划就是让 Agent 把一个大目标拆成一小串可执行的步骤。很多人第一次接触这个概念时会觉得：“这不就是让模型写个 TodoList 吗？”对，但不完全对。写列表只是第一步，工程上的规划远比这复杂。
规划模块要解决三个问题：第一，这个任务需不需要拆？有些任务一步就能完成，比如查个天气，你让 Agent 拆成五步反而浪费 token。第二，按什么逻辑拆？是顺序执行、并行执行，还是带条件分支？这里要用到类似状态机的机制来控制流程。第三，拆完以后如果某一步失败了，是整个任务重来，还是只重试这一步？
我自己常用的规划模式有三种。第一种是 ReAct，也就是“推理—行动—观察”循环，模型每一步先想再干，看到结果再想下一步，这种模式特别适合工具调用密集的场景。第二种是 Plan-and-Execute，先一次性生成完整的计划，然后按计划逐步执行，适合那些步骤明确、不太需要中途调整的任务。第三种是 Reflection（反思），Agent 执行完一轮以后，自己审视结果，发现问题再改进，适合写代码、写文案这类需要反复打磨的任务。三种模式不是互斥的，实际项目里经常组合用。
2.3 记忆：短期工作台与长期仓库
记忆这个东西，如果用一个不恰当的比喻，你可以把它当成 Agent 的“数据库”，但这样理解就太窄了。工程上我更愿意把记忆分成两层：短期记忆和长期记忆。
短期记忆其实就是当前任务上下文。它存在于模型的上下文窗口里，包含用户目标、中间结果、已执行的动作。它的实现方式和模型选择直接相关，上下文长就多存点，短就得精打细算。常见的工程手段是“滑动窗口”——只保留最近 N 轮的关键信息，把更早的内容压缩成摘要塞回上下文里。
长期记忆则是跨任务的持久化信息。它可以存用户偏好、历史任务记录、专业知识库。工程实现上，最常见的方式就是向量数据库。你把一段文字（比如产品文档、历史对话）切成小块，用 embedding 模型转成向量存起来，等需要时再按相关性检索回来，拼进当前上下文。这就是 RAG（检索增强生成）的核心思路。但你一定要小心：长期记忆不是存进去就万事大吉，存什么、怎么切、怎么更新、怎么避免过期信息污染新任务，这些都得做设计。
2.4 工具：让 Agent 真正动手干活的“手脚”
没有工具的 Agent，就像只有脑子没有手的人。工具的本质是什么？是把模型输出的结构化意图，映射到真实世界的可执行操作上。比如模型说“我要查一下北京的天气”，工具系统就把它变成一个真实的天气 API 调用。
工程上，工具层要做的事可以拆成三块：第一，定义工具的能力边界，也就是一个工具能干什么、输入输出是什么；第二，把工具列表暴露给模型，让模型知道有哪些工具可选；第三，执行工具调用，并把真实结果回传给模型。
这里想提醒一个非常容易踩的坑：工具描述写得太含糊。模型判断用哪个工具、填什么参数，完全依赖工具的描述文字。你用“check_weather(city)”这种格式，模型大概率能懂，但如果你写“get_weather_info_by_city_name(param: str)”，模型可能就要犹豫。工具的描述、参数名、参数说明，都要写得非常清楚，这直接决定工具调用的成功率。我做过一个小实验，仅仅把工具描述从一句话扩展到三句话带示例，调用准确率就从 70% 出头提升到 90% 以上。这个投入产出比相当可观。
2.5 行动：从“想”到“做”的临门一脚
规划产生了动作指令，工具系统负责执行，但行动这个环节强调的是“执行结果怎么处理”。模型输出了一段 JSON，说“调用函数 A，参数是 X、Y”，你的系统真的去调用了吗？调用成功了吗？返回结果是什么？这些就是行动层要管的。
行动层的工程实现有几种风格。最传统的是“函数调用”，OpenAI 最早推的 Function Calling 就是这个路子，模型输出结构化的函数名和参数，代码侧按 schema 执行。另一种是让模型直接输出可执行代码（比如 Python），你的系统用沙箱跑这段代码。后者灵活度更高，但风险也更大——代码注入、资源耗尽这些问题需要额外的安全措施。再一种是把行动封装成 HTTP 请求，Agent 通过 API 网关调用外部服务，这种方式最干净、最容易做权限管控，也是企业落地时最常见的选择。
我自己的习惯是：能用函数调用解决的就用函数调用，别动不动让模型写代码。模型写代码虽然灵活，但调试成本、安全成本都不低。真实业务里 80% 的工具调用，用标准化的函数调用都能覆盖。
2.6 感知：Agent 怎么知道外界发生了什么
感知这个词听起来很玄，其实干的事很具体：Agent 从环境里拿信息，用来支撑下一步决策。最基础的感知就是工具返回的结果——你调用天气 API 返回了下雨，Agent“感知”到了，于是决定提醒用户带伞。更高级一点的感知包括读取网页内容、解析 PDF、监听用户新输入、甚至是多模态的图片/语音输入。
工程上，感知层最重要的是一件事：把外部信息转换成模型能理解且不“超载”的格式。比如你让 Agent 读取一个网页，直接把整个 HTML 丢给模型，模型会被大量噪音干扰。如果先做正文提取、清理、摘要，再喂给模型，效果会好得多。感知到的信息还要做“可追溯”处理，也就是这个信息来自哪个页面、哪个时间段，这些元信息得存下来，否则 Agent 引用了错误信息，你还查不到源头。
2.7 协作：当一个 Agent 不够用的时候
单一 Agent 能做的事是有天花板的。一个模型在一个上下文里同时处理规划、记忆、工具调用，一旦任务复杂，上下文就会膨胀，工具选择就会混乱。这时候多 Agent 架构就派上用场了：让多个 Agent 各管一段，有的负责拆解任务，有的负责具体执行，有的负责审查结果。
多 Agent 不是简单的“多调几次模型”，而是要设计 Agent 之间的通信协议、任务分配机制、结果汇总方式。工程实现上，主流的做法是编排式，有一个“主管 Agent”统一调度，把任务分给下面的“专家 Agent”；也有极端的自由式，让 Agent 们通过消息互相协作，但这种模式下结果不可控，我一般不建议在正经项目里用。
3. 工程实现的七个决策点
零件拆完了，现在进入正题：你真要动手做一个 Agent，会遇到哪些决策？
这七个决策点，是我在多个项目里反复踩坑后总结出来的。按顺序分别是：框架选型、模型选型与调用方式、Prompt 与工具 Schema 设计、记忆落库与检索方案、规划循环控制、可观测性与调试、性能成本与安全。每一个决策点都不是孤立的技术选型，它会影响后续所有环节。所以建议你把它当成一张决策清单，在项目启动时逐个过一遍。
3.1 决策点一：框架选型，从 LangChain 到自研
框架选型是所有人都会遇到的第一个岔路口。市面上主流的框架我基本都试过：LangChain、LlamaIndex、CrewAI、AutoGen，还有最近越来越多的基于 Rust 的高性能运行时时，比如有些团队用 Rust 做 Agent 执行引擎来降低延迟。选框架之前，先想清楚一个问题：你要的是“快速搭 Demo 验证想法”，还是“做一个要长期维护、深度定制的产品“。
如果是前者，选一个成熟的框架完全可以，它能帮你把工具调用、记忆、Agent 循环这些事串起来，让你半天就能跑通流程。但如果是后者，我给你的建议可能会让你意外：框架用可以，但别重度依赖。原因是 Agent 的工程实现高度个性化——你的业务工具五花八门，你的记忆策略千差万别，通用框架的抽象层往往会“帮倒忙”，让你在调试时无从下手。
我个人的做法是“混合式”：用框架管理比较标准的交互流程，但 Agent 的核心循环、记忆读写、工具注册这些关键模块，写成薄薄的自研层。这样既保留了框架的便利，又不至于被框架绑死。如果你从零开始完全自研，其实也没那么可怕，一个最简单的 Agent 循环核心代码就几十行，难的是把它做成稳定的生产系统。
3.2 决策点二：模型选型与调用方式
第二个决策点直接决定 Agent 的智商上限，也决定成本下限。模型选型不是“哪个强用哪个”，而是要综合看四个维度：推理能力、上下文长度、延迟、成本。
推理能力决定它能不能正确使用工具、能不能做复杂规划；上下文长度决定短期记忆的容量；延迟影响用户体验——如果一个任务需要三步推理才能完成，而每步要等 3 秒，用户会疯掉；成本就不用多说了，Agent 的每次任务可能会消耗几万甚至几十万 token，不是聊天那种“问一句答一句”的量级。
调用方式也是要决策的：你直接调云端 API，还是自己部署开源模型？在 Agent 场景里，我倾向于优先用云端大模型 API 来跑核心规划逻辑，因为规划和工具调用对模型要求很高，开源模型在这些方面还有明显差距。但如果你对数据隐私有硬性要求，或者拥有 GPU 资源，也可以考虑混合架构：核心规划用强模型，一些“边角料”任务（比如摘要、分类）用小型本地模型，这样能在成本和效果之间取一个平衡。
3.3 决策点三：Prompt 与工具 Schema 设计
Prompt 工程在 Agent 里比在普通聊天里重要得多，因为你写的不是一句指令，而是一整套“操作系统说明书”——Agent 要在这个系统里完成目标、选择工具、处理错误、决定是否停止。
我自己写 Agent Prompt 时，一定会包含以下部分：人设与能力边界、目标与输出格式、可使用的工具列表及使用规则、执行步骤的通用指导、异常处理策略、停止条件。每一部分都有讲究。比如“停止条件”写不清楚，Agent 就会在任务完成后继续“自由发挥”，浪费 token 还容易出错。
工具 Schema 设计是我反复强调的部分。给模型看到的工具描述，和给你团队看的技术文档，完全是两码事。每个工具的描述，至少要说清楚：这个工具是干什么的，什么场景下用，每个参数是什么意思，参数格式是什么样的，有没有什么注意事项。别嫌麻烦，这块细节做得好，后面调试省一半力气。
3.4 决策点四：记忆落库与检索方案
记忆的设计直接决定 Agent 能不能应付复杂、长期的任务。你要决策的是：短期记忆怎么管理，长期记忆存到哪里，用什么方式检索。
短期记忆管理，核心是上下文压缩。我常用的方法包括：滑动窗口只保留最近几轮对话；对历史信息做摘要并替换原文；如果模型上下文足够长，也可以干脆全部保留，但成本会明显升高。长期记忆则要考虑存取介质和检索策略。向量数据库是主流方案，但不要迷信它，如果你记忆条目的结构非常明确（比如都有固定的字段），传统的关系型数据库加关键词检索可能更可靠。
另外一个容易被忽略的点是“记忆更新机制”。Agent 在与用户交互过程中，旧记忆可能需要修正。比如用户之前说“我喜欢 A 方案”，后来又说“其实我更喜欢 B 方案”，你要怎么处理两条矛盾记忆？最简单的策略是加上时间戳，检索时优先返回最近的记录，并让模型意识到记忆可能已经过期。别看这个细节小，处理不好，Agent 会“极其自信地”给出过时的建议。
3.5 决策点五：规划循环怎么控制
这个决策点，是 Agent 从“玩具”走向“生产系统”的分水岭。很多人做的 Agent 之所以不稳定，问题就出在规划循环控制上。循环是什么？就是“模型想 → 调工具 → 看结果 → 再想”这个循环。循环如果没控制好，Agent 要么停不下来，要么一步就放弃。
工程上，你需要给循环加以下几个“刹车”和“护栏”：最大迭代次数，比如最多执行 15 步，防止死循环；步骤超时控制，比如每步最长 60 秒；结果验证，比如模型说“任务完成”时要校验这个结论是不是真的合理；兜底策略，比如循环超限后，强制 Agent 把当前进展汇报给用户。这些机制在框架里往往都有对应参数，但默认值通常不适合你的场景，要按业务特点调。
还有一点，循环控制里要处理“工具的异常反馈”。工具调用失败时，返回的错误信息会被模型当作输入，如果你的错误信息写得不清不楚，模型可能会“脑补”一个错误原因，然后做出错误决策。所以工具的错误返回也要格式化设计，最好包含错误码、错误描述、可能的解决方案，让模型拿到错误后能真正理解并重试。
3.6 决策点六：可观测性与调试
Agent 的调试体验，和传统后端完全不一样。传统后端程序有明确的调用栈，报错就能定位；Agent 是模型输出驱动的，同样的输入，每次输出的推理路径可能都不一样，这让 bug 复现变得特别难。
可观测性要解决的就是这个问题。你需要把 Agent 的每一次决策都记录下来：模型输入了什么 Prompt、模型输出了什么内容、调用了哪个工具、工具返回了什么、下一步计划是什么、最终为什么停止。这种“决策轨迹”不仅方便调试，还能用来做 prompt 优化、回归测试、安全审计。
在我的项目里，日志的格式是统一的 JSON，每一条记录都带 trace_id，从用户请求到 Agent 执行的每一步，都能串成一个时间线。存储上可以直接放日志系统，也可以放到数据库里方便查询。早期开发时，我还会把这些轨迹渲染成一个可视化界面，用树状结构展示每一步的推理和动作，调试效率提升好几个量级。这块投入别省，Agent 应用上线后的维护，基本全靠它。
3.7 决策点七：性能、成本与安全
最后一个决策点，也是最容易被忽略的——一个 Demo Agent 跟一个生产 Agent 的区别，就是这三件事：性能、成本、安全。
性能方面，除了模型延迟，你要关注 Agent 的“端到端延迟”。一个 Agent 任务往往需要多次模型调用，串行执行的话，总延迟就是各步骤之和。优化手段包括：能并行的步骤就并行；提前缓存一些可复用的中间结果；对某些确定性步骤（如简单的数据格式化）不用模型，直接写代码。成本方面，因为 Agent 的 token 消耗远比聊天多，你需要给每一步加“成本预算”，并设置上限。一种常见做法是分阶段给不同的模型——简单阶段用小模型，复杂阶段用大模型。
安全这块，往大了说涉及模型输出风险、工具权限管控、数据隐私；往小了说，至少要做到：别把用户的敏感信息拼进 Prompt 里；给每个工具做最小权限授权；对 Agent 能执行的操作做白名单；对外部输入做注入防护。说句实在话，很多 Agent 项目死掉不是因为效果不好，而是因为权限太宽，一个不小心让模型执行了不该执行的操作。这部分的重视程度，怎么强调都不为过。
4. 从零搭一个 Agent：实操走一遍
决策点讲完了，光说不练没有意义。我用最简的方式，带你把一个可用的 Agent 从零搭出来。你不会看到完整框架代码，因为我故意不用重框架，让你先看到 Agent 的本质。
4.1 最小骨架：Agent 循环就这几行
一个 Agent 的核心是循环，每次循环做三步：把当前状态告诉模型、让模型决定下一步动作、执行动作并记录结果。用伪代码描述，大概是这样：
def run_agent(user_goal): # 初始化记忆和状态 messages = [{"role": "system", "content": SYSTEM_PROMPT}] messages.append({"role": "user", "content": user_goal}) for step in range(MAX_STEPS): # 1. 让模型根据当前上下文决定下一步 response = llm.chat(messages, tools=TOOL_SCHEMAS) # 2. 如果模型认为任务完成了，就退出 if response.finish_reason == "stop" and not response.tool_calls: return response.content # 3. 如果模型想调用工具，就执行工具并记录结果 if response.tool_calls: for call in response.tool_calls: result = execute_tool(call.name, call.arguments) messages.append(format_tool_result(call.id, result)) return "已达最大步数，任务未完成"看懂这个循环，你就看懂了 80% 的 Agent 框架。所谓的 LangChain Agent、自研 Agent，扒掉外壳，里面都是这个模式。区别在于各方对具体细节的封装和增强。
4.2 让 Agent 学会用工具
工具注册是给模型一份“能力清单”。我建议每个工具都提供以下五个字段：工具名、工具描述、参数结构、必需参数、示例调用。比如给 Agent 加一个“查询天气”的工具：
TOOL_SCHEMAS = [{ "type": "function", "function": { "name": "get_weather", "description": "根据城市名查询当前天气，适合用户询问天气时调用", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市中文名，例如：北京、上海、广州" } }, "required": ["city"] } } }]注意 description 的语言组织。对比一下这两种写法：“查询天气”和“根据城市名查询当前天气，适合用户询问天气时调用”，后者明显更容易让模型做出正确选择。工具描述写得好的标准，是让模型哪怕没接触过这个工具，也能在 5 秒内判断它适不适用。
4.3 加入记忆之后的变化
上面的骨架没有记忆管理，所有历史都堆在 messages 里。任务短还好，任务一长，上下文就会爆炸。所以，生产级的 Agent 一定要加记忆管理。
结合 2.3 节的记忆划分，你可以用两个简单手段升级你 Agent 的记忆能力。手段一：对超过窗口的历史做摘要替换，代码思路是把最早的 message 取出来，让模型压缩成一段摘要，再存回上下文，这样就能把上下文长度稳定在一个可控范围。手段二：长期记忆配合向量检索，用户每次交互后，把关键事实抽取出来，存到向量数据库；下一次任务启动时，先按用户目标和当前时间检索相关记忆，并把检索结果拼进系统 Prompt 或用户消息的开头。
加完记忆后，Agent 最大的变化是“连续性”变强了。它不再每次从零开始思考，而是能引用过去的对话、过去的决策。这种体验上的差距，是纯 Prompt 怎么调都补不回来的。
5. 避坑指南：Agent 落地时的常见问题与排查
最后这章，全是我自己踩过的坑，整理成问答形式，方便你遇到问题时直接查阅。
5.1 Token 为什么烧得这么快
几乎每个刚开始做 Agent 的人都会被 token 账单吓到。Agent 的 token 消耗和聊天完全不是一个量级——一次任务可能会反复调用模型，每调用一次，前面的历史还会重复计费。排查思路：先加 trace，看每一步实际消耗；再把系统 Prompt 和工具描述精简；然后对长历史做摘要压缩；最后给整个任务设一个 token 预算，超了就强制让 Agent 收尾。你还可以考虑用缓存策略，完全相同的上下文可以直接命中缓存，省掉重复计算的钱。
我见过有些团队上来就追求效果拉满，把工具 Schema 写得又多又长，上下文里堆了特别多细节，结果一次简单查询都要消耗好几万 token。我的原则是：工具数量控制在必要范围内，每个工具描述控制在 100 字以内能说清的就别写 300 字，上下文能压缩就压缩。
5.2 Agent 陷入死循环或者迟迟不结束
这是 Agent 开发里最经典的灵异现象：模型翻来覆去地调用同一个工具，或者在一个错误结果上反复重试，就是不收尾。排查时先查循环上限和超时配置是否合理，再看工具的错误返回是否提供了“新信息”——如果模型每次拿到的错误都一样，它就没有依据改变策略，只能重复同样的动作。所以，工具的错误信息里一定要带上“我这次尝试了什么、失败了、下一步该怎么办”这类信息。兜底方案也别忘了：给循环加上步数限制和超时终止，保证任何情况下 Agent 都不会无限跑下去。
5.3 工具调用格式频繁出错、参数张冠李戴
模型在调用工具时偶尔会生成不符合 Schema 的 JSON，或者把参数填错。这种问题通常有两类原因：一是模型本身能力不够，这种情况下换更强的模型立竿见影；二是你的 Schema 设计有问题，字段命名、类型、描述含糊不清，导致模型理解不了。排查策略是：先把最近 N 次失败的输出全部拉出来，看模型到底错在哪个字段，然后针对性修改工具描述，必要时在工具描述里给一个“示例调用”。很多失败，其实只要在描述里加一句“注意：参数 city 必须为中文城市名，格式参考：北京”就能解决。
5.4 效果不稳定，同一个问题两次回答不一样
Agent 天然带有随机性，但如果你觉得它“太不稳定了”，多半是系统 Prompt 缺少约束。可以给模型设定更明确的决策路径，比如“无论何时，当你决定调用工具前，必须列出理由”或者“如果结果与预期不符，必须再次确认参数”。还可以降低模型 temperature，并在 Prompt 里强调稳定输出。如果你的业务对稳定性要求极高，建议增加一层“结果校验器”：用一个规则系统或更便宜的模型，对 Agent 的最终输出做一次检查，不达标就让它重写。
5.5 框架帮倒忙：升级一个依赖，整个 Agent 行为变了
这是框架党最痛的体验。LangChain 这类框架迭代太快，Agent 的默认行为、工具调用格式、甚至 Prompt 结构都可能在大版本里默默变化，导致你的应用突然变笨了。我的建议是：核心 Agent 逻辑要跟框架解耦——不要直接用框架的 AgentExecutor 做你的最终循环，而是把框架当成“零件库”，只取你用得到的能力。同时，在升级依赖前，跑一遍你的回归测试集。没有回归测试，升级框架就是在赌运气。
最后说点我自己的体感
Agent 项目做多了，你会越来越明白一个道理：Agent 的工程实现，难的不是写出那个循环，难的是让这个循环在你的业务环境里稳定、可控、成本可接受。七要素和七个决策点，本质上是一套检查清单——写代码前过一遍，能少走很多弯路；上线后出问题，也能靠这张清单快速定位。
如果你刚开始接触 Agent，我的学习路线建议很简单：先用 Python 手写一个 50 行以内的 Agent 循环，理解本质；再读两三个框架的源码，理解封装；最后回到手写循环，按你的业务需求往里加功能。别急着追新框架，也别怕自己写核心逻辑。等你把七要素和七个决策点都亲手趟过一遍，Agent 在你的项目里就不再是“调一个模型”那么简单了，它会变成你能掌控的工程系统。
