企业官网建设流程全解析

你有没有过这种经历：脑子里突然闪过一个念头，“哎，这个开源项目最近更新挺快，帮我梳理一下它最近三十天到底改了什么”，然后你打开编辑器、翻出上次那个 prompt、补一段背景、调整参数、等模型跑完、再把结果手动归档到笔记里——我掐过表，这一整套动作下来十分钟打底。而那个念头本身，从出现到消失，可能也就三秒钟。作为一个天天跟大模型打交道的工程师，我一直觉得这件事特别反直觉：模型越来越聪明，但“派活”这个环节却还停留在手工时代。

我的目标很简单：把“突然想到”到“Agent 开工”的派活摩擦压到一分钟以内。不是做一个平台，也不搞复杂的多租户系统，就是给自己用的一套轻量 Agent 调度工具。现在实测稳定运行了两个多月，从随手丢一个想法，到 Agent 真正开始干活，最快能压到五十秒左右。这篇文章就是这套方案的完整复盘，包括我为什么这么设计、核心代码怎么写的、中间踩了哪些坑，以及一些常规文档里不会告诉你的细节。如果你也是一个人开发、手上有一堆杂活想甩给 Agent，这套思路可以直接抄作业。

1. 项目整体设计与思路拆解

1.1 派活摩擦到底卡在哪

先说一个容易被忽略的事实：我们讲 Agent 效率的时候，聊的大多是模型推理速度、工具调用准确率、并发吞吐能力——但这些都是“Agent 开工之后”的事。开工之前的这段路，才是真正让我难受的地方。

我给自己做了一次完整的任务拆解，发现一次典型的“随手派活”，实际上要经过六个环节：明确意图（这个念头到底想让我干嘛）、补全上下文（这个项目是什么背景、我之前处理过类似的吗）、选工具（用浏览器还是用代码执行器，还是直接查知识库）、写 prompt（把前几步变成一段能干活的话）、执行等待、结果归档。前四步听起来都有对应的工具，但问题是它们分散在不同的软件里，每次都要来回切换。

我试过直接用 ChatGPT、Claude 这类聊天界面派活，感觉是“聊天很爽，归档很苦”。同样一个任务，今天问一遍、明天问一遍，每次都要重新解释背景，而且做完的结论散落在对话流里，回头想找都找不回来。我也试过比较重的 Agent 平台，功能确实全，但配置成本太高，光是把“工具权限”和“知识库绑定”调明白就花了一个周末，后来发现我百分之八十的任务只需要那么几种固定玩法，重平台完全是杀鸡用牛刀。

真正让我下决心自己写一套工具的原因，是有一天我想做一件很简单的事：让 Agent 每隔几天帮我盯一下某个页面的价格变化，有变动就通知我。但在现成的平台里，这需要我配置触发器、写回调、设定权限……折腾了半小时没跑通，最后我关掉页面，自己半小时手写了。那一刻我就明白了，派活摩擦的本质不是“没有工具”，而是“工具和任务之间的距离太远”。我要做的，是把这六步压缩成一步：丢一句话进来，剩下的全自动。

1.2 设计原则：把“怎么干”固化成协议，把“干什么”留给动词

我给自己定了四条设计原则，这四条原则决定了整个项目的走向，也推荐你在做类似系统时先想清楚。

第一条是入口极简。所有任务从我这边进来的时候，就是一个自然语言句子，可能是打字，也可能是语音转文字。我刻意没有做复杂的表单页面，因为任何需要填写的字段都会成为派活的心理障碍。念头本来就是碎片化的，系统必须容忍碎片。

第二条是模板化任务契约。我把“怎么干”这件事从每一次的 prompt 里抽出来，固化成任务模板。模板里写清楚执行什么步骤、用哪些工具、输出什么格式、结果存到哪里。用户（也就是我自己）只需要提供“干什么”这个动词和相关的对象。“怎么干”和“干什么”分离，是整个系统能把摩擦降到一分钟的关键。

第三条是记忆自动补全。以前每开一个新对话，都要重新交代背景。这套系统里，我会让 Agent 在执行前自动去检索本地记忆库，把与本次任务相关的历史结论、项目背景、偏好设置拼进上下文。说白了就是：你不用解释你是谁、你要什么，系统默认知道。

第四条是异步反馈。派活之后不等结果再继续等，执行完成的通知推到我的消息入口，该归档的自动归档。这看起来是个小细节，但它大幅降低了“等结果”的焦虑感，让我更愿意把随手念头丢给 Agent。

这四条原则其实对应一个更朴素的经验：凡是重复超过三次的动作，都值得固化成模板；凡是说过一次的信息，都不应该再说第二次。

1.3 为什么选轻量自建而不是主流框架

热词里大家都在聊 Agent 框架，什么 LangGraph、AutoGen、CrewAI、Spring AI Agent，我都接触过。但最后这套系统的执行层，我只保留了一个非常薄的调度器，外加几个官方 CLI 工具。原因很简单：我看过吴恩达那个 Agent 教程，也知道业界普遍认为 Agent 的力量来自于“规划、工具、记忆、多智能体协作”的组合，但那是方法论层面的参考，不等于每个场景都要上全套架构。

我的任务类型其实很有限：查资料归纳、跑代码验证、盯网页变化、写文档草稿。这类任务用 ReAct 循环都嫌重，很多时候一个带工具的 prompt 就能搞定。重框架的最大问题是抽象层太多，调试时要穿过框架的封装去看模型到底在干什么，反而拖慢了我的迭代速度。轻量自建的核心优势是：每一个环节都是裸的，出问题了我一眼能定位。我这套系统从初始化到第一版跑通只用了三天，而当时如果去读框架文档再配置环境，估计一周都下不来。

2. 核心细节解析与实操要点

2.1 意图识别：从一句话到结构化任务

在一分钟目标里，意图识别要解决的核心问题是：怎么把“帮我看看 X 项目的 issue”这种话，变成机器能稳定处理的 JSON。

我试过纯正则匹配，效果惨不忍睹。因为同一个意图的表达方式太多了，“看看”“查一下”“梳理一下”“总结一下”全是同一个意思。最后我选择用结构化输出（Structured Output）来做。方法不复杂：给模型一个 Pydantic 模型作为 schema，告诉它把你的理解填到这个结构里。核心字段有四个：task_type（任务类型）、target（任务对象，通常是 URL 或文件路径）、constraints（约束条件列表，比如时间范围、语言）、output_path（期望的输出位置，可空）。

这里有三个实操要点，都是踩坑踩出来的。

第一个是分类别太细。我一开始定义了十五个task_type，结果模型频繁混淆“research”和“summary”。后来砍到五个大类：research（检索归纳）、code（代码执行验证）、monitor（监控变化）、write（文档生成）、misc（其他）。分类粒度越粗，命中率越高，反正模板之间可以组合，不需要一次性把事情做完。

第二个是schema 字段要少。字段越多，模型“编造”空值的概率就越大。我给constraints设了默认空列表，给output_path设了可选，这样模型在面对模糊表达时，宁可留空也不瞎填。

第三个是必须要有一个置信度字段。schema 里加一个confidence: float，让模型在理解不确定时给低分，比如只说“那个东西更新了”这种指代不明的话。调度器拿到低置信度会回问一句，而不是硬着头皮执行。

from pydantic import BaseModel, Field from typing import List, Optional class TaskIntent(BaseModel): task_type: str = Field(description="research/code/monitor/write/misc") target: str = Field(description="URL or file path or topic") constraints: List[str] = Field(default_factory=list) output_path: Optional[str] = None confidence: float = Field(description="0~1, lower means unclear")

2.2 任务模板：Agent 执行的最小配置单元

意图识别完成之后，调度器要根据task_type找到对应的模板。我的模板不是一个字符串，而是包括四部分的配置：system_prompt（干活的角色设定和方法）、allowed_tools（这个任务能调用哪些工具）、output_spec（输出的格式要求）、timeout（最大执行时间）。

模板用装饰器注册成一张全局表，写起来很像 Flask 的路由。我推荐你也用这种“注册表”的方式，而不是把模板散落在各个脚本里。

TEMPLATES = {} def task_template(name): def decorator(cfg): TEMPLATES[name] = cfg cfg["name"] = name return cfg return decorator @task_template("research") RESEARCH_TEMPLATE = { "description": "针对一个主题或网页进行资料查阅、归纳总结", "system_prompt": "你是资深分析师。请围绕目标主题收集信息，区分事实与推测，输出带来源标记的结构化摘要。", "allowed_tools": ["web_search", "fetch_url", "read_file"], "output_spec": "markdown，含'核心结论'、'证据要点'、'来源链接'三部分", "timeout": 120, }

模板设计最关键的一点：description字段不是给人看的说明，而是给意图匹配看的“路由关键词”。我一开始没写这个字段，导致除了 task_type 完全匹配之外，模板之间无法做相似度路由。后来我给每个模板都写了一句高语义密度的话，比如 research 的 description 是“查资料、看网页、归纳总结、找证据”，这样模型在解析意图时可以直接读到候选模板的描述，把task_type和模板描述对齐，准确率明显上来了。

还有一个容易被忽略的细节：每个模板必须定义“结束条件”。比如 research 是“找到至少三个来源”、monitor 是“确认页面快照生成完毕”。没有明确结束条件，Agent 容易陷入“我还能再补充一点”的循环。这与热词里大家抱怨的“agent execution terminated due to error”是两码事，那个是异常终止，而我说的是正常流程里如何判断“干完了”。

2.3 记忆补全：一分钟里的隐形工作

我的“一分钟派活”之所以能成立，很大程度上归功于记忆补全。以前和 Agent 对话，最大的隐性成本是“重新解释背景”。我明明上周已经和它讨论过某个项目的技术选型，今天再说起这个项目，它还是一副第一次听说的样子，每次都要把背景贴回去。

我的做法分了三个阶段，复杂度递增，你可以按需选。

第一阶段是关键词召回：每次任务完成的摘要会追加进一个本地 Markdown 文件，用关键词做简单匹配。这个方案能解决百分之四十的问题，缺点是同义词召回很差，说“电商平台”就搜不到“淘宝”。

第二阶段是向量召回：把历史摘要切段后做 embedding，存进 SQLite 的向量表，任务开始时用目标文本的 embedding 做相似度检索，取 top-k 拼进上下文。这里有一个关键参数：相似度阈值。我见过不少 Agent 记忆设计失败，就是因为没有阈值过滤，分数很低的无关记忆也被硬塞进上下文，导致模型被旧信息带偏、答非所问。实践下来阈值设 0.75 比较稳，低于这个分值的宁可不要。

第三阶段是偏好沉淀：把我在任务中明确说过的话，比如“输出要带中文摘要”“代码示例要用 Python”，提炼成一条条偏好规则，放到一个固定的偏好文件里，每次都加载。本质上这是让系统越来越懂你，而不是每次从零开始理解你。

提示：记忆不是越多越好。上下文里塞三十条无关记忆，对模型输出质量的破坏力，比没有记忆还大。过滤和排序，比“存得多”更重要。

3. 实操过程与核心环节实现

3.1 整体技术栈与目录结构

我的整套系统是用 Python 写的，核心依赖只有三个：openai或同类 SDK（负责调模型做意图识别）、pydantic（结构化输出）、sqlite-vec（向量记忆，可选）。执行层没有自己写 Agent 循环，而是直接调用现成的 CLI——比如 Codex CLI、Claude Code 这类支持沙箱环境的工具，我的调度器负责传参和回收结果。

这里要补充一句，关于热词里大家总在问的“AI Agent 怎么扛并发”：个人场景其实根本不需要扛高并发，我同一时间最多跑两三个任务，所以调度器用的是简单的 asyncio 队列。并发能力不是靠框架堆出来的，而是靠“限制同时执行的任务数”和“给每个任务独立沙箱”这两条硬约束保证的。如果你要做的也是个人工具，别急着上 K8s，先把单机队列稳住。

项目目录结构如下，体量很小但可扩展性还可以：

dispatch/ ├── dispatch.py # 主调度器 ├── templates/ # 任务模板注册 │ ├── research.py │ ├── code_run.py │ └── monitor.py ├── memory/ │ ├── vector_store.py # 向量记忆 │ ├── archive/ # 任务归档 markdown │ └── preferences.md # 偏好沉淀 ├── sandbox/ # 每个任务的独立工作目录 │ └── task_20250101_.../ └── config.yaml # 模型、超时、目录白名单

3.2 调度器核心代码实现

整个系统的心脏是一个dispatch.py，它只有三个函数链：parse_goal→match_template→execute。我把它简化贴出来，你可以直接在此基础上改。

async def dispatch(goal_text: str): # 1. 意图识别 intent = await parse_goal(goal_text) # 返回 TaskIntent if intent.confidence < 0.6: return "理解不太确定，请补充对象或意图" # 2. 模板匹配 + 记忆补全 template = match_template(intent.task_type) context = await recall_memory(intent.target) # 向量召回历史 # 3. 组装执行环境 workdir = create_sandbox(template.name) # 独立目录，隔离风险 run_config = { "prompt": build_prompt(template, intent, context), "allowed_tools": template["allowed_tools"], "timeout": template["timeout"], "workdir": workdir, } # 4. 执行：根据模板选择 CLI 或 API 方式 result = await run_agent(run_config) # 5. 归档与通知 summary = extract_summary(result, template) save_archive(summary, workdir, intent) notify(summary) return summary

parse_goal的实现非常简单，就是把TaskIntent的 schema 传给模型：

async def parse_goal(goal_text: str) -> TaskIntent: resp = await llm.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "把用户目标解析成结构化任务，不确定就降低 confidence。"}, {"role": "user", "content": goal_text}, ], response_format=IntentResponseFormat, # 依赖 SDK 的结构化输出 ) return IntentResponse.model_validate(resp.choices[0].message.content)

build_prompt是整条链路里最能体现“摩擦压缩”的地方。它把三块内容拼在一起：模板的 system prompt、从记忆里召回的相关历史摘要、用户的原始目标。大多数时候用户只需要一句话，但模型看到的是一份含上下文的简报。这就是为什么我自己的 Agent 看起来“很懂我”，本质上不是模型懂，而是我给了它足够的上下文铺垫，只是这些铺垫不再需要我手写而已。

3.3 执行器与沙箱配置实践

执行器有两种路径：调 API 或者调 CLI。我的经验是：凡是涉及代码运行的，一律走 CLI 沙箱；凡是纯文本知识处理的，可以走 API。原因是代码运行的风险等级高，需要文件系统隔离和权限控制，CLI 工具通常已经内置了沙箱机制，直接复用比自己去造轮子安全得多。

我自己用的是 Codex CLI 和 Claude Code 这类支持沙箱模式的工具，调度器通过 subprocess 调用它们，然后传入workdir、超时时间和 prompt。我踩过一个很典型的坑，就是热词里那批人问过的“codex 无法发送消息，显示更新 agent 沙盒”——这个问题的根因通常是沙箱目录权限不对，或者环境变量没传进去。当时我的排查过程是这样的：

1. 先看错误文案，确认是沙盒更新失败，不是网络问题 2. 检查任务目录权限，确认运行用户有读写权限 3. 检查环境变量，发现 PATH 里没有 CLI 依赖的某些路径 4. 最后定位到：CLI 版本太旧，沙箱文件不兼容新环境

解决之后我给沙箱写了一个固定初始化脚本，每次创建任务目录时自动同步最新的 CLI 镜像和配置，之后再也没出过这类问题。这个经验可以抽象成一句话：遇到 Agent 环境类报错，先看环境变量和目录权限，再怀疑代码逻辑。

沙箱配置里还有两个参数强烈建议设置。第一个是timeout，我用timeout=120兜底监控类任务，用timeout=30兜底普通查询。第二个是max_steps，代码执行类的 ReAct 循环如果不设上限，模型可能在一个问题上反复横跳二十轮，既烧钱又超时。之前“agent execution terminated due to error”很多次都是因为模型把自己绕进死循环然后爆掉，设了max_steps=8之后执行稳定性明显提升了。

下面是我实际跑通的一个例子，时间记录来自系统日志：

输入："梳理一下 Requests 库最近 30 天 release notes，总结主要变化" 意图解析耗时：1.8s，task_type=research，confidence=0.93 记忆召回：匹配到 3 条历史笔记（含上次整理 Python 生态的偏好规则） 执行耗时：47s，经过 web_search + fetch_url 两步获取数据 归档：自动生成 markdown 存档，通知推送到手机 总计：约 52 秒从想法到归档完成

虽然名字是 Requests，但你换成“Rust 生态”“某个数据库新版本”都一样，这套流程是通用的。

3.4 一分钟目标是怎么被拆出来的

给读者一个透明的视角：所谓的“一分钟”，不是我拍脑袋定的 KPI，而是从链路反推出来的。整条链路拆成五段：意图解析（目标不超过 5 秒）、模板匹配与记忆补全（不超过 10 秒）、执行器启动与沙箱就绪（不超过 15 秒）、Agent 干活（这部分是变量，通常 30 到 90 秒）、归档通知（不超过 5 秒）。真正的时间大头永远在执行本身，而派活摩擦只占前面三段。如果执行前的准备超过 30 秒，那一定是链路里有环节在做多余的事情。

这一点值得展开：很多人做 Agent 工具，把时间花在调模型、调 prompt 上，但“派活摩擦”恰恰是准备链路里的工程问题，不是模型问题。我在最初版本里，意图解析甚至用了完整的 GPT-4，一来一回要等四五秒，后来换成gpt-4o-mini并把 schema 简化后，解析速度降到 1.5 秒左右，准确率几乎没有下降。对轻量工具来说，模型选型的第一指标是延迟，不是智商上限。

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

4.1 高频问题速查表

这套系统跑了两个多月，我遇到的实际问题远不止模型回答错那么简单。把典型问题整理成一张排查表，方便你对照：

这六类问题里，有三类是我最开始完全没预料到的：记忆串味、沙箱环境错误、以及“模型知道答案但故意走了一堆弯路”的伪智能问题。

4.2 印象最深的三个坑与修复过程

第一个坑是记忆串味，这个必须单独说。有一段时间，我的 Agent 在回答“监控任务”的问题时，老是莫名其妙带上“上一轮查资料的结论”。查了很久才发现是召回模块没有过滤分数，把相似度只有 0.3 的历史笔记也拼进了 prompt。模型看到上下文里有一段和当前任务无关的旧信息，它不会忽略，而是会尝试“合理化”它，最后生成的内容就变成怪异的缝合怪。修复方式就是我在前面提的：加阈值、限制 top-k。这个坑也让我对“Agent 记忆”这个热词有了更清醒的认识——记忆的关键不是“存了什么”，而是“取出来的时候过滤了什么”。

第二个坑是CLI 沙箱环境初始化失败。某天早上我例行派一个代码验证任务，直接报错说 Agent 无法启动。我当时的第一反应是模型接口坏了，换了模型、换了网络，折腾了二十分钟。最后冷静下来去翻沙箱日志，发现是前一晚系统升级把它依赖的一个可执行文件路径改了。这个教训很朴素：排查问题要看日志、按链路逐级排查，别跳步骤。现在我在沙箱初始化的入口加了一个环境健康检查函数，启动前检查所需命令是否可用，有问题就直接报“哪个路径缺失”，而不是等到 Agent 跑到一半才炸。

第三个坑比较有意思，我管它叫“模型绕远路”。有一段时间我让 Agent 做一个简单的文本归纳，它愣是去搜索了五个网页、读了三个文档，绕了一大圈才给出答案。原因是我在 research 模板的 system prompt 里写了“请充分利用可用工具”，这句话被模型解读成了“必须把每个工具都用一遍”。这是个典型的 prompt 过度引导案例。改成“仅在必要时使用工具，信息充分即可作答”之后，执行时间缩短了差不多一半。由此我也总结出一条经验：给 Agent 写 system prompt 时，不要用鼓励性的空话，多用“最小行动原则”，明确告诉它什么情况下应该停止。

4.3 排查思路的通用方法论

把这几次排查串起来看，我有一个通用的方法论：遇到 Agent 类问题，永远按照“输入 → 环境 → 模型 → 逻辑”的顺序排查。

• 先确认输入是什么样，是不是用户的表达方式触发了误判；
• 再确认环境的权限、路径、版本是否正常；
• 然后单独测模型，给它一个手工写好的标准输入，看它能不能正确输出；
• 最后才去检查调度逻辑的编排是否正确。

这套顺序能避免 90% 的瞎折腾。很多初学者上来就怀疑模型能力不行，或者怀疑框架有 bug，其实绝大多数问题都在“环境”和“逻辑”这两层。顺便说一句，网上那些“Agent 项目从 0 到 1 搭建”的教程，通常会花大量篇幅讲模型怎么规划、工具怎么调用，但很少讲派活链路的稳定性问题。我这篇文章的侧重点恰恰是补上这块：真正影响日常使用体验的，不是模型会不会规划，而是整个派活管道会不会动不动就卡住。

5. 安全边界与后续扩展

5.1 Agent 权限收口：能做什么不如不能做什么

既然 Agent 开始代替我做一些真实的事情，就一定要聊“Agent 安全”这个话题。我自己定的安全原则很简单：给 Agent 最小权限，让它所有动作都在受控的沙箱里发生，关键操作必须经过人工确认。

具体到配置上有这么几条硬约束：

• 目录白名单：Agent 只能读写sandbox/task_xxx/和指定的笔记目录，其他位置一律禁止访问。我在沙箱初始化时就把workdir之外的文件系统权限切掉了。
• 命令黑名单：代码执行类的 Agent，启动前注入黑名单拦截逻辑，删除类的命令、修改系统配置类的命令直接拒绝。
• 关键操作确认：Agent 发现目标是“关闭服务、修改线上数据”这类高风险动作时，必须返回一个确认请求，由我手动批准后才会继续。
• 输出审计：所有结果的存储路径统一收口到memory/archive/，不允许 Agent 自行决定写盘位置。这既是归档习惯，也是安全兜底。
• 超时与恢复：所有任务强制 timeout，超时即杀掉进程并回收容器。不会出现一个失控的 Agent 循环占满资源的情况。

这套约束在热词里对应的就是那句“agent安全”和“a-memguard”这类防护思路。我自己没有上复杂的记忆攻击防护方案，因为我的场景是单人使用、任务边界清晰，基于最小权限的沙箱隔离已经足够。如果你的 Agent 要暴露给外部用户，那安全模型就要重做，但那是另一个量级的问题了。

5.2 这套系统还能往哪扩展

目前这套工具只覆盖了我自己最常用的几类任务，但它扩展起来很容易。我留了几个比较顺手的扩展方向，你要是也打算自己搭一套，可以参考这个顺序。

第一个方向是定时触发。把 dispatch 接到 cron 或系统定时器上，就能做出“每周一早上九点自动汇总上周项目动态”这类自动化。这个扩展的难点不在于调度本身，而在于让意图识别和模板匹配支持“没有用户输入”的模式，说白了就是任务参数部分来自定时配置、部分来自记忆库自动补全。

第二个方向是多入口接入。我现在主要用终端命令和手机端两个入口，终端适合开发时使用，手机端适合在通勤时丢一个念头进去。原理都一样，把消息传进 dispatch，再把结果推送回来。

第三个方向是多 Agent 协作工作流。比如一个 Agent 去搜集资料，产出交给另一个 Agent 去撰写草稿，最后再有一个 Agent 做格式校验。这个方向我之前尝试过，结论是：协作的价值要到任务链条足够长才体现出来，短任务强行拆成多 Agent 反而会增加上下文传递的损失和延迟。所以我建议你先把单 Agent 的派活摩擦打磨好，再考虑多 Agent 的编排。

还有一个比较高级的方向是共享记忆库。如果团队里有几个人都在用各自的 Agent，大家可以把任务归档放到一个共享的仓库里，这样每个人派活时都能自动检索到别人已经做过的结论，避免重复劳动。这个本质上就是热词里“agent记忆”在团队场景下的应用，但工程复杂度会随团队规模上升，我目前还是在单机层面做，先把个人效率吃透再说。

写在最后的一些体会

这套系统做完之后，我最真实的感受是：它带给我的最大收益不是我“省了”多少分钟，而是让我变得敢把念头随手丢出去了。以前冒出一个小问题，我会下意识地想：就这么个小问题，专门跑一趟工具链是不是太麻烦？现在完全不会，心里一闪而过的想法，随手丢给 Agent，它跑它的，我继续我手头的事，等结果回来再决定要不要深入。我的很多小项目、小实验，其实就是从这样一个随手丢出去的疑问开始的。如果派活本身成了一座大山，那些脆弱的灵感碎片根本到不了开工这一步。

最后再分享一个小技巧，是我用着用着发现的：给每个模板加一个“状态”字段，不用的模板不要直接删除，而是标记成deprecated，并给一句原因说明。因为我的意图识别层会把模板描述喂给模型做匹配，如果你把旧模板删了，模型在模糊意图时反而可能匹配到完全不相关的新模板。标记成deprecated之后，路由逻辑会直接跳过它，但它的描述仍然会给模型提供一个“这些事我们不接”的边界信号。这个小细节对意图识别稳定性有明显的正面作用，值得你试试。

这套方案的代码量不大，思路也不复杂，它的核心价值其实在于那一层“派活协议”：把重复的“怎么干”收进模板，把临时的“干什么”留给一句话。如果你也经常有一堆一闪而过的念头想委托给 Agent，照着这个思路搭一个轻量版本的试试，大概率不会让你失望。