企业官网建设流程全解析

1. 开头：一个业务系统太多，Agent 帮手反而变笨了

接触过这类项目的人都懂，真正推动我去做「分层定制」的，不是技术炫技，而是被实际业务痛到不行。之前给某公司内部做统一的 AI 助手时，最初的想法很简单：把所有业务知识塞进一个知识库，把所有能用得上的工具全部注册成控制器，让大模型在 browser-use WebUI 里统一调度。结果上线没两周就翻车了——客服同学问订单问题时，模型把另一套财务系统的报销术语也带了出来；运维同事让它操作服务器，工具列表里居然混着市场部门的营销文案模板。知识互相污染、工具彼此冲突、上下文被不相关的内容挤爆，这是所有想在浏览器自动化场景里做业务定制的人早晚要撞上的墙。

所以这个标题其实戳中了一个很核心的工程问题：当 browser-use WebUI 需要服务的不只是一个系统，而是多个业务系统，且每个系统在知识库和控制器上都有完全不同的要求时，怎么做才能让同一个 Agent「见人说人话、见鬼说鬼话」？答案就是标题里说的「分层定制」：按照业务系统把知识库拆开、把控制器拆开，运行时判断当前在哪个系统，再动态加载对应的那套配置。这篇文章我会把完整思路、架构设计和落地时踩过的坑都写清楚，适合正在用 browser-use、想在 WebUI 之上做多业务定制的人参考，也适合准备把 Agent 工程化落地的团队看看。

需要先交代一个概念，免得后面混乱：这里说的知识库，指的是喂给大模型做检索增强（RAG）的文档/向量数据；控制器，指的是给大模型调用浏览器、点击、输入、读取页面等能力的工具集，也可以理解成技能插件。分层定制的目标，就是让这两样东西都跟着“当前正在访问的页面/业务系统”走。

2. 为什么单一知识库 + 全量控制器撑不住多业务

2.1 知识混在一起，检索出来的答案必然是“串味”的

把不同业务系统的操作手册、FAQ、规则说明全部塞进同一个向量库，是直觉上最省事的做法，但工程上几乎一定会失败。原因不在于向量检索能力不行，而在于相似度检索天然不看业务边界。你搜「如何发起审批」的时候，向量距离最近的可能是采购审批的文档，也可能是行政用印的流程，模型拿到混合结果后只能靠猜。一旦猜错，整个对话的置信度就崩了。

举个实际例子。某公司同时跑着三类系统：CRM 客户管理、ERP 进销存、OA 审批流。统一知识库里这三块文档比例相当。测试时问「驳回一笔订单需要谁审批」，模型检索出的 Top 5 片段可能两段来自 ERP 订单流程、两段来自 OA 审批制度、一段来自 CRM 合同条款。结果它为了“全面”，把三个系统的规则揉成了一段四不像的答复。用户当场就发懵。这不是模型笨，而是我们的知识组织方式没给它边界感。

2.2 控制器全量注册，决策效率和安全性都大打折扣

控制器是另一个大坑。browser-use 这类浏览器自动化框架允许注册一系列动作，比如点击元素、表单填写、页面导航、截图分析、读取表格等等。如果 10 个业务系统各有 10 个专属控制器，加起来 100 个工具全塞给大模型，会发生什么？

模型每次决策都要把所有工具的 description 过一遍。工具列表过长时，有两个问题：一是选择准确率下降，模型更容易在相似名称的工具之间点错；二是上下文窗口被无意义占用，每个工具的 JSON Schema 描述动辄几百 token，100 个工具光定义就占掉数万 token，真正留给任务推理的空间少了一大截。更严重的是安全风险——财务系统的「发起转账」控制器在 CRM 页面里也能被调用，一旦路由判断失误，轻则报错，重则操作落到不该操作的系统上。

2.3 从一次真实故障看：不隔离边界，Agent 就是事故发动机

那次让人印象很深的故障是这样的：用户让助手在 OA 系统里查会议室预订记录，结果模型看到工具列表里有一个不在 OA 业务域内的「批量导出客户联系方式」控制器，竟然真的发起调用。页面跳转到 CRM 后，模型发现自己跑错了系统，又手忙脚乱往回跳。整个过程日志里写得明明白白：模型不是故意越权，而是它根本不知道哪些控制器是当前业务系统允许用的。这次之后我们就定了一个原则：Agent 能用的工具，必须由运行环境显式注入，而不是由模型自己从全集里挑。

应该说清楚一个反直觉的点：很多人以为「模型能力越强，越不需要人为限定工具集」。实际恰恰相反，模型越强，它越会积极尝试调用各种工具，越需要外部系统帮它划好边界。分层定制的本质，不是限制模型，而是把「当前业务场景的知识和工具白名单」替模型提前准备好，让它在清晰的边界内发挥全部推理能力。

3. 分层定制的整体架构：路由、知识、控制三层各自干什么

3.1 分层不是简单的“多建几个库”，而是把「业务系统」变成一等的定制维度

在动手改代码之前，先把架构想清楚。我的做法是把整个定制过程拆成三个层次，每一层只负责一件事，层与层之间通过一个「当前业务系统身份」的公共变量联动。

• 路由层：负责在会话开始时判断「现在正在访问哪个业务系统」。依据可以是 URL 域名、页面标题、URL 路径参数、登录用户所属角色，或者这几者的组合。
• 知识层：负责按业务系统组织知识，决定当前会话可以检索哪些知识库切片。知识库不再是「一个大池子」，而是按业务域拆成多个独立命名空间，可以交叉引用但默认隔离。
• 控制层：负责按业务系统装配控制器。每个控制器声明自己适用的业务系统，运行时只把当前系统白名单里的控制器注入给大模型。

这个设计的核心变化在于：以前我们按「功能」维度组织 Agent 的能力（一堆知识 + 一堆工具），现在改成按「业务系统」维度组织。功能只是能力本身的标签，业务系统才是决定「能力何时可用」的钥匙。

3.2 路由层：判断业务系统身份，是整个动态加载的触发器

路由层是所有动态加载的第一步，也是决定后面两层能不能正确工作的前提。我把它做成一个轻量级的判定器，放在 browser-use 的初始导航完成之后、大模型第一次决策之前触发。

判断依据优先级从高到低如下表所示：

路由判定器输出一个标准化的业务系统标识，比如crm、erp、oa、hr。之后的逻辑里，不管是加载知识库还是加载控制器，都以这个标识为查询键。如果识别不出来，不要硬猜，直接拒绝执行并提示用户手动指定业务系统，宁可停下来也不要拿错配置。

有个容易忽略的细节：真实环境下 URL 可能变化，比如从erp.xxx.com/stock跳转到erp.xxx.com/sale，虽然仍是同一业务系统，但页面语义已经变了，控制器白名单可能需要收窄。所以路由层建议做成可被页面变化触发的二次判定逻辑，而不仅仅是会话开始判定一次。

3.3 知识层与控制层：用「按需装配」替代「全量常驻」

在传统实现里，知识库检索和控制器定义通常是全局的，Agent 每次决策都能访问。分层定制要求反过来：默认不加载，路由判定后按需装配。当路由层输出业务系统标识后，由装配器读取「系统-配置」映射表，把对应的知识库配置和控制器白名单加载到本次会话的上下文中。

这个「按需装配」的设计带来的直接好处有三个：上下文干净、决策更快、权限边界清晰。知识库里不会出现别的系统的内容来干扰检索；控制器列表里不会出现别的系统的工具来诱导模型误操作；即使模型出现幻觉，它能拿到的工具从物理层面就被限定了，无法越权动作。后面我会分别把知识层和控制层的落地细节展开说。

4. 知识库动态加载：先拆库，再按业务系统挂载

4.1 拆库粒度：一个业务系统一个命名空间，必要时再按子域细分

知识库拆分的粒度直接决定后期维护成本。我的经验是：至少按业务系统一级拆分，也就是每个系统拥有独立的知识库集合或索引命名空间；如果某个系统内部的流程差异极大，比如 ERP 里的采购流程和财务流程完全不同，再往下按子域拆也可以，但要避免拆得过碎。

拆碎的下场就是维护地狱。比如把「订单页常见问题」「订单页按钮说明」「订单页字段含义」拆成三个库，看起来很精细，实际上检索时要么三库都要查，要么经常漏查关键的。更合理的粒度是「一个业务域一个库」，库内部用文档的元数据字段（业务域、文档类型、更新时间）做二次过滤。

以某公司为例，我们的知识库拆分方案是：

• kb_crm：客户管理相关的客户分级、商机阶段、跟进规则、合同模板要点。
• kb_erp：进销存相关的商品管理、采购入库、销售出库、库存盘点操作流程。
• kb_oa：审批流、会议室、公告、考勤相关的制度和操作说明。

每个库在向量数据库里对应独立的 collection 或索引前缀，检索时按 collection 隔离，互不干扰。

4.2 绑定关系配置：一份可读的映射表是命脉

拆完库之后，需要一个地方维护「哪个业务系统挂哪个知识库」的映射。我建议用 YAML 或者 JSON 配置，而不是在代码里硬编码。一份最小可用的配置长这样：

business_systems: crm: display_name: 客户管理系统 kb_collections: - kb_crm controllers: - crm_contact_search - crm_customer_detail - browser_core erp: display_name: 进销存系统 kb_collections: - kb_erp controllers: - erp_sku_search - erp_stock_query - browser_core oa: display_name: OA办公系统 kb_collections: - kb_oa controllers: - oa_approval_query - oa_meeting_book - browser_core

注意一个细节：每个业务系统都配了browser_core控制器集合。这是浏览器自动化的基础能力，比如打开页面、滚动、截图等，所有系统都需要，属于公共控制器。分层定制不是要把公共能力也拆掉，而是「公共能力默认有，业务专属能力按需加」。

4.3 挂载过程与检索策略：会话初始化时绑定，检索时限定集合

知识库的动态加载在工程上其实是「配置驱动 + 运行时绑定」。当路由层判定当前业务系统为erp后，装配器执行两件事：第一，读取映射表获得kb_erp的集合名称和连接配置；第二，在这个会话里初始化一个只指向kb_erp的检索器。后续用户提问时，检索器的相似度搜索只会在这个集合内执行。

检索策略方面，我强烈建议采用「混合检索 + 轻量重排」。混合检索指同时用向量相似度和关键词匹配（BM25）各自召回一批，再用一个轻量级的交叉编码器把两路结果合并排序。原因在于，向量检索擅长语义相似但措辞不同的查询，关键词检索擅长精确匹配专有名词（比如系统里的单据编号、特定按钮名称）。光靠向量检索，遇到「SP-2024-0912 这张出库单卡在哪一步」这种问题，容易被编号干扰；加上关键词召回后准确率高很多。

重排模型不用选太大的，百来 MB 的双塔或者小型交叉编码器就够了。这一步对最终回答质量有决定性影响——Top 5 片段里只要有一条是别的业务域的，大模型就可能被带偏。有了重排，检索结果才能稳定控制在当前业务域的文档里。

这里再给一个容易踩的坑：不要把知识库的「集合权限」和「API 密钥权限」混为一谈。即使你的向量库支持按集合做 API Key 隔离，也最好在应用层再校验一次当前会话的业务系统标识与目标集合是否匹配。安全永远多一层保险，尤其涉及敏感业务数据时。

5. 控制器动态装配：注册表、过滤器、上下文注入

5.1 控制器的本质与注册声明：让工具自己说清楚「我属于谁」

控制器在代码层面就是一组可被大模型调用的函数或工具声明。在 browser-use WebUI 的场景里，控制器可以是独立的技能包，每个技能包包含：工具函数的实现、工具的 JSON Schema 描述（包含参数、返回值、触发条件）、以及运行时元数据。

为了支持动态装配，每个控制器在注册时必须声明两个额外的字段：allowed_business_systems（允许哪些业务系统调用）和required_kb（如果需要知识库辅助，依赖哪个知识库集合）。这样做的好处是，业务系统与控制器之间的绑定关系不再是某个人脑里的记忆，而是一份可以被程序检查和测试的数据。

一个控制器注册表的示例结构如下：

CONTROLLER_REGISTRY = { "crm_contact_search": { "module": "controllers.crm.contact_search", "function": "search_contact", "description": "在CRM系统中按姓名/电话搜索客户联系人，返回联系人详情列表。", "parameters": { "type": "object", "properties": { "keyword": {"type": "string", "description": "联系人姓名或电话关键字"} }, "required": ["keyword"] }, "allowed_business_systems": ["crm"], "required_kb": "kb_crm", "danger_level": "medium" }, "browser_core": { # 浏览器公共能力，所有系统可用 "allowed_business_systems": ["*"] } }

5.2 动态装配的执行逻辑：白名单过滤 + 角色二次过滤

控制器装配的运行时逻辑不复杂，却需要严谨。我从路由层拿到业务系统标识后，先做一次「系统 → 控制器」的白名单过滤，把标记为允许当前系统的控制器全部捞出来；然后做一次「用户角色 → 控制器」的二次过滤，这一步专门处理同一系统内不同岗位权限不同的情况。

举个例子，同在一个 CRM 系统里，销售专员可以使用crm_contact_search，但不能使用crm_price_adjust（改价权限）；销售主管则两者都可以。角色信息可以从登录态里拿，在装配控制器时作为附加过滤条件。经过两次过滤后形成的最终控制器列表，连同知识库配置一起注入大模型的 system prompt 和 tools 参数里。

从代码层面看，核心过滤逻辑就几行，但边界检查要做足：

def assemble_controllers(business_system: str, user_roles: list[str]) -> list[ToolDefinition]: eligible = [] for name, meta in CONTROLLER_REGISTRY.items(): allowed_systems = meta["allowed_business_systems"] if "*" not in allowed_systems and business_system not in allowed_systems: continue required_roles = meta.get("allowed_roles") if required_roles and not any(role in required_roles for role in user_roles): continue eligible.append(load_tool_definition(name, meta)) return eligible

5.3 命名空间与描述规范：防止模型在有边界的情况下依然点错工具

动态装配解决了「能调用哪些工具」的问题，但还有一个隐形问题：工具名称和描述如果含糊，模型即使在白名单内也可能选错。比如 CRM 里有个search_contact，ERP 里也有个search_supplier，名字都很像「搜索」，模型如果不细看描述，容易被误导。

我的做法是强制规定控制器命名加业务前缀，并在描述里把业务域、触发条件、妥协同义词都写明白。例如：

• crm_search_contact：仅在 CRM 系统内，按姓名/电话/公司名搜索客户联系人。
• erp_search_supplier：仅在 ERP 系统内，按供应商编码/名称搜索供应商档案。
• oa_book_meeting_room：仅在 OA 系统内，按时间与人数预订空闲会议室。

还有一个细节值得注意：不要给多个控制器重复声明极其相似的触发条件。模型读工具描述就像人看菜单，如果两道菜名字和描述都接近，点错概率很高。宁可让描述长一点、触发条件具体一点，也不要为了省 token 写得模棱两可。

5.4 控制器之间的依赖关系也要考虑

有些控制器单独没用，必须配合另一个控制器使用。比如「导出报表」通常建立在「筛选列表」成功之后，先拿到筛选结果，才能导出。这种依赖如果靠模型自己摸索，往往要浪费好几轮试错。

我习惯在控制器注册表里加一个depends_on字段，装配时如果发现当前业务系统需要依赖某个前置控制器，会自动带上。比如：

{ "name": "erp_export_stock_report", "allowed_business_systems": ["erp"], "depends_on": ["erp_stock_query", "browser_core"] }

这样装配器在注入工具时，会确保下游工具所依赖的上游工具也同时在列表中，避免模型找到导出按钮却因为没有筛选能力而无法完成前置操作。

6. 在 browser-use WebUI 里的配置化落地

6.1 把「业务系统-知识库-控制器」绑定做成可视化配置

前面讲的是架构，这一节讲怎么把这些落在 browser-use WebUI 这个具体载体上。browser-use WebUI 本质上是一个可视化操作界面，用户可以在浏览器页面里创建任务、查看 Agent 的操作轨迹、管理配置。我们要做的，是把分层定制的映射表放到这个 WebUI 的配置层里，让非纯技术背景的业务同学也能维护。我们当时在页面上做了一个「业务系统配置」的板块，左侧列出所有业务系统，右侧分别展示这个系统的知识库挂载列表和控制器开关列表。

配置界面的字段大致如下：

把配置做成可视化不是为了花哨，而是为了让「加一个新业务系统」变成一次纯配置操作，不用改代码。实际效果是，后来某业务部门要接入一套新的项目管理系统，迭代流程从「开发介入 + 两轮代码发版」缩短到「业务人员在 WebUI 里花半小时把知识库和控制器勾选好」。

6.2 配置版本化：把数据库里的配置同步到 Git 仓库

可视化配置带来一个副作用：配置变更没有版本记录。某天知识库挂错了集合，或者控制器开关被改动，事后连回滚都找不到依据。我的建议是让 WebUI 在保存配置时生成一份 YAML 文件，同时 push 到 Git 仓库做版本管理，WebUI 数据库里只存「当前生效版本」的引用。这样改坏了可以随时 diff 回滚。

Git 仓库里的完整配置结构大概是这样：

agent-configs/ ├── systems/ │ ├── crm.yaml │ ├── erp.yaml │ └── oa.yaml ├── knowledge/ │ └── collection-mapping.yaml └── controllers/ └── controller-registry.yaml

配置与代码分开版本化还有一个额外好处：审计更清晰。查「上周三那次误操作是谁改的控制器开关」时，直接看 Git 提交记录即可，不需要翻数据库操作日志。

6.3 会话级装配示例：一次完整请求的加载序列

把第 4 节和第 5 节的内容串起来，一次完整的 browser-use 会话装配流程是这样的：

1. 用户在 WebUI 里输入一个任务，比如「在 ERP 里查一下库存低于 10 的 SKU，并生成提醒表格」。
2. browser-use 启动浏览器，导航到 ERP 页面。
3. 路由层读取当前页面 URL，判定业务系统为erp，并读取当前用户角色。
4. 装配器读取erp.yaml配置，挂载kb_erp知识库集合，过滤出browser_core、erp_sku_search、erp_stock_query等控制器。
5. 大模型在这个受限的上下文里开始执行任务，每一步都在 ERP 知识库和 ERP 工具集内决策。
6. 如果用户中途说「顺便看看 OA 的会议室」，路由层检测到 URL 变化为 OA，重新触发装配流程，切换知识库与控制器。

这个流程里最关键的一点是第 6 步：动态加载不是一次性的，而是一个随路由状态反复触发的过程。多系统穿梭是真实业务里很常见的需求，如果加载逻辑只在会话开始时执行一次，那跨系统任务还是会出错。所以我们的装配器设计成「订阅路由状态变化」，页面 URL 每变一次就重新评估一次。

7. 踩坑实录：动态加载项目里最常见的五个问题及解法

7.1 知识库“串味”不是检索质量问题，而是边界没有下放

我们最初也怀疑过是 embedding 模型选得不好导致跨域混淆，后来发现根因在配置层：某业务系统的挂载集合里，被人手动多加了一个不属于它的「通用文档集合」。这个集合里正好有几十篇客户合同相关的材料，导致 CRM 场景的检索结果里频繁混入合同条款。排查办法也不复杂——在测试环境里对每个业务系统单独跑一批预设问题，人工检查每道题检索出来的 Top 3 片段是否都落在对应的知识库集合内。发现疑似串味，先查配置，再查检索策略，不要上来就换模型。

7.2 工具同名冲突：换一个函数名拯救一整晚的调试时间

在控制器注册表合并时，我们发现两个子团队分别提交了名称完全相同的send_notification控制器，一个发企业微信通知，一个发邮件通知，allowed_business_systems 还都写了同一个系统。装配器按名称去重时直接覆盖了其中一个，导致模型实际调用的根本不是用户预期的那个。排查了很久才发现是注册表里名称碰撞。这个问题的教训是：控制器注册表必须以全局唯一键为准，不允许同名存在，哪怕功能相似也不许，「发送企业微信通知」和「发送邮件通知」就应该叫两个完全不同的名字。后来我们在注册表加载时加了启动校验，同名直接报错，宁可发布失败也不带着隐患上线。

7.3 工具列表过长依然会发生：公共控制器也要做裁剪

虽然按业务系统过滤后列表短了不少，但公共控制器browser_core里塞了太多通用动作（滑动、截图、缩放、切换 Tab、刷新、后退……），加到一起还是有二十多个。模型在需要「截个图我看下」这种简单操作时，往往会在好几个截图相关的公共工具之间犹豫。解决办法是把公共控制器也做一次「按任务阶段精简」——不是所有任务都需要 Tab 切换能力，装配时可以根据任务的初步意图再收窄一步。比如任务是「查询并整理数据」，就只保留滚轮、截屏、读取表格这几个基础操作，把刷新、后退这类导航类控制器过滤掉。

7.4 路由识别失败：宁可停下来，也不要靠猜

有时页面加载慢，URL 还没变成目标域名，或者单页应用里的路由切换不会改变域名，路由层就会拿不到业务系统标识。一开始我们的兜底逻辑是「取最近一次成功识别的业务系统继续跑」，结果翻过车——用户明明已经跳到了 OA，控制器还停留在 ERP 白名单，模型拿着 ERP 的工具去操作 OA 页面，一顿操作全打在错误元素上。后来改成：识别失败时暂停任务，弹出一个选择框让用户手动确认当前系统。虽然多了一步交互，但准确性提升明显。记住，在 Agent 的世界里，「我不知道」比「我装知道」安全得多。

7.5 重新装配时的上下文残留：旧工具描述要清理干净

动态装配最容易忽略的是上下文清理。我们曾经在系统切换时把新的控制器和知识库配置追加到了 system prompt 里，但旧的控制器描述还留在消息历史中，模型继续看到了两种系统的工具，又把工具点混了。后来我们规定：每次重新装配，system prompt 必须整体重写，历史消息只保留用户问题和 Agent 对页面状态的描述，不保留任何工具列表相关的旧内容。这个细节直接决定跨系统切换的稳定性。

8. 落地效果的验证方法：让每次改动都有数可依

分层定制上线后，验证不能只靠「我觉得效果变好了」。我建议建立一套针对每个业务系统的独立评估集，每条测试用例包含：用户请求、预期知识域、允许使用的控制器范围、预期操作路径。每周跑一遍回归，对比以下指标：

从我们的实测看，分层定制在知识域和工具准确率方面的提升最明显：没做之前，混合知识库和全量控制器状态下，订单查询类任务的正确率大概在 70% 上下；做了按系统动态装配后，单业务系统场景下正确率能到 90% 以上。决策耗时也明显下降，原因是工具列表短了，模型思考负担轻了，上下文里噪声少了。

验证过程中还有一个容易被忽视的点：不要只测「正确任务」，更要测「危险任务」。专门构造一些跨权限请求，比如用销售专员身份请求调用改价控制器，或者在一个系统里请求另一个系统的数据。这类测试才能验证装配器的边界是真的有效，而不是停留在纸面设计上。

最后分享一个持续迭代的思路：把每次「配置变更 + 评估结果」绑定记录到一个统一看板，哪个系统加了新知识库、哪个控制器改了描述、哪次改动导致某个指标下滑，全部有迹可循。我们这个项目做到后面，基本每个季度只需要花一天时间做一次全业务域的回归评估，剩下的时间都在处理新增业务接入的配置工作，而不是在救火。反过来说，如果某天你发现自己的 Agent 项目天天在处理跨域污染、工具点错、权限失控的紧急问题，大概率不是模型不够强，而是缺少了这层「围绕业务系统的动态装配能力」。