ThinkDE 内审数字员工 · 客户实施与使用指南

1.1 您将获得什么

平台升级到 0.3.0 并完成初始化后，系统会自动为您装配一位开箱即用的数字员工与一整套内审能力资产：

1.2 一张图看懂业务闭环

1.3 内置资产清单（升级后自动入库）

1.4 建议阅读路径

• 最终客户：第 2 章快速上手 → 第 4 章认识内审资产 → 第 5/6/7 章按您的业务线逐条实施 → 第 8 章用 AIRPA 打通业务系统取数 → 第 10 章 FAQ。
• FED 工程师：第 3 章安装与升级（含补丁命令、skills 目录、健康检查）→ 第 8 章 AIRPA 无侵入对接 → 第 9 章技能与 MCP 集成详解 → 第 10 章边界与回滚。

3.1 部署形态速览

3.2 全新安装（一键安装包）

全新环境使用官网发布页提供的一键安装包（当前版本 0.3.0），按包内 install.sh 引导执行即可。安装包已内置全部内审技能包，安装完成后首次启动即自动种子入库，可直接跳到 3.5 验证。

3.3 存量环境升级到 0.3.0（补丁包）

cd /root
aria2c -x16 -s16 -o thinkde-patch-0.3.0.tar.gz \
  "https://<发布服务器>/downloads/thinkde-patch-0.3.0.tar.gz"

# 校验 SHA256，必须完全一致才允许继续
sha256sum thinkde-patch-0.3.0.tar.gz
# 期望值：5b32db756e9cdbb9e8ca437223b361d6be1db2ef4d5801ddc1214b0e1a90140e

tar -xzf thinkde-patch-0.3.0.tar.gz
cd thinkde-patch-0.3.0
bash install-patch.sh --dir /opt/thinkde --service thinkde --port 8500 2>&1 | tee /root/patch-0.3.0.log

# 在实施机上打包仓库内的 skills 目录并上传
tar -czf skills-0.3.0.tar.gz skills/
scp -i ~/.ssh/<key>.pem skills-0.3.0.tar.gz root@<服务器IP>:/root/

# 服务器上解包到安装目录
cd /opt/thinkde
tar -xzf /root/skills-0.3.0.tar.gz          # 得到 /opt/thinkde/skills/…
chown -R thinkde:thinkde /opt/thinkde/skills
ls skills/
# 应看到：policy-compliance-check  contract-backdating-check  thinkde-api-* 等

systemctl restart thinkde
sleep 8
systemctl status thinkde --no-pager -l | head -n 12
curl -s http://127.0.0.1:8500/api/app/version

3.4 许可激活

全新安装或换机迁移后，需在许可激活页录入产品序列号（SN，形如 THINKDE-XXXX-XXXX-XXXX）完成激活；激活页会显示有效期。补丁升级不影响已有激活状态。

3.5 升级后验证清单（逐项打勾）

# 1) 版本应为 0.3.0
curl -s http://127.0.0.1:8500/api/app/version

# 2) 内审实体入库核验（SQLite，注意表名为复数形式）
sqlite3 /opt/thinkde/data/thinkde.db "
SELECT id,name,status FROM agent_profiles WHERE id LIKE '%internal_audit%';
SELECT slug,name,status FROM general_skills WHERE slug IN ('policy-compliance-check','contract-backdating-check');
SELECT name,bucket,tool_type,enabled FROM tools WHERE bucket='内审·合规审查';
SELECT id,name,status FROM skills WHERE id IN ('policy_compliance_audit','contract_backdating_audit');
SELECT resource_type,COUNT(*) FROM agent_resource_bindings GROUP BY resource_type;
SELECT name,enabled FROM mcp_servers;"

UI 侧核验：登录管理端，确认模型页已有可用模型（内审引擎为确定性脚本不依赖大模型，但对话派活的调度需要）：

3.6 失败回滚

install-patch.sh 在安装过程中任一步失败会自动回滚到补丁前状态。如需手动回滚：备份包位于 /opt/thinkde/backup/pre-patch-<时间戳>.tar.gz，停止服务 → 解开备份覆盖 → 重启即可。

systemctl stop thinkde
cd /opt/thinkde
tar -xzf backup/pre-patch-<时间戳>.tar.gz
chown -R thinkde:thinkde /opt/thinkde
systemctl start thinkde
curl -s http://127.0.0.1:8500/api/app/version   # 应回到旧版本

3.7 本指南页面自身的部署（FED 备注）

本 guide.html 及 guide/ 截图目录位于前端构建产物 frontend-enterprise/dist/ 中，由后端 single_port_app.py 的显式路由提供服务（/guide.html 页面 + /guide 静态目录挂载）。更新指南只需替换 dist 下对应文件并重启服务，无需重新构建前端。

4.1 技能：确定性审查引擎

路径：管理端›技能（/enterprise/general-skills）

技能列表可见两个内审技能包，状态均为已发布（published）：

通过操作菜单的「编辑本地版本」进入技能详情页，可以看到技能包的完整文件树（SKILL.md 说明书、rules/ 规则包、sample/ 样例输入、scripts/ 判定脚本、sop/ 流程定义），以及右侧的运行测试面板 —— 这是对技能做实测验证的官方入口（详见 第 9 章）。

4.2 SOP：把审查串成自动化流程

路径：管理端›流程（/enterprise/skills）

进入流程详情可看到可视化流程图。以制度符合性 SOP 为例，节点链路为：

4.3 工具：对话调用的入口

路径：管理端›工具（/enterprise/tools）

两个内审工具的 URL 形如 general_skill://policy-compliance-check/scripts/check_compliance.py，类型为 general_skill —— 即「把技能脚本注册为可被数字员工调用的工具」。对话派活时，数字员工正是通过这两个工具触发确定性脚本。

4.4 绑定关系与开放广场

「法务·内审合规数字员工」的资源绑定如下（可在数据库 agent_resource_bindings 表核对，FED）：

同时，上述技能 / 流程 / 工具均已上架开放广场，供其他数字员工按权限发现与复用：

4.5 能力包 IA-030 · 对话框一键引入

如果升级后员工列表里没有「法务·内审合规数字员工」，或您想把内审技能/工具/SOP 直接配给某位现有员工（如财务专员），无需重启服务、无需上传文件 —— 在该员工的对话框里发送能力包号即可：

IA-030

也支持带前缀动词的写法：引入 IA-030、导入能力包 IA-030、安装 IA-030 等。系统不经过大模型，直接完成装配并回复回执：

• 幂等装配内审数字员工 + 2 技能 + 2 工具 + 2 SOP（已存在的资产不重复创建，您在界面上的改动全部保留）；
• 把技能/工具/SOP 绑定到当前对话员工，回执会列出资产清单与绑定说明；
• 引入后即可直接派活，例如「帮我审查这批报销记录是否符合制度」。

4.6 对话内管理员沉淀 · 生成 / 挂载 / 发布（0.3.2）

管理员登录后可直接在任意数字员工对话框里让系统生成 SOP / 技能 / MCP 服务 / 知识库，并沉淀挂载到当前员工、按需发布到开放能力广场。这是受限编排：管理员发固定指令、走确定性流程，模型不会自主决定挂什么或发什么；且全程采用两阶段确认——先生成草稿预览、再由管理员凭令牌确认落地。

预览回执会给出一个一次性确认令牌（约 15 分钟内有效）。示例：

沉淀SOP 每月按制度审查报销单据的合规性
确认沉淀 AbC123dEf4 发广场

5.1 第一步 · 建立制度知识库

路径：管理端›知识库（/enterprise/knowledge）

1

知识库页点击新建知识库，命名如「报销管理制度」「合同审查标准清单」，逐库上传制度原文（Word / PDF / Markdown 均可），等待解析入库完成。

5.2 第二步 · 接入业务数据源（FED）

审查需要「审计主体」数据（报销单、合同台账等）。数据来源有三种接入方式，按客户信息化程度选择：

5.3 第三步 · SOP 节点装配（知识库引用 + 取数工具）

路径：管理端›流程›制度符合性对比审查›全屏 → 点击节点

1

在流程图页面点全屏，再点击 report_violations 节点，右侧滑出「编辑节点」面板。在知识库引用区勾选第 5.1 步建好的制度库 —— 这样违规报告会引用您自己的制度原文。

5.4 第四步 · 对话派活（真实实测记录）

回到「法务·内审合规数字员工」对话页，直接下达任务。以下是生产环境实测的派活与执行过程：

请按报销管理制度对以下报销单做制度符合性审查，输出结论表：
张三·差旅报销：发票合规，发生后10天提交，金额3000元，住宿600元/晚
李四·差旅报销：发票合规，发生后45天提交，金额3000元，住宿950元/晚

数字员工自动执行了一条完整动作链（对话中每一步可见、可审计）：

5.5 第五步 · 读懂四态结论

主体级状态汇总规则：有任一「疑似违规」→ 主体疑似违规；否则有「待人工复核」→ 主体待人工复核；否则符合。

5.6 第六步 · 自定义规则扩展（客户制度 → 新规则包）

「不同业务有不同监督检查体系」的落点：新增一个监督体系 = 在技能的 rules/ 目录放一个新规则包 JSON，纯数据、不改脚本。步骤：

{
  "rule_id": "R-RB-04",
  "domain": "报销合规",
  "title": "差旅住宿报销不得超过标准限额(800元/晚)",
  "severity": "medium",
  "basis": "《报销管理制度》：差旅住宿费按职级限额报销，超标部分自理",
  "applies_when": {"type": "enum_in", "field": "expense_type", "allowed": ["差旅", "出差"]},
  "check": {"type": "threshold", "field": "lodging_per_night", "op": "<=", "value": 800}
}

6.1 内置规则包 reimbursement（5 条规则）

6.2 输入数据格式（审计主体 JSON）

每张报销单是一个「主体」，要素放在 attrs 里。以下为技能包内置样例（节选 3 条，覆盖典型情形）：

{
  "rule_packs": ["reimbursement"],
  "subjects": [
    { "subject_id": "RB-2026-01", "name": "张三·差旅报销",
      "attrs": { "expense_type": "差旅", "has_valid_invoice": true, "submit_days": 10,
                 "amount_yuan": 3000, "lodging_per_night": 600 } },
    { "subject_id": "RB-2026-02", "name": "李四·差旅报销",
      "attrs": { "expense_type": "差旅", "has_valid_invoice": true, "submit_days": 45,
                 "amount_yuan": 3000, "lodging_per_night": 950 } },
    { "subject_id": "RB-2026-05", "name": "孙七·差旅报销",
      "attrs": { "expense_type": "差旅", "has_valid_invoice": true, "submit_days": null,
                 "amount_yuan": 6000, "manager_approved": true, "lodging_per_night": null } }
  ]
}

• 布尔字段接受 true/false、"是"/"否"、"有"/"无"、1/0 等常见写法；无法判定的一律转「待人工复核」。
• 字段缺失（如孙七的 submit_days: null）不会被补默认值，对应规则直接判「待人工复核」。
• 对话派活时不必手写 JSON —— 用自然语言描述单据要素，数字员工自动组装（见 5.4 实测）。

6.3 运行测试（技能编辑页实测）

1

进入 技能 → 制度符合性对比审查 → 编辑本地版本，右侧「运行测试」面板粘贴上面的输入 JSON，点击运行：

6.4 上线校准清单（客户 + FED 共同确认）

校准操作即修改 rules/reimbursement.rules.json 中的数值与 basis 文案，方法见 5.6；改完在运行测试面板回归一遍样例即可。

7.1 能力一 · 合同条款合规（contract_review 规则包，5 条规则）

该规则包依据法务知识库真实条款编写（非模板包），另内置 data_compliance 数据合规规则包（分级、单独同意、PIA/DPA、出境备案）。使用方式与第 5 章完全一致 —— 对话派活时说明「按合同审查规则包检查这些合同」即可：

{
  "rule_packs": ["contract_review"],
  "subjects": [
    { "subject_id": "HT-2026-101", "name": "示例船务A·运力租赁合同",
      "attrs": { "amount_wan": 50, "review_days": 2, "has_dispute_clause": true,
                 "has_confidentiality_clause": true, "counterparty_blacklisted": false } }
  ]
}

7.2 能力二 · 合同倒签专项检查（T1/T2/T3 日期时序）

倒签检查是独立技能 contract-backdating-check，判定规则固定且不可篡改：

• 三个关键日期：T1 审批结束日 / T2 合同签订日 / T3 履约起始日。
• 日期传字符串即可，YYYY-MM-DD、YYYY/MM/DD、YYYY年MM月DD日 均可解析；不要传时间戳数字（时区歧义会判待人工复核）。
• tolerance_days 容差参数：差值大于容差才计入倒签（默认 0，早一天就算）。
• 字段兼容中文键：合同编号 / 所属公司 / 审批结束日期 / 合同签订日期 / 履约起始日。

{
  "tolerance_days": 0,
  "contracts": [
    { "contract_id": "HT-2026-001", "company": "示例船务A",
      "t1_approval_end": "2026-03-10", "t2_signing": "2026-03-05",
      "t3_performance_start": "2026-03-20" },   // 先签后审：T2 早于 T1 五天
    { "contract_id": "HT-2026-004", "company": "示例港口C",
      "t1_approval_end": "2026-06-01", "t2_signing": "2026-06-10",
      "t3_performance_start": null }            // 缺 T3 → 待人工复核
  ]
}

输出为结构化结论：每份合同给出 verdict（疑似倒签 / 未发现倒签 / 待人工复核）、backdating_types、gap_days（相差天数）与 evidence 证据文案（如「签订日 2026-03-05 早于审批结束日 2026-03-10（相差 5 天）」），汇总 backdating_count / need_review_count / clean_count。

7.3 倒签 SOP 流程与台账接入（FED）

合同倒签 SOP（contract_backdating_audit）节点链路：

fetch_dates 节点声明依赖工具 contract.archive_query。FED 接入客户合同台账的推荐做法：

1. 与客户确认合同系统取数途径：API / 数据库视图 / 网页（AIRPA 抓取）/ 定期导出 Excel。
2. 将其注册为工具（工具页「注册工具」，HTTP API 型）或 MCP Server（见 第 9 章），命名为 contract.archive_query 以匹配 SOP 节点声明；若合同系统是网页型老系统，推荐直接用 第 8 章 AIRPA 无侵入取数。
3. 输出字段对齐输入契约：contract_id / company / t1_approval_end / t2_signing / t3_performance_start（或对应中文键）。
4. 在 SOP 的 fetch_dates 节点编辑面板确认工具绑定，随后用一小批真实台账做端到端联调。

未接入台账前，客户可直接在对话中粘贴合同日期清单派活（同 5.4 方式），倒签判定能力完全一致。

8.1 为什么叫「无侵入」

传统对接要业务系统开 API、改库、做中间层，周期长且动生产。AIRPA 探索核已融合进 ThinkDE 进程内，用 Playwright 驱动真实浏览器、以您自己的登录会话去探索和操作业务系统页面 —— 对业务系统而言，它只是一个「会自己点页面的用户」，因此零改造、零接口依赖。

8.2 三步接入（官方链路）

1

① 自然语言探索（仅管理员）：路径 管理端›AIRPA业务接入。选通道（页面探索 / API 直通），填三要素后点「开始探索」：

字段	填什么	内审场景示例
目标系统名称	业务系统叫法	报销填报系统 / 合同台账系统
目标系统 URL	登录页或 base URL	https://erp.example.com
账号密码（可选）	用于登录后深度探索	给一个只读查询账号最稳妥
需求描述	一句话说清要什么功能	我要接入报销系统，需要报销单列表查询和明细导出功能

探索核自动执行：建系统 → 连通探测 → 页面结构/接口探索 → AI 解读（分钟级，请耐心等待），浏览器实时画面与日志同步呈现。结束后给出「识别出 N 个页面、M 项功能」。

8.3 内审闭环：用 AIRPA 查找业务系统里的问题

AIRPA 只负责「把数据取出来」，「判断有没有问题」交给第 5/6/7 章的确定性引擎。两者串起来才是完整的内审闭环：

请用报销系统的查询工具，拉取 2026-08 全部报销单，
按报销合规规则包逐条审查，输出疑似违规清单和依据。

8.4 已接入实例与验证

示例环境已用 AIRPA 接入 AIRPA·csic（系统 #4，MCP 端点 airpa:4，6 个工具，状态已启用），可在「已接入的业务系统」表格看到，并在工具页 AIRPA 分组、调试台验证（截图见 8.2）。验证闭环最简方式：对已绑该工具的员工派活一句查询指令，观察逐步执行回执与返回数据。

8.5 边界与注意事项（FED）

• 权限：探索与发布接口仅管理员可调用（非管理员 403）；普通员工只能使用已发布的工具。
• 耗时：探索为分钟级（含浏览器登录与站内实爬），页面有验证码时可能转人工兜底，属正常。
• 改版失效：连接器是「确定性步骤回放」，业务系统改版后回放可能失败 —— 到「已接入的业务系统」点「刷新工具」重新探索发布即可。
• 操作范围：回放会真实操作业务系统页面。内审取数请优先只勾选查询/导出类功能，避免误触写操作；确需写操作请先与客户确认范围。
• 凭据：目标系统凭据加密入库；解密失败会如实报错（不静默）。建议为 AIRPA 单独开只读账号。
• 凭据错误快速失败：e2e 实测确认 —— 目标系统密码错误时，连接器回放会显式报「登录未生效」并终止，绝不静默返回成功；修正凭据后重新派活或「刷新工具」即可。
• 降级：服务器未装 Chromium 且未配 browserless 时，引擎降级 HTTP 语义探测并在结果中如实标注 mode，不会假装是浏览器回放。

9.1 技能包文件结构（SKILL.md 规范）

每个技能包是一个目录，位于服务器 /opt/thinkde/skills/（仓库 skills/）。以内审两包为例：

skills/
├── policy-compliance-check/            # 制度符合性对比审查
│   ├── SKILL.md                        # 技能说明书：frontmatter(name/description/allowed-tools) + 运行方式 + 契约 + 判定规则 + 边界
│   ├── rules/                          # 规则包（纯数据 JSON）
│   │   ├── contract_review.rules.json
│   │   ├── data_compliance.rules.json
│   │   ├── finance_compliance.rules.json
│   │   └── reimbursement.rules.json
│   ├── sample/                         # 各规则包的样例输入（可直接回归测试）
│   ├── scripts/check_compliance.py     # 判定引擎（唯一权威逻辑，勿改写）
│   └── sop/policy_compliance_audit.sop.json
└── contract-backdating-check/          # 合同倒签检查
    ├── SKILL.md
    ├── sample/contract_ledger_sample.json
    ├── scripts/check_backdating.py
    └── sop/contract_backdating_audit.sop.json

• SKILL.md frontmatter：name（=工具注册的 slug）、description（数字员工 capability_search 检索的依据，写清「输入什么、怎么判、不做什么」）、allowed-tools。
• 运行约定：脚本从 stdin 读一个 JSON 对象，向 stdout 写一个 JSON 对象（UTF-8）。工具 URL 形如 general_skill://policy-compliance-check/scripts/check_compliance.py。
• 确定性铁律：判定逻辑固定在脚本内，不允许大模型改写或凭推断下结论；缺数据判「待人工复核」，绝不猜测或补默认值；空输入返回零计数不报错。

9.2 运行测试（官方实测入口）

1

技能 → 目标技能 → 操作菜单「编辑本地版本」→ 右侧「运行测试」面板：粘贴 stdin JSON → 运行 → 查看 stdout 结构化结果。这是验证技能改动（如校准规则阈值）的标准回归手段。

服务器命令行自测（FED）：

bash

复制

cd /opt/thinkde/skills/policy-compliance-check
python3 scripts/check_compliance.py < sample/subjects_reimbursement_sample.json

cd /opt/thinkde/skills/contract-backdating-check
python3 scripts/check_backdating.py < sample/contract_ledger_sample.json

9.3 输出契约要点（对接方必读）

9.4 MCP Server 注册（四种接入类型）

路径：管理端›工具›注册 MCP / 工具

示例环境已注册并启用：builtin_demo（内置演示）、stdio_demo（本地命令演示）、airpa-4-csic（AIRPA 浏览器自动化，6 个工具）。FED 交付时可按客户集成需要增删。

9.5 已知限制 · 工具页测试面板

!

工具列表页对单个工具的「测试」面板，当前不支持 general_skill 类型，点击测试会返回：

实测返回

复制

UNSUPPORTED_TOOL_TYPE: general_skill

替代方案：技能实测一律走 9.2 的技能编辑页「运行测试」面板；对话链路验证直接对数字员工派活（5.4）。

10.1 判定与结论

10.2 规则与制度

10.3 平台使用

10.4 运维（FED）