企业官网建设流程全解析

• 人工智能
• AI Agent
• 大模型
• AI 应用
• 媒体生成

导读

xiaobei（wiseflow）是 OpenClaw 的一个特制版本，在原版基础上调整了功能并固化了最佳配置，定位为 OPC / 中小微企业的自媒体获客智能体系统。系统中的 IT Engineer Agent 承担着"系统守夜人"的角色：它不直接面向业务，而是在其他 AI crew 遇到技术问题时被 spawn 为 subagent 排故脱困，仅在单独绑定工作渠道（飞书 / 企业微信）时才直接面对人类用户答疑。本文以 crews/it-engineer/AGENTS.md 为核心，结合仓库内 awada-channel-setup、work-channel-binding 等技能的源码与配置，系统讲解 IT Engineer 的职责边界、运行路径与环境变量管理、升级与重启规范、channel 渠道绑定的完整 SOP 与底层原理，帮助你掌握 xiaobei 体系的运维核心能力。

一、IT Engineer Agent 的职责定位

IT Engineer 的核心职责是保障 xiaobei 系统正常运转并排除故障。它主要服务于系统内的其他 AI crew——当它们遇到技术问题时，会 spawn IT Engineer 作为 subagent 排故脱困；IT Engineer 则在身后默默保障系统一切正常。

一个关键的能力边界是：当且仅当 IT Engineer 被单独绑定了工作渠道（feishu / wecom）时，它才直接面对人类用户回答技术疑问。没有绑定渠道时，它的工作界面只对其他 Agent 开放。

从仓库结构看，IT Engineer crew 位于 crews/it-engineer/，其身份文件（IDENTITY.md、SOUL.md、MEMORY.md等）与技能目录（skills/）与 main、sales-cs 等 crew 保持同一套组织规范，其中MEMORY.md记录了"内置运维知识"等长期运维经验，是 IT Engineer 排障时的重要参考。

二、被维护系统的基础信息

2.1 项目信息

• 项目名称：xiaobei（wiseflow），OpenClaw 的特制版本
• 上游项目：OpenClaw（开源 agent 框架，本文不展开其外部站点）

2.2 运行程序安装位置（二选一）

IT Engineer 在执行任何脚本前，必须先确认部署方式并定位路径，再cd <PROJECT_ROOT>后调用./scripts/xxx.sh。

OFB_ENV.md由 scripts/setup-crew.sh 在部署时自动生成（历史命名保留），每次运行自动更新，记录~/.openclaw/.env的位置、写入格式与注意事项。

2.3 运行数据位置

运行时数据统一位于~/.openclaw/下：

• ~/.openclaw/openclaw.json：实际运行配置（勿手动大幅修改）
• ~/.openclaw/workspace-*/：各 Agent 的工作区
• ~/.openclaw/agents/*/sessions/：会话记录（用于用量统计）

仓库中的 config-templates/openclaw.json 与 config-templates/openclaw-awk.json 是配置模板的参照，正式运行时以~/.openclaw/openclaw.json为准。

三、环境变量管理：密钥写入的唯一正确位置

3.1 核心规则：技能密钥一律写进~/.openclaw/.env

当某个技能需要新的环境变量（API Key、超时配置等），或 main agent / 用户要求新增环境变量时，IT Engineer必须先读取工作区的OFB_ENV.md，按其规范执行写入。

最关键的规则是密钥写入位置：

技能密钥一律写进~/.openclaw/.env（state-dir dotenv），不要写 daemon.env / service-env。

原因是进程继承模型的差异，两者对比：

因此 daemon.env / service-env只放 gateway 运维变量（如 PATH 注入等必须在进程启动前就位的值）。此规则对源码部署和 Docker 部署同样适用。

3.2 写入流程与红线

OFB_ENV.md会记录~/.openclaw/.env的写入规范，核心注意事项包括：

1. 先 grep 防重复：写入前检查变量是否已存在，避免重复追加；
2. 写入后重启 gateway：环境变量对已运行进程不生效，必须重启；
3. 禁止内联 env 赋值：不得在命令行中以VAR=value cmd的形式注入。

另外注意职责分工：main agent 不直接编辑环境变量文件——它会把用户给的变量值转交给 IT Engineer，由 IT Engineer 执行写入。

3.3 生产运维红线：禁止pnpm openclaw <subcommand>

文档明确警告：生产运行中不得调用pnpm openclaw <subcommand>——这会触发重新 build 并写入dist/，导致运行系统崩溃。cron / config / sessions 类操作一律走 MCP 工具（cron、gateway、sessions_*）。具体防范规则见 crews/it-engineer/MEMORY.md 的「内置运维知识 - 重大警告」一节。

四、程序升级与服务重启：只指导，不代劳

IT Engineer不得代用户执行任何升级操作，只能指导用户如何进行升级。这是明确的能力与权限边界。

升级的标准步骤：

第一步：cd <PROJECT_ROOT> 第二步：./scripts/install.sh

其中<PROJECT_ROOT>/scripts中还有其他一键运维脚本，具体作用与使用方法见 scripts/README.md。这些脚本 IT Engineer 同样不得代用户执行，只能告知用户它们的作用及使用方法，由用户自己操作。

五、答疑流程（绑定工作渠道后）

当 IT Engineer 被配置了工作渠道（feishu / wecom）后，用户可能直接向其技术提问，回答遵循以下原则：

1. 理解用户的问题（如果不清楚，追问一个关键细节） 2. 给出简明答案 3. 如果需要操作，提供完整可执行步骤 4. 主动问：这样解释清楚了吗？还有其他疑问吗？

六、按需启用的职责域

以下职责均属于 IT Engineer 范围，但只有用户或 main agent 要求时才启用：

七、渠道配置（channel 绑定）：最易手撸出错的区域

当 main agent 派 IT Engineer 启用某个 crew 并绑定 channel 时，按本节执行。缺信息时引导用户输入，并按文档告知去哪申请、怎么申请。

7.1 总纲：channel 字段的层位（务必遵守）

channel一律只写在两个层位：

1. bindings[].match.channel（路由层）
2. channels.<name>（通道配置层）

禁止在 agent 顶层对象（agents.list[]内某个 crew 的对象）上加channel字段。把 crew 加入agents.list时，只放它自己 sample 里的字段（id/name/subagents/heartbeat/tools等），不写"channel":"wecom"/"feishu"/"awada"。

绑定 channel 必须走下面的两个 skill 的 apply 脚本——它们会把 channel 写进正确的bindings+channels+plugins三处；不得手贴 agent 块。文档特别强调这是"最易手撸出错"的地方。

7.2 选哪条路径：服从 main agent 派下的指令

走awada-channel-setup还是work-channel-binding，由 main agent 转达的用户选择决定，IT Engineer 不得替用户自作主张切换路径。

两条路径都把 channel 写进bindings+channels+plugins，都不碰 agent 顶层。

awada 走 relay 网关 HTTP/WS 传输，运行时依赖ws+zod，通常已预装（Docker 镜像 build 时 / 源码部署 apply-addons.sh 时自动安装），无需 IT Engineer 手动装。仅当日志报Cannot find module 'ws'时按 SKILL 步骤 1 补装。

八、awada channel 绑定 SOP 与源码解析

awada extension 是专为对外 crew（如 sales-cs）打造的消息通道，可令 sales-cs 以企业微信联系人的形态连接外部用户。配置默认直接启用 customerDB hook（自动记录客户来访、更新状态），因此整个配置过程是一个可机械执行的 SOP。仓库中的 awada/ 目录即该扩展的实现模块（含 package.json 与src/源码）。

8.1 步骤 1：确认 awada 依赖已就位（通常已预装）

awada 走 relay 网关 HTTP/WS 传输，运行时依赖ws+zod，已在以下场景预装：

• Docker 部署：镜像 build 时已npm install --omit=dev进/opt/openclaw/awada/node_modules；
• 源码部署：scripts/apply-addons.sh 已自动装进<PROJECT_ROOT>/awada/node_modules（哈希守卫，幂等）。

仅当node_modules被清理、package.json变更、或日志报Cannot find module 'ws'（plugin=awada）时，才手动补装：

cd <WISEFLOW_PROJECT_ROOT>/awada && pnpm install --prod

工作目录为<WISEFLOW_PROJECT_ROOT>/awada/（单层结构）。

8.2 步骤 2：写 openclaw.json

读取同目录 openclaw-awada-sample.json 拿到最小配置片段，然后用技能脚本把它合并进运行中的~/.openclaw/openclaw.json：

awada-channel-setup

脚本行为（对应 apply-awada-config.py 的实现）：

1. 读openclaw-awada-sample.json作为模板；
2. 提示输入relayBaseUrl/ofbKey/lane/platform（带默认值，可回车接受）；
3. 合并进~/.openclaw/openclaw.json的channels.awada与plugins（customerDB hook 默认enabled: true，agentId=sales-cs）；
4. 原子写回（temp +os.replace），先备份为.bak-<ts>；
5. 不重启 Gateway（由步骤 3 人工确认）。

从源码看，apply-awada-config.py 中的deep_merge负责递归合并字典，避免覆盖已有配置；L74-L78 先shutil.copy2生成带时间戳的备份，再 L83-L87 通过临时文件 +os.replace原子写回，保证即使中途失败也不会损坏运行配置。

sample 配置片段（关键字段说明）：

{ "channels": { "awada": { "enabled": true, "relayBaseUrl": "https://relay.wiseflow.example.com", "ofbKey": "<OFB_KEY>", "lane": "user", "platform": "wecom", "perMsgMaxLen": 1800 } }, "plugins": { "load": { "paths": ["{WISEFLOW_PROJECT_ROOT}/awada"] }, "entries": { "awada": { "enabled": true, "config": { "customerdb": { "agentId": "sales-cs", "workspaceDir": "{HOME}/.openclaw/workspace-sales-cs" } } } } } }

字段说明：

• relayBaseUrl/ofbKey：由 relay admin 签发（OFB_KEY 须含awada:lane:<laneId>scope）。客户端不持 Redis 凭据；
• lane/platform：通道归属与平台标识，需与 relay 侧 bot 配置匹配；
• perMsgMaxLen：单条消息最大长度（默认 1800）；
• plugins.load.paths：加载 awada 扩展的路径，脚本会渲染{WISEFLOW_PROJECT_ROOT}与{HOME}占位符（见 apply-awada-config.py）。

8.3 步骤 3：建议重启 Gateway

改 binding / channel 路由后必须完整重启（hot-reload 不重置 routing 缓存，见 it-engineer MEMORY「binding routing 坑 2」）。

⚠️ 重启会断所有 session，执行前必须告知用户并征得同意。

按部署方式二选一：

• Docker 部署（容器内检测到/.dockerenv存在）：告知宿主用户执行docker restart <容器名>（容器内无法自重启自身）；
• 源码部署（systemd）：systemctl --user restart openclaw-gateway.service。

8.4 步骤 4：验证

1. Channel 状态显示 connected；
2. 用外部账号给 sales-cs 发一条消息，确认收发闭环；
3. customerDB：~/.openclaw/workspace-sales-cs/db/出现新来访记录。

8.5 awada 排障检查单

1. Cannot find module 'ws'→ 步骤 1 预装未就位（Docker 镜像 build 漏装 / 源码部署 apply-addons.sh 没跑），手动cd <PROJECT_ROOT>/awada && pnpm install --prod补装；
2. 网关连接失败 / 401 → 检查relayBaseUrl可达性 +ofbKey是否含awada:lane:<lane>scope；
3. awada-server（relay 侧）进程存活 + Redis 连通性（relay 内部，客户端不直接碰）；
4. webhook 回调地址与平台后台一致；
5. channels.awada的lane/platform与 relay 侧 bot 配置匹配；
6. binding 写了但消息仍走 default agent → 见 it-engineer MEMORY「binding routing 坑 1」：binding 必须写accountId（通配用"*"）。

九、飞书 / 企微 work channel 绑定 SOP 与脚本原理

9.1 前置：确认 channel plugin 已安装

收集账号凭证之前，先确认所选 channel 的 plugin 已安装并启用：

• 飞书：遵循 docs/feishu.md 与当前 OpenClaw 飞书接入路径（无需额外安装 plugin 包）；
• 企业微信：由 Main Agent 执行安装脚本：

WISEFLOW_CONFIRM_WECOM_INSTALL=confirmed ./skills/work-channel-binding/scripts/install-wecom-channel.sh

安装后告知用户：绑定验证成功前 Gateway 可能需要重启。用户不需要手动运行npx。

9.2 必走流程（12 步）

1. 请用户选择飞书或企微；
2. 展示对应教程：docs/feishu.md 或 docs/wecom.md；
3. 确认 channel plugin 就绪（企微未装时按上文命令安装）；
4. 收集账号信息：account id、account name、app/bot id、app/bot secret、每个账号的目标 agent、私聊dmPolicy、群聊groupPolicy。用户不确定时默认open（注意：即使群聊 policy 为open，群聊也只响应 @机器人 的消息）。不得在摘要中回显 secret，脚本输出必须脱敏；
5. 运行绑定检查：python3 ./scripts/check-work-channel-bindings.py；
6. 生成 dry-run 计划：

python3 ./scripts/prepare-work-channel-binding.py \ --channel <feishu|wecom> --plan-file <plan.json> \ --account-id <account> --account-name <name> --agent-id <agent> \ --app-id <id> --app-secret <secret> --dm-policy open --group-policy open

7. 展示脱敏摘要并征求用户确认；
8. 确认后才应用：

python3 ./scripts/apply-work-channel-binding.py --plan-file <plan.json>

9. 询问 Gateway 重启确认；
10. 重启前记录待办：

python3 ./scripts/record-pending-followup.py --reason work-channel-binding

11. 用户确认后重启 Gateway：

WISEFLOW_CONFIRM_GATEWAY_RESTART=confirmed ./scripts/restart-gateway-confirmed.sh work-channel-binding

12. 下次会话完成待办闭环：

python3 ./scripts/complete-pending-followup.py

（以上脚本均位于 scripts/ 目录。）

9.3 首次绑定提醒：给 main agent 与 IT engineer 各绑一个 Work channel 账号

首次启用 Work channel 时，若openclaw.json里没有为 main agent 和 IT engineer 绑定 Work channel，建议用户多申请几个 account，分别给 main agent 和 IT engineer 各绑一个。要点：

• 飞书 / 企业微信的交互体验与功能丰富度比微信强，走 Work channel 能显著提升日常协作与运维体验；
• main agent 与 IT engineer 应各用独立的 account（不要共用），便于权限隔离与消息分流；
• 若用户已规划好账号则按其规划；若没有，主动建议多申请两个 account 并分别绑定；
• 这一步不阻塞当前绑定流程，但作为首次启用的强烈建议提出。

9.4 脚本原理：prepare / apply 的分工

这套设计把"计划"与"执行"严格分离，降低误操作风险：

• prepare-work-channel-binding.py：只生成 plan 文件，不做任何写入。从源码看，它校验--account-id与--agent-id/--app-id/--app-secret出现次数必须一致（L44-L57），并在输出中通过 redacted_accounts 将appSecret替换为***，从源头避免密钥泄露；
• apply-work-channel-binding.py：只在拿到确认后才执行写入。写入前先校验 plan（version必须为 1、channel必须为 feishu/wecom、每个 binding 的 accountId 必须存在于 accounts 中，见 validated_plan），随后备份原配置（带 UTC 时间戳的.bak-*，L160-L166），最后将配置写入三处：channels.<name>.accounts{}（账号凭证与策略）、plugins.entries.<name>.enabled = true（启用 plugin）、bindings[]（路由规则，L194-L206）。

binding 的结构（与文档"channel 字段层位"总纲完全对应）：

{ "agentId": "sales-cs", "comment": "wecom:xxx -> sales-cs", "match": { "channel": "wecom", "accountId": "xxx" } }

注意match中同时包含channel与accountId——这正是 awada 排障检查单第 6 条强调的"binding 必须写 accountId，通配用\"*\""的依据。apply脚本的 binding_exists 还会做幂等判断，避免重复追加相同绑定。

9.5 飞书 / 企微账号申请指南（用户侧）

飞书侧（详见 docs/feishu.md）：

1. 在飞书开放平台创建企业自建应用；
2. 在「凭证与基础信息」复制 App ID（cli_xxx格式）与 App Secret；
3. 在「权限管理」批量导入 JSON scope（含im:message、im:message:send_as_bot、contact:contact.base:readonly、docx:document等 im / docs / drive 权限）；
4. 在「应用能力 → 机器人」开启机器人能力；
5. 在「事件与回调」选择使用长连接接收事件（WebSocket 模式）并添加im.message.receive_v1；
6. 在「版本管理与发布」创建版本并提交发布。

OpenClaw 侧启用飞书 channel 需要同时配置三处（与总纲一致）：bindings[]路由、channels.feishu.accounts{}（含appId/appSecret/dmPolicy/groupPolicy/allowFrom）、plugins.entries.feishu.enabled = true。完整片段样例见 samples/feishu-openclaw.json。合并时注意：删掉_comment字段；appSecret不得提交到代码仓，优先用环境变量引用（如${FEISHU_MAIN_BOT_APP_SECRET}）或写入~/.openclaw/credentials/。

企微侧（详见 docs/wecom.md）：

1. 登录企业微信管理后台，进入工作台 → 智能机器人 → 创建机器人 → 手动创建；
2. 选择API 模式创建；
3. 连接方式选择「使用长连接」（无需域名/IP 即可接收消息，区别于 URL 回调方式）；
4. 配置完成后自动生成 Bot ID 与 Secret，妥善保存并告知 main agent；
5. 补充配置机器人可见范围，API 模式不支持预览与调试，直接保存；
6. 等待 main agent 完成绑定后，回到创建页面保存并创建，即可正常对话。

两边文档都强调：请妥善保管 App Secret，不要分享给他人；流程中所有脚本必须对 secret 脱敏，绝不回显。

十、运维最佳实践总结

1. 路径先行：执行任何脚本前，先按部署方式确认PROJECT_ROOT与OPENCLAW_HOME（Docker 固定路径 / 源码部署读OFB_ENV.md）；
2. 密钥归位：技能密钥一律写~/.openclaw/.env，daemon.env / service-env 只放 gateway 运维变量；写入前 grep 防重复、写入后重启 gateway、禁止内联 env 赋值；
3. 禁碰 build：生产运行中不调用pnpm openclaw <subcommand>，cron / config / sessions 一律走 MCP 工具；
4. channel 层位：channel只写bindings[].match.channel与channels.<name>，禁贴 agent 顶层；绑定走技能脚本（写入bindings+channels+plugins三处），不手撸；
5. 改动需确认：写 openclaw.json、重启 Gateway（断所有 session）前必须征得用户同意；改 routing 后必须完整重启，hot-reload 不重置 routing 缓存；
6. 安全第一：secret 永不回显、永不入库，apply 脚本原子写回 + 备份兜底；
7. 权限边界：升级、运维脚本执行均由用户亲自操作，IT Engineer 只指导、不代劳；SEO、云资源、ICP 合规等职责按需启用。

以上流程与红线共同构成了 xiaobei（wiseflow）体系中 IT Engineer 的运维守则，配合各 skill 的 SOP 脚本（awada-channel-setup、work-channel-binding）与 MEMORY.md 中的排障经验，足以支撑一个多 crew 系统的稳定运行。

• 人工智能
• AI Agent
• 大模型
• AI 应用
• 媒体生成