AgentSpace智能体构建实战：从最小闭环到工具调用与记忆规划

最近在做一个内部知识库问答工具，试了一圈智能体框架，最后在 AgentSpace 上停了下来，把整套流程跑通之后，最大的感受是：构建智能体这件事，难点从来不是“调用大模型”，而是怎么把模型、工具、记忆和流程这四样东西拧成一股绳。第25章用 AgentSpace 构建智能体的内容，刚好把这条主线讲得很清楚。这篇文章我打算换个视角聊，不按章节复述，而是把它当一份实操笔记来写——从最小闭环开始，到一个能自主调用工具、带记忆和多步骤规划的智能体，把每一步的原理、代码和踩坑记录都摊开来说。适合刚接触 AgentSpace 的开发者，也适合已经在用但被“跑不通、不可控、不好调”折磨过的朋友。

1. AgentSpace 能做什么：先搞懂智能体设计的底层逻辑

1.1 智能体的“最小闭环”：感知-决策-行动-反馈

我说过很多次，构建智能体最忌讳一上来就写代码。你得先理解 AgentSpace 到底在帮你做什么。它本质上不是一个“模型封装库”，而是一套让智能体跑起来的运行时框架。一个智能体要真正解决任务，必须有一个闭环：感知输入、基于已有状态做决策、调用工具采取行动、根据行动结果更新状态，然后再回到决策环节，直到任务完成。

这个闭环和我们人类处理事务的逻辑几乎一模一样。举个例子，你让一个实习生去查客户的订单状态，他会先看工单内容（感知），决定去订单系统里搜（决策），打开页面输入订单号（行动），看到结果后判断客户问的是不是这个问题（反馈），如果信息够了就回复，不够就继续查物流渠道（下一个循环）。AgentSpace 就是把这一套流程抽象成了可控的程序结构，让模型充当“决策大脑”，让工具充当“手脚”，让记忆充当“工作笔记”。

很多人一开始觉得这套机制没什么特别，但实际跑起来才会发现，反馈这一环才是整个闭环的灵魂。如果缺少对工具执行结果的解析和回写，Agent 很快就会“自说自话”：模型以为调用工具成功了，实际却拿到一个异常结果，然后继续基于错误信息瞎编。AgentSpace 的循环里，工具执行结果必须显式地追加回上下文，模型才能看到真实状态。这套设计本质上是在逼着开发者把“反馈”当一等公民对待。

1.2 AgentSpace 与传统任务脚本的本质差异

传统程序处理任务，靠的是开发者预先写好的 if-else 分支。比如“如果订单号为空，提示用户输入；如果订单查询失败，返回错误”，这种逻辑对确定性问题没毛病，但一旦任务形态多变，分支就会爆炸，维护成本高到你怀疑人生。AgentSpace 的思路是把“决策”这一环交给模型，开发者只需要定义好工具和边界，模型会在运行时动态决定调用哪个工具、按什么顺序调用。

这个差异带来的直接好处是：一个 Agent 可以覆盖大量以前需要写几十个接口才能覆盖的长尾场景。以我的客服场景为例，以前“查订单”“查物流”“算退款金额”各是一套代码，现在只需要给 Agent 注册三个工具，再用一句系统提示词说明“先查订单再查物流，最后判断是否需要退款流程”，它就能自己编排路径。坏处也很明显，模型决策有概率性，所以 AgentSpace 里每一步都不是“一定正确”，而是“大概率正确”，这就倒逼开发者把反馈、校验、重试机制做扎实。

换个角度理解：传统脚本像是刻好轨道的火车，永远沿着铁轨走；AgentSpace 构建的智能体更像是配了导航的司机，目的地和路况规则给定，具体怎么走它自己判断。这也是为什么我强烈建议新手先摒弃“把所有逻辑写进提示词”的冲动，踏踏实实把工具定义清楚，把 AgentSpace 的执行循环理解透。

1.3 适用场景与选型边界

AgentSpace 不是万能的，我吃了不少亏才总结出它的边界。它特别适合四类场景：一是客服类任务，用户问题千变万化，但底层工具只有十几个；二是数据查询与分析，比如“帮我拉一下上周的销售数据并按渠道汇总”，Agent 可以自动把自然语言翻译成查询并整理结果；三是内部知识库问答，结合检索工具回答文档相关的问题；四是自动化测试和运维操作，让 Agent 根据失败信息自动定位、重试甚至执行回滚脚本。

不适合的场景也要拎清楚。如果你的任务链路完全固定、参数有限，比如一个计算器接口、一个固定格式的报表生成，直接用普通代码更稳、更快、更便宜。再比如高并发、毫秒级响应的在线服务，AgentSpace 这种模型驱动的循环天然不适合挂在请求链路上，模型推理延迟和成本都不允许。我的经验是：把 AgentSpace 用在“人机交互”层，而不是“系统内部调用”层，这个边界守住了，架构基本不会出大乱子。

2. 环境准备与基础概念：动手前先想明白这几个关键对象

2.1 安装与最小项目结构

AgentSpace 的安装很常规，基于 Python 3.10+ 环境，一行命令就能拉起来。我习惯先建虚拟环境再装，避免把系统 Python 环境搞乱。最小项目结构一般这么组织：

agent_demo/ agent.py # 构建并运行 Agent 的入口 tools.py # 注册工具的地方 memory_store.py # 记忆存储配置 config.py # 模型、温度、步数等参数

这种结构不是 AgentSpace 强制的，但按“入口、工具、记忆、配置”来拆分，后面调试会轻松很多。尤其是工具文件独立出去，等你从 3 个工具扩展到 30 个工具的时候，就知道这个决定有多明智。AgentSpace 启动时会读取配置文件里的模型参数，如果本机有 OpenAI 兼容的 API 或本地模型服务，直接填 base_url 和 api_key 就能跑通。

安装完成之后有一个我很喜欢的细节，就是它的诊断命令。执行agentspace doctor时会自动检查模型连通性、工具装饰器是否注册成功、记忆存储是否可写，这个检查能帮你省掉大量“第一个 Agent 跑不起来”的排查时间。我第一次接触时没看文档直接写代码，结果一直报工具找不到，后来才发现是 Python 模块导入路径写错了，工具根本没有被加载进来。

2.2 Agent、Tool、Memory 三条主线

AgentSpace 里有三个你必须搞懂的核心对象，理解了它们，整个框架就通了。

Agent 是决策主体，你可以把它理解为“一个拥有大脑的员工”。它持有模型连接、系统提示词、可用工具列表、记忆实例和执行参数。每当你调用 agent.run()，实际上就是启动了一次“思考-行动-观察”的循环。Agent 本身不保存长期业务状态，它更像一个无状态的调度器，真正的状态要么在上下文中，要么在 Memory 里。

Tool 是智能体的“手脚”。在 AgentSpace 里，工具就是一个被 @tool 装饰的普通函数，框架会自动读取函数的签名、参数类型和文档字符串，生成给模型看的工具描述。这个设计很聪明，你不需要单独写 JSON Schema，把 Python 函数写清楚，框架就能对着函数签名构建出模型需要的参数结构。但请注意，函数名和 docstring 是模型理解工具用途的关键，命名含糊、注释缺失的工具，模型基本不会调用。

Memory 是智能体的“工作笔记和档案柜”。短期记忆就是当前对话上下文，AgentSpace 会自动管理；长期记忆需要显式接入，通常配合向量数据库做相似度检索。我这里有个重要提醒：Memory 不是越大越好，过长的上下文会让模型“迷失重点”，还会拉高成本。要为 Memory 设定明确的生命周期和检索范围，这个话题我在 4.1 节细说。

2.3 我踩过的第一个坑：环境隔离和状态污染

第一次用 AgentSpace 做多会话测试时，我犯了一个典型错误：把 Memory 定义成了模块级全局变量，然后开两个 Agent 实例共用同一个 Memory。结果 A 会话的用户问过的问题，在 B 会话里莫名“被想起”；更离谱的是，两个 Agent 调用同一个工具时，工具内部缓存了前一个请求的中间结果，导致数据串号。

AgentSpace 本身是支持实例级隔离的，但前提是你得正确使用它的 API。正确做法是每个用户会话创建一个独立的 Agent 实例，并为它单独挂载 Memory 存储。如果使用全局工具函数，工具内部一定不要缓存和用户相关的业务数据，工具应当是无状态的，有状态的数据全部通过参数传入。工具内部用了全局缓存导致串数据，这个问题排查起来非常隐蔽，我那次花了将近一个下午才定位到。先把这个隔离思路刻在脑子里，能帮你避开很多诡异的线上问题。

# 错误示范：多个 Agent 共享同一个 Memory shared_memory = Memory() def create_bad_agent(model_cfg): return Agent(system_prompt="...", memory=shared_memory) # 会话数据会互相串 # 正确做法：每个会话独立 Memory def create_good_agent(model_cfg, session_id): mem = Memory(session_id=session_id) return Agent(system_prompt="...", memory=mem)

3. 构建第一个可用的智能体：完整实现与逐段拆解

3.1 定义工具：让智能体真正“能动手”

工具是智能体能力的边界，工具定义的质量直接决定 Agent 能不能干成事。下面我以一个客户服务场景为例，定义两个工具：一个查订单，一个算退款金额。在 AgentSpace 里，工具本质就是一个普通函数加上注册装饰器。

from agentspace import Agent, tool @tool def get_order_status(order_id: str) -> str: """查询订单当前状态，返回订单的物流进度和签收情况。 参数 order_id 是用户在电商平台看到的订单编号， 形如 ORD20250101XXXX。 """ # 这里替换成真实的订单系统调用，demo 直接返回 mock 数据 data = { "ORD20250101ABCD": "已发货，预计 3 天后送达，物流公司：顺丰", } return data.get(order_id, "未找到该订单，请核对订单号") @tool def calculate_refund(order_id: str, reason: str) -> str: """根据订单 ID 和退款原因计算预计退款金额。 规则：未发货订单全额退款；已发货订单扣除 10 元运费； 虚拟商品一经发货不支持退款。 """ if reason == "未发货": return "预计退款：订单全额" if reason == "已发货": return "预计退款：订单金额 - 10 元运费" return "该情况不支持退款，建议转人工"

这里有个细节值得展开：函数 docstring 一定要写清楚“参数是什么格式、返回什么结构、有哪些业务规则”，因为模型真正读到的就是这段描述。你不会给一个人类同事留一张只有函数名的纸条，那也别给模型留。我见过太多人因为 docstring 写得含糊，模型反复生成错误参数，工具调用成功率直线下降。工具内部还要做好异常捕获，返回给模型的信息尽量是“能指导下一步行动”的自然语言，而不是一串堆栈异常。

3.2 组装智能体：系统提示词与工具绑定

工具准备好了，接下来就是创建 Agent。这里系统提示词的作用容易被低估。AgentSpace 里的 system prompt 不是客套话，而是在告诉模型“你是谁、手头有哪些工具、遇到什么情况该调用它们、什么情况不该调用”。我那份客服 Agent 的系统提示词大概长这样：

agent = Agent( system_prompt="""你是一位电商客服助手。 你有两个工具：get_order_status 和 calculate_refund。 用户的提问如果涉及订单查询、物流进度，必须先调用 get_order_status； 如果用户询问退款金额或退款规则，必须先调用 calculate_refund。 工具的返回结果是唯一可信信息源，不要编造订单数据。 如果工具返回"未找到该订单"，请让用户核对订单号后重试。""", tools=[get_order_status, calculate_refund], memory=Memory(session_id=session_id), )

注意看我加了“工具的返回结果是唯一可信信息源”这句，这一句是给模型套上缰绳。否则模型非常容易在工具返回“未找到该订单”之后，仍然自信地回复一段“您的订单已签收”之类的幻觉内容。说白了，系统提示词就是在给 Agent 立规矩，规矩越明确，不确定性越小。实测下来，加了三句约束之后，客服 Agent 在测试集上的胡说率从 15% 降到了 3% 左右。

3.3 运行与结果解析：执行循环到底发生了什么

调用 agent.run() 之后，内部不是只做一次模型推理就结束的，而是一个循环。第一轮，模型读到用户问题，判断“这需要查订单”，于是生成一个结构化的工具调用指令；AgentSpace 解析这个指令，找到 get_order_status 工具并执行；执行结果被追加回上下文；模型读到结果，判断信息足够，生成最终回复；循环结束。也就是说，一次 run 可能对应多次模型请求。

很多新手会在这里犯迷糊，以为 agent.run() 是同步返回最终文本，结果发现工具调用链路一长就会超时。AgentSpace 默认对每一步都有超时控制和最大步数限制，我建议第一步先把日志打开，看看模型每一轮到底输出了什么、工具返回了什么，之后再关闭日志跑生产。下面是我跑客服 Agent 时抓到的简化日志：

[1] user: 我的订单 ORD20250101ABCD 什么时候到？ [1] thought: 用户询问物流进度，需要调用 get_order_status [1] tool_call: get_order_status(order_id="ORD20250101ABCD") [1] tool_result: 已发货，预计 3 天后送达，物流公司：顺丰 [1] final: 您的订单已发货，预计 3 天后送达，承运商是顺丰。

这个日志格式就是典型的“思考-行动-观察”链条。看日志的时候你就能直观感受到 Agent 的决策过程，也能快速定位问题出在哪个环节：是模型没有正确选工具，还是工具执行报错，还是模型没有合理利用工具结果。

3.4 参数调整：温度、最大步数、超时时间怎么定

很多人在 AgentSpace 里只调模型名称，其他参数全用默认值，这种做法不太推荐。以我的经验，有几个参数值得单独针对场景调一下。

另外还有一个小技巧：AgentSpace 支持给单个工具设置“重试次数”。像查物流这种偶尔超时的接口，我会在工具装饰器上加一次重试，而不是让整个 Agent 因为工具抖动就失败。这套参数组合不是拍脑袋定的，要结合你实际跑批数据的结果来调。我第一次跑批量测试的时候，用默认温度 0.7，工具参数的乱填率接近 20%，把温度压到 0.1 之后，直接降到 2% 以下，这个对比足够说明参数的重要性。

4. 进阶：让智能体真正“靠谱”的五个关键机制

4.1 记忆管理：短期与长期记忆的配合

构建完第一个能跑通的 Agent，下一步就是让它“记住事儿”。短期记忆在 AgentSpace 里很简单，就是一次 run 内或者一个会话内保存的上下文，框架会自动拼接。真正考验人的是长期记忆：跨会话保存用户偏好、历史订单、业务规则，在对话开始时自动检索并注入上下文。

长期记忆的落地姿势一般是：先把重要信息写入向量库，等下次用户发起会话时，AgentSpace 根据当前输入做相似度检索，召回 top_k 条相关记忆，塞进 system prompt。我实际做客服场景时，会给每个用户单独建一个记忆空间，存储他常问的问题类型、历史订单编号、售后进度。这样用户再来咨询时，Agent 不需要重复询问订单号，体验会好很多。

但长期记忆也有坑。最典型的是上下文污染：你检索回来的 5 条记忆里，可能只有 2 条和当前问题相关，其余 3 条纯属干扰，模型反而被带偏。我的做法是先做一轮“记忆过滤”：召回之后用一个轻量规则或模型判断相关度，只保留置信度高的记忆。还有一个成本问题，记忆塞得越多，单次请求的 token 就越高。我给记忆条目设置了 200 字的上限，超出就做摘要压缩，这个策略在成本和准确率之间找到了平衡点。

4.2 任务分解与规划：从“问一句答一句”到“自主干活”

如果你的智能体只做单轮问答，那 3.2 的配置已经够了。但 AgentSpace 的进阶价值在于支持复杂任务分解。它内置了一个 Planner 机制，可以把一个模糊的大目标拆成有序的子任务。我做过的一个典型例子是“生成季度销售报告并发送邮件”，如果直接丢给 Agent 做，模型很容易漏掉“先汇总数据再写结论”的步骤。用 Planner 先拆解之后，Agent 的执行路径会清晰很多。

from agentspace import PlannerAgent planner_agent = PlannerAgent( system_prompt="你是数据分析助手，负责把任务拆解为可执行的步骤。", tools=[query_sales_data, generate_chart, send_email], plan_strategy="sequential", # 按顺序执行 ) result = planner_agent.run("生成上个季度的销售报告，包含各渠道柱状图，发送给 manager@example.com")

执行时 Planner 会先输出一个步骤清单，再一步步执行，每完成一步就更新清单进度。这样做的好处是，用户等结果时能看到进度，而不是干等一个大模型响应；某个环节失败时也能准确定位，不会整个任务从头再来。需要注意的是，任务分解不是每一步都非要模型推理，像“查询数据”这种确定操作应该走工具；“决定图表类型”“判断结论优先级”才交给模型判断。把推理用在刀刃上，成本和延时都会友好很多。

4.3 多智能体协作：编排方式与适用性

AgentSpace 支持多智能体协作，最常见的两种模式是 supervisor 模式和 pipeline 模式。Supervisor 模式里有一个“主管”Agent 负责分发任务给多个“专员”Agent，自己汇总结果做最终判断；Pipeline 模式则是把任务按阶段串联，前面的 Agent 输出直接作为后面的 Agent 输入。

我在一个自动化周报项目里试过这两种模式。最初用 supervisor 模式，让一个主管 Agent 同时协调数据收集、图表生成、文字总结三个专员，理论上很美好，实际跑起来却发现频繁出现上下文超长和步骤冲突。后来改成 pipeline 模式，数据收集 Agent 先跑完，产出 JSON 文件；图表 Agent 读文件出图；总结 Agent 读图表标题和关键数字写文字。每个阶段边界清晰，出问题只需要替换对应阶段的 Agent，调试难度直线下降。

但我得说句实在话，多智能体不是越多越好。每一个 Agent 都会增加一层模型调用的延迟和成本，也会引入新的失误点。我在实际项目里超过七成的需求，用“单 Agent + 多工具 + Planner”就能解决。多智能体适合的问题，往往是你已经能清晰地划分专业领域边界、且每个领域需要完全不同的提示词和工具集。否则，一段复杂的 system prompt 配上精确定义的十几个工具，比拆成七个相互协作的 Agent 要稳定得多，也更便宜。

4.4 可观测性与日志：没有日志，调试就是灾难

智能体项目上线后，最让人头疼的问题不是“功能没实现”，而是“运行了但结果不对，且不知道为什么不对”。模型是概率性的，同样的输入可能因为上下文细微变化就输出不同路径，没有日志，你连复现问题都做不到。AgentSpace 提供了比较完善的可观测接口，我在项目里会做三件事：第一，记录每一轮模型调用的完整输入和输出；第二，记录工具执行的入参、出参、耗时和错误信息；第三，记录每次会话的系统提示词版本和模型版本。

推荐在项目里加一个 JSON Lines 日志文件，每一轮循环追加一条记录，字段包括会话 ID、时间戳、agent_id、step 编号、事件类型（thought/tool_call/tool_result/final）、token 用量、耗时。这样后续排查时，可以直接用 grep 按会话 ID 拉出整条链路日志。我分享一个真实案例：有一次客服 Agent 在特定提问下重复调用退款工具，用户没收到退款但系统提示“退款成功”。排查日志才发现，是系统提示词里没有说明“退款执行结果必须二次确认”，模型把“工具返回成功”等同于“用户已经收到钱”。日志链路上清清楚楚，改一行系统提示词就解决了。

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

5.1 智能体陷入死循环怎么办

工具型智能体最常见的故障就是死循环：模型一遍遍调用工具，每次工具返回的信息都不能让它做出“结束”的判断，然后一直转圈，既消耗 token 又拖垮响应速度。我在 AgentSpace 里遇到过两次严重的死循环，一次是工具返回的订单状态字段有变化，但提示词没有告诉模型“什么状态代表可以结束”，于是它反复查询确认；另一次是工具返回了错误码，模型尝试重试，但错误码始终没消除，它就一直重试。

解决方向有三个。第一个好办，设置 max_steps 上限，但这只是止损，不是根治。第二个是改提示词，明确列出“结束条件”，比如“如果订单状态为已签收，可以直接结束回复用户”。第三个是给工具加幂等和状态检测：重复调用同一参数的工具时，直接返回“已经查过该订单，状态未变化，请勿重复查询”。实操下来，提示词加上结束条件是最有效的。另外，AgentSpace 的日志里能看到 step 数，你可以在达到第四步时主动给模型追加一条提醒：“你已调用多次工具，请尽快基于已有信息结束任务”，这种软性干预很管用。

5.2 工具调用一直失败：参数格式和异常捕获

模型生成的工具调用参数偶尔会脱离工具函数定义的 schema，比如字符串传成数字、必填字段缺失。AgentSpace 有参数校验机制，但校验失败默认只是把错误信息返回给模型，模型有时候会换一种错误姿势继续试。更稳妥的做法是在工具函数内部再把一道关。

@tool def get_order_status(order_id: str) -> str: """查询订单当前状态。""" if not order_id or len(order_id) < 10: return "订单号格式不正确，请让用户提供完整的 ORD 开头订单号" try: result = query_order_api(order_id) return result except Exception as e: return f"订单查询接口异常，原因：{e}。请告知用户稍后重试"

这里的关键是异常返回值一定要用自然语言描述清楚，并且尽量包含“下一步建议”。模型读到“请让用户提供完整的 ORD 开头订单号”，比读到“KeyError: order_id”更容易修正自己的行为。还有一点容易被忽视：工具函数的返回字符串长度也要控制。如果工具返回一坨几万字的原始数据，模型会抓不住重点。我在工具内会先做摘要，只返回最关键的状态、时间和结论，详细数据写到临时文件或数据库里，需要时再让模型用另一个工具去取。

5.3 输出不稳定：如何用约束和校验兜底

如果你希望 Agent 输出结构化内容（比如 JSON）给下游系统用，直接让它“自然语言输出 JSON”是不够的。模型偶尔会在 JSON 前后加解释文字，或者多一个逗号，下游解析直接爆掉。AgentSpace 提供了输出 Schema 校验能力，相当于给模型的输出套了一个格式边界，不符合格式就自动触发重试或修正。

from agentspace import OutputSchema order_schema = OutputSchema( type="object", properties={ "order_id": {"type": "string"}, "status": {"type": "string"}, "eta_days": {"type": "integer"}, }, required=["order_id", "status"], ) agent = Agent( system_prompt="...", tools=[get_order_status], output_schema=order_schema, )

我之前做一个自动生成订单摘要的模块，没有加 Schema 校验前，20% 的返回结果没法直接解析；加上校验并配置一次自动重试之后，成功率拉到 96%，剩下的 4% 是模型连续两次都过不了格式关，直接返回“生成失败”，由上游服务兜底处理。这个思路的核心是不要指望模型每次都完美，而是用机制去兜底。

5.4 性能与成本调优：缓存、并发与模型选型

最后聊一个老板比较关心的话题：成本和性能。AgentSpace 跑一个复杂任务可能调用模型多次，token 消耗比单次问答高出一个量级。我的优化优先级排序是：先缓存、再换模型、最后考虑并发。

缓存的位置可以放两层。一是工具结果缓存：同一会话内，相同参数的订单查询直接返回上次结果，不重复调接口。二是完整请求缓存：对于业务上允许短时滞的查询，用“用户问题+工具列表”做 key，命中缓存就直接返回历史答案，不再调模型。这个策略在我的知识库场景里节省了大约 40% 的模型调用。

第二件事是模型分级。不是所有步骤都需要最强模型。AgentSpace 支持为 Agent 配置多个模型品牌，我经常把“意图识别、工具选择”用中等模型，把“最终总结、复杂推理”用强模型，简单分类直接用规则或小模型。这样平均成本能降一半，延迟也会有明显改善。特别提醒一下，模型切换不要影响提示词一致性，每次改动都跑一遍回归测试，否则很容易出现“换模型以后工具调用率骤降”这类问题。

第三件事是并发控制。AgentSpace 跑多会话任务时，模型 API 的限流很容易被打爆。我建议在应用层做信号量限流，单模型实例控制在 5~10 个并发，具体数值压测决定。宁可让请求排队，也不要把 API 打挂导致全站不可用。

在实际迭代中，我发现一个很值得坚持的原则：先把闭环跑通，再谈优化。很多团队一上来就铺多 Agent、上向量库、加各种缓存，结果连最基础的工具调用链路都不稳，后面排查问题时根本分不清是框架问题、提示词问题还是基础设施问题。我在 AgentSpace 里的推进路径很固定：先用最简单的方式跑通一个端到端任务，看日志确认每一步都没有意外，然后逐步加记忆、加规划、加校验。每一步只改一个变量，这样任何一次效果变差，你都能立刻知道是谁的锅。

最后再分享一个小技巧：工具定义里除了写清楚参数和返回规则，还可以写一条“使用注意”，比如“该工具查询耗时较长，请在必要时才调用”。模型会真的读到这句话，并减少不必要的工具调用。这个小细节是我在一次成本优化时偶然发现的，后来在多个项目里都验证有效。构建智能体这件事，说到底是不断给模型减少不确定性的过程——工具清晰一点、反馈明确一点、边界划定一点，Agent 就会靠谱一大截。