企业官网建设流程全解析

最近一直在琢磨大语言模型的推理能力，尤其是智能体（Agent）方向的落地问题。提到Agent，就绕不开一个词：动作空间。你可以把它理解为“模型在当前状态下所有可选行为的集合”——调用哪个工具、读哪个文件、跑哪段代码、要不要搜索，都算动作。NIPS 2025上那篇关于DYNAACT的工作，标题很直白：Large Language Model Reasoning with Dynamic Action Spaces，翻译过来就是让大模型在“动态的动作空间”里完成推理。

这个方向看着学术味重，但做过Agent开发的人一眼就能get到它有多刚需。传统做法是提前把几十个工具的描述、参数、示例一次性塞进上下文，让模型自己挑。路径一长、工具一多，模型就开始“选择困难”，要么盯着一个工具反复调用，要么在无关描述里浪费大量token。DYNAACT这类思路想解决的核心问题，就是把“静态的全量动作列表”变成“按需生成、动态更新”的动作空间，让模型每一步决策都更精准、更省、更能适应新环境。

这篇文章我会从问题根源讲起，拆解动态动作空间的实现思路，再给出一套可以直接复用的搭建方案、评测维度和避坑经验。适合正在做Agent工具调用、任务规划、代码生成式交互的同学参考，也适合那些觉得“固定工具列表不够用”的开发者。

1. 项目概述：当动作空间不再一尘不变

1.1 从“固定菜单”到“动态菜单”：什么是动作空间

动作空间这个词，最早来自强化学习，指智能体在每个状态下可以选择的所有合法行为。放到LLM Agent场景里，动作空间就是“模型调用某个能力”的候选集合。比如一个客服机器人，动作空间可能是：查订单、查物流、转人工、发优惠券、记工单。一个编程助手，动作空间可能是：读文件、写文件、执行shell命令、调用编译器、运行单测。

传统实现里，这个集合通常在会话开始前就固定好了。把所有工具的描述写进系统提示词，或者做成一个Schema列表注入上下文，然后让模型在每次需要行动时，从这些预先定义好的动作里选一个执行。这套方案在工具数量少、类型稳定的时候没大问题。但一旦工具数量上到几十上百个，或者任务链路变长，模型就很容易“挑花眼”。

打个比方：固定动作空间有点像你走进一家餐厅，服务员递给你一本几十页的固定菜单，你想点个快手菜，还得先翻完前菜、汤品、主食、甜点四大板块才能做决定。而动态动作空间呢，更像一个会主动跟你说“今天的时蔬是秋葵，当日例汤是冬瓜排骨，招牌菜卖完了别点”的活人服务员——信息是跟着当下场景走的，点菜效率自然高。

1.2 这个方向到底在解决谁的痛点

我接触过不少Agent项目，凡是工具一多，痛点都出奇一致。

第一个痛点是上下文被“工具说明书”撑爆。50个工具，每个描述平均150个token，光工具列表就要吃掉7500多token，再乘上对话轮次，长任务很容易逼近模型上下文窗口上限。而且这些token大部分时候是无用信息——一个查天气的工具描述，在用户问数学题时根本用不上。

第二个痛点是模型的选择准确率会随着候选数量增加而下降。这不是玄学，是评测里反复出现的结果。候选动作越多，模型在“到底该用哪个”上的错误率就越高。尤其是两个功能相近的工具摆在一起，模型很容易选错。我见过一个任务，明明应该调用“按客户ID查询合同”，模型却选了“按合同编号查询客户”，两个工具名称仅一字之差，结果整个流程都绕错了。

第三个痛点是新动作无法在运行过程中加入。真实业务里，工具是会升级的。今天加了一个“批量导出PDF”的新接口，明天某个旧接口被废弃，如果动作空间是静态的，模型要么不知道新接口的存在，要么继续调用已废弃的老方法。动态动作空间的价值，就在于让动作列表跟着环境反馈和状态变化实时更新，而不是一开场就把所有可能性焊死。

2. DYNAACT的核心思路拆解

2.1 总体框架：把“一次看完”改成“边走边查”

DYNAACT这类方法，核心可以拆成三个环节：动作库维护、动作子集筛选、动作执行反馈。整个链路不再假设动作空间是“初始就给全”的，而是把它看成一个可以随推理过程增长的动态资源。

在动作库里，每条动作都是结构化元数据：动作名、用途描述、参数Schema、调用示例、当前状态、版本号。推理过程中，模型会根据当前观测和任务目标，先经过一道检索或筛选逻辑，从动作库里挑出最相关的少数几个候选动作，再把这些候选动作送进上下文让模型做最终选择。执行动作后，环境返回的新信息可能带来新动作——比如代码执行后返回了模块里可用的新函数，或者搜索文档中发现了一个新的API——这时动作库就要完成一次“注册新动作”的更新。

这个过程有点像一个经验丰富的工程师查手册的方式：碰到问题，先定位章节，再快速翻阅相关那段，而不是从头到尾把整本手册背一遍。动作库是那本手册，筛选逻辑就是你的目录和索引，而每个新动作的注册就像是给手册补充边页笔记。

静态动作空间和动态动作空间的整体设计差别，可以用下面这个表格快速看清楚：

2.2 动态动作空间的两类构建方式

我在实际调研和复现过程中发现，动态动作空间并不是只有一种实现路径。按动作产生的方式，大致可以分成两类：预注册型和边做边扩型。

预注册型指的是动作库在任务启动前已经建好，运行过程中只是根据当前状态做“子集筛选”。比如一个企业内部知识库助手，事先把查库存、查价格、查供应商、查物流这些接口全部登记好，推理时根据用户提问只把可能用到的三五个接口选出来。这类实现可控性好，动作质量有保障，适合业务边界清晰、动作集合相对稳定的场景。

边做边扩型则强调动作在执行过程中产生。比如模型执行一段代码，代码运行后返回了某个模块提供的函数列表，这些函数本身成为新的可选动作；或者模型访问了一个网页，网页文档里包含的动态链接和交互接口，也变成了下一轮可以调用的动作。这类方式灵活性最高，但动作质量参差不齐，需要额外的校验和过滤逻辑，否则动作库会迅速膨胀，甚至混进无用噪音。

实际生产中，大多数系统采用的是混合策略：先预置一批核心可信动作，保证基本功能可用；再让执行反馈触发动作注册逻辑，把临时的、环境生成的新动作慢慢补充进来。这样既保证了稳定性，又保留了动态扩展能力。

2.3 为什么说动态优于静态：三个维度逐一对比

既然动态方案实现起来更复杂，那到底值不值？我自己的理解是，它的收益主要体现在三个维度。

第一是推理聚焦度。模型做决策时，候选动作越多，注意力越容易被分散。动态方案通过检索把数十上百个动作缩小到五到十个，模型能更专注地比对当前任务和动作描述之间的匹配关系。这就像你去超市买洗发水，货架上50种肯定比5种更难选，不是因为你能力不够，而是选择的认知负担变大了。

第二是token效率。动态方案并不需要在每轮对话里重复注入全部动作描述，而是只携带检索出来的那部分。对于长链路任务来说，省下的token非常可观。假设每个动作描述150token，每轮只带8个动作，相比原来带50个动作，每轮能省下6300多token。在API调用成本高、上下文窗口有限的场景下，这个优势几乎是决定性的。

第三是扩展能力。固定动作空间里，模型很难知道“刚刚发现的新接口”。动态动作空间则允许任务在执行中通过观测结果扩展动作集。这意味着Agent可以适应那些“一开始无法完全预见”的环境——比如动态网页、代码运行时暴露的API、用户自定义插件等。这类场景在真实业务中越来越多，静态方案基本无解，动态方案几乎是唯一现实路径。

当然，动态不等于一定更好。筛选本身需要算力，检索不准反而可能丢掉关键动作。所以后面第三个章节要聊的，就是怎么把筛选和更新机制做好，让它真正发挥优势。

3. 实操落地：从零搭一个动态动作空间系统

3.1 动作表示：结构化的钩子才是关键

动态动作空间的第一步，是给每个动作做一份“结构化档案”。这一步做得不好，后续检索和模型选择都无从谈起。

我建议每个动作至少包含这些字段：动作名称、用途描述、参数Schema、调用示例、返回格式、适用条件、状态、版本号。其中用途描述要写成“动词开头的完整句”，比如“查询指定订单号的物流轨迹，返回物流节点列表”，不要写“物流查询”这种短语。模型对完整句的理解远好于关键词片段。

参数Schema强烈建议用JSON Schema格式，因为主流模型对这个格式的理解稳定，解析也方便。调用示例要给出一个输入到输出的完整样例，让模型能直观看出“用了它会得到什么样的结果”。

下面是一个动作档案的示例：

{ "name": "query_logistics", "description": "根据订单号查询物流轨迹，返回物流节点列表。订单号不存在时抛出异常。", "parameters": { "type": "object", "properties": { "order_id": {"type": "string", "description": "13位订单号，例如SO20250101001"} }, "required": ["order_id"] }, "example": "query_logistics(order_id='SO20250101001') -> [{'node': '已发货', 'time': '2025-01-02 10:00'}, {'node': '运输中', 'time': '2025-01-03 09:30'}]", "state": "active", "version": 1 }

注意描述里一定要写清楚边界条件，比如“订单号不存在时抛出异常”。否则模型可能误以为这个动作永远不会失败，导致后续路径出错。

3.2 动作筛选：三套策略与选型建议

动作库建好之后，核心问题就是“每一步到底把哪些动作送进上下文”。我试过三种方案，各自适用场景不同。

第一套是规则筛选。基于关键词或正则做匹配，比如任务文本里出现“物流”就把物流相关动作选出来。优点是速度快、零成本；缺点是泛化能力差，换个说法比如“我的快递到哪了”就匹配不上。规则方案适合动作总数很少、关键词明确的小项目。

第二套是embedding向量检索。先把候选动作描述用嵌入模型编码成向量，运行时把“当前观测+未完成任务目标”编码成查询向量，然后算余弦相似度取top-k。这种方法灵活性强，对语义变体有较好的容忍度，实现也比较简单，是我最推荐的中小规模方案。

第三套是让LLM自己选候选。具体做法是先给模型一个带“动作名+一句话摘要”的全局索引，让它根据当前状态从索引里选出一批候选动作，再把候选的完整描述喂给模型做最终选择。这种方法选择质量高，但会多一次模型调用，延迟和成本都上去了，更适合动作库极大、单次检索无法覆盖的场景。

实际项目里，我建议小动作库（少于30个）直接用embedding检索就够了；动作库超过100个，再加上二级筛选逻辑。不要一上来就搞三套方案全家桶，先用最简方案跑通，再看瓶颈在哪。

3.3 动作库更新：时机、版本和一致性

动态和静态最大的区别，就是动作库会变。而变化如果没有规则约束，系统很快会乱套。

我在项目里总结出三个更新原则。第一个原则是“先登记后启用”。一个新动作从“被环境发现”到“允许模型调用”，中间至少要经过一个合法性校验步骤。校验可以是规则，比如函数签名完整、参数Schema可解析；也可以是人工审核，尤其是涉及真实业务操作的动作，宁可让人看一眼也别让模型直接调。

第二个原则是“下线不删除”。动作因为版本升级或业务下线被停用，不能直接从库里删除，而是要把状态改成inactive。因为历史会话里可能还留有对这个动作的引用，直接删除会导致回溯时找不到对应定义。状态标记就能保住链路完整性。

第三个原则是“带着版本号调用”。每次模型选择动作并执行时，记录下该动作当时的version；执行完发现动作库更新了，不能拿新版本的Schema去理解旧调用结果。版本号这里的作用就是快照，防止“用旧钥匙开新锁”的错位问题。

3.4 一个可运行的简易方案示例

下面给出一份简化但能跑的Python伪代码，演示动态动作空间的基本循环，重点是让你看清“检索-决策-执行-注册”四个环节是怎么衔接的。

class DynamicActionSpace: def __init__(self, actions): self.actions = actions # dict: name -> meta self.embedder = load_embedding_model() def register(self, new_action): name = new_action["name"] new_action["embedding"] = embed_text(self.embedder, new_action["description"]) new_action["state"] = "active" self.actions[name] = new_action def search(self, query, top_k=8): q_vec = embed_text(self.embedder, query) scored = [] for name, meta in self.actions.items(): if meta.get("state") != "active": continue score = cosine_similarity(q_vec, meta["embedding"]) scored.append((score, name)) scored.sort(reverse=True) return [name for _, name in scored[:top_k]] action_space = DynamicActionSpace(load_initial_actions()) observation = initial_task_state() history = [] while not task_finished(observation): candidates = action_space.search( query=observation + " | " + task_objective, top_k=8 ) prompt = build_agent_prompt(observation, history, action_space.actions, candidates) response = llm_response(prompt) action_name, action_args = parse_action(response) if action_name == "stop": break observation = execute_action(action_space.actions[action_name], action_args) history.append((action_name, action_args, observation)) for new_action in extract_new_actions_from_observation(observation): action_space.register(new_action)

这里有几个容易被忽略的细节。build_agent_prompt只接收候选动作的完整描述，而不是全量动作列表；extract_new_actions_from_observation负责从环境返回里识别新动作，这通常需要配合正则或进一步调用模型来提取；task_objective要始终保留在查询里，否则只基于当前观测检索，Agent容易在子任务里越走越偏。

把一个Demo跑起来并不难，真正花时间的是后面的调优。下一节我就来讲讲怎么评估这套系统，以及怎么判断它到底有没有跑在正确的方向上。

4. 效果评估：怎么看动态动作空间到底值不值

4.1 推荐评测场景与评测指标

动态动作空间的价值不在“跑通Demo”，而在复杂、多步、非确定性的场景里能不能稳定超过静态方案。我建议至少准备四类评测场景：多步工具调用、网页交互操作、代码执行与调试、实时数据查询。每一个场景都要强调“环境反馈会影响后续动作选择”，这样才能拉开动态和静态的差距。

评测指标建议同时看五类数据。任务成功率是硬指标，一个任务从头到尾能否给出正确结果。平均调用步数看方案是否路径更短。动作选择准确率看每次决策是否选对动作，这是定位问题的核心。上下文token消耗直接反映成本。最后一定要加一个“新动作利用率”——在整个评测过程中，模型到底有没有真正用到执行中新增注册的动作。如果这个指标经常是0，那说明你的动态扩展链路可能只是摆设。

4.2 静态方案和动态方案的真实差距

我在一个中等规模工具集上做过对比实验：工具总数45个，任务类型包括数据查询、文件操作、API调用三种。静态方案把所有45个工具描述全部写进系统提示词，动态方案用embedding检索每轮选出8个候选。

结果和预期一致。静态方案的动作选择准确率在80%左右，动态方案能提到94%以上。任务成功率方面，越复杂的多步任务，差距越大。三步以内的短任务两者差距不到两个百分点，但八步以上的长任务，动态方案成功率高出静态方案十几个百分点。平均每轮上下文token消耗，动态方案比静态方案低了60%以上。

最让我意外的是新动作利用率。第一版实验里我把“新增动作注册”的触发点设计在某个API返回的头信息中，预设了两条新接口。静态方案从头到尾完全不知道有新接口可用，在需要这些新能力时只能报错；动态方案则能在执行到对应步骤后检索到新注册动作，并在后续环节正确调用。这个对比非常直观地说明了动态扩展的意义：它不仅是省token，更是让Agent具备“在环境中发现新工具并学会使用”的能力。

4.3 需要客观看待的性能代价和边界

动态方案不是白拿好处的。首先是检索链路引入了额外延迟，embedding计算和相似度排序在大动作库下会有几十毫秒到几百毫秒的开销；如果动作库特别大，还需要上向量数据库，部署复杂度随之上升。

其次是检索质量的上限决定了整个系统的上限。如果动作描述写得含糊，或者embedding模型本身区分度不够，筛选出来的候选子集可能丢掉最优动作。这时模型再强也没用，因为它根本看不到那个被滤掉的动作。这个问题在动作描述高度相似的时候尤其严重，比如“获取合同列表”和“查询合同详情”两个动作，语义接近，embedding排序经常难分伯仲。

最后是动态更新的副作用。新动作批量注册时，如果没有过滤垃圾动作，库会越来越脏；检索时把一堆低质量动作捞上来，反而干扰决策。所以我一直强调，动态动作空间不是“自动化越多越好”，而是“该动态的环节动态，该受控的环节受控”。核心动作和临时动作一定要分开标记，质量门槛不能只靠检索兜底。

5. 实践经验与避坑指南

5.1 动作库多大时才值得动态化

这是很多人问我的第一个问题：动作库到底多大，才值得上动态方案？

我的经验是，少于10个动作，老老实实用静态全量列表就行。30个左右开始出现选择准确率下降，这时可以先只做“检索筛选”，不做“运行中新增”。动作库超过50个，或者动作会随环境变化，再考虑完整动态方案。我不建议一开始就为了“技术先进”给只有五六个工具的Demo套上动态框架，那只会增加无谓的复杂度和排障成本。

判断标准其实很简单：如果你发现模型偶尔“看不到某工具”、上下文经常被工具描述堆满、或者工具列表这个月就改了好几次，那动态方案就该提上日程了。反之，工具固定、数量不多，动态化只是给自己添堵。

5.2 动作描述怎么写才不会被模型“选错”

动作描述是动态动作空间里投入产出比最高的优化点。我踩过几次坑之后，总结出几条硬规则。

描述要以“做什么”开头，不要以“这个接口用于”开头。比如“查询指定订单的物流轨迹”就比“该接口用于根据订单号查询物流轨迹信息”更清晰，模型识别动词意图更直接。要在描述里写出“何时用、何时不用”，比如“适用于已支付订单的物流查询，未支付订单不返回任何信息”。模型需要知道边界，边界写得越清楚，误用越少。最好给一个“正例+反例”的隐性样例。正例在example字段里体现，反例可以在description末尾补充“不使用场景：当事人尚未提交订单时不应调用”。

我见过一份动作描述，写的是“提供订单查询服务”，后面参数都是订单号、客户名、时间范围。等到模型真去调用时才发现，这个接口只提供聚合统计，不提供明细。描述和实际行为不一致，是动作层面最大的坑，比格式不合法更难排查。

5.3 动态更新最容易踩的三个坑

第一个坑：动作重复注册。环境多次返回同样的函数定义，多次注册后动作库里出现同名同逻辑但不同版本号的记录。模型检索时可能看到两个几乎一样的动作，也不知道该选哪个。解决办法是注册前先检查“名称+参数签名”是否已存在，存在就直接更新版本，不新增条目。

第二个坑：已经失效的动作没及时下线。比如某个第三方接口开始报422，你通过环境反馈能感知到它变了，但如果更新逻辑只做新增不做失效判断，动作库里就会积累一堆“僵尸动作”。建议每次注册新动作时，顺手比对新旧Schema，如果类型或必填项变了，自动把旧版本标记为inactive。

第三个坑：动态注册的动作没经过安全校验就暴露给模型。尤其涉及文件删除、订单修改、资金操作这类高影响动作，必须在注册链路上加一层白名单或人工确认。不要高估模型对动作后果的判断力，动态化的便利性不应该以系统安全为代价。

5.4 排查问题的一些调试技巧

动态动作空间比静态方案多了一条链路，排查问题的难度也更高。我自己的调试顺序是：先查检索，再查描述，最后查执行。

遇到模型选错动作时，我会先把检索结果打印出来，看目标动作到底有没有进入候选集。如果目标动作根本没被召回，问题出在检索逻辑或embedding质量；如果目标动作在候选集里，但模型没选，问题才出在提示词或模型本身。这个二分定位法能帮你快速把问题缩小到具体环节。

还有一个技巧：在系统提示词里强制要求模型每轮输出“选择该动作的依据”。这个设计一开始只是为了回溯方便，后来发现它本身也能降低模型乱选的概率。因为模型在解释依据时，会更认真地比对候选动作描述和当前任务，逻辑上的不匹配更容易暴露。

最后，日志里一定要记录动作库版本快照。动态系统最怕的就是“这个动作上轮还能用，这轮突然没了”，有了版本快照，就能确认是检索漏掉了，还是动作库更新时被覆盖了。很多时候，排障的答案不在模型，而在你的动作库里。

我个人在实际操作中的体会是，动态动作空间这个方向真正打动人的地方，不是它比静态方案多了多少理论创新，而是它把“环境是会变的”这个常识重新放进了推理链路。模型不再被假设成一个面对固定工具集做选择的机器，而是变成一个能感知新工具、淘汰旧工具，在变化中持续做决策的智能体。如果你手头有工具调用相关的Agent项目，不妨先找一个中等规模的动作库，把静态和动态两条链路跑一遍，量化和静态方案的差距后，你大概率也会得出和我一样的结论：这个方向，值得深入推进。