别让 AI 直接点 OA 网页：用受控 CLI 让 OA 更快、更稳、更安全（可审计、可幂等）

每天早上9点，某公司行政部的小张都要处理近20条请假申请核对------员工们在OA网页上填错日期、漏选假种、忘记附理由是常事；而研发部的小李，为了把"每月考勤对账"接入自动化流程，写了一堆浏览器脚本，结果OA前端一改版，脚本全部失效，还要重新调试DOM元素；更糟的是，尝试让AI协助处理审批的团队，曾因AI误点"驳回并归档"按钮，导致3条重要的加班调休申请被错误处理，复盘了整整两天。

这就是多数企业OA系统的现状：对人可用，对自动化/AI极不友好。员工手工操作能完成的登录、查余额、提请假、看审批，一旦想接入自动化或AI，就会暴露底层能力未抽象、操作不可控、风险无边界的核心问题。

1. 操作高度依赖人工，重复且易出错

• 场景：某企业3000名员工，每人每月平均2次OA操作（查假、提请假、查审批），累计每月6000次重复操作；其中15%的操作因人工填错字段（如日期格式、假种选择）需要返工，每月额外消耗120人/小时。
• 本质：登录、跳转、填表、确认全是"人肉步骤"，效率低且稳定性完全依赖人的细心程度。

2. 系统能力无抽象，对外是"黑盒"

OA的核心能力（如请假提交、审批流转）藏在网页交互背后，外部无法获取稳定、可复用、可组合的接口语义：

• 对人：是"点页面、填表单"的直观操作；
• 对系统/AI：是DOM节点、按钮点击、页面跳转的无序组合，没有"提交请假申请""查询年假余额"这类业务级语义。

3. 网页自动化≠系统化接入

很多团队用Selenium/Puppeteer做网页自动化，或让AI直接控制浏览器，看似解决了"自动操作"，但存在致命问题：

• 脆弱性：前端结构（如按钮ID、表单字段名）一改，自动化链路直接失效；
• 无管控：权限校验、幂等保护、误操作兜底、审计追踪全靠脚本开发者自行实现，极易遗漏；
• 不可控：AI无法区分"可逆操作（查余额）"和"不可逆操作（提交审批）"，误操作代价极高。

4. 高风险动作缺乏边界

查询类操作（查假种、余额）风险低，但审批、提单、驳回等动作一旦误触发，影响的是真实业务单据：

核心架构对比

反模式（脆弱且高风险）：

最优解（稳定且可控）：

为什么要先做oa-cli？

oa-cli 不是"换个方式点网页"，而是把OA高频动作抽象成稳定、可治理、带管控的命令，收拢页面分散的流程、字段、校验和异常处理能力。

基础 CLI 命令示例（完整场景）

# 认证相关oa-cli auth login --username zhangsan --password-env OA_PWD  # 密码从环境变量读取，避免明文oa-cli auth status  # 输出JSON格式的登录状态oa-cli auth logout --clean-cache  # 登出并清理本地会话缓存# 请假相关oa-cli leave types  # 查询所有可用假种（年假/事假/病假等）oa-cli leave balance --type annual  # 查询年假余额oa-cli leave list --start 2026-01-01 --end 2026-04-01  # 查询指定时间段请假记录oa-cli leave preview --type annual --start "2026-04-10 09:00" --end "2026-04-10 18:00" --reason "事假"  # 预览提交结果（无实际提交）oa-cli leave submit --type annual --start "2026-04-10 09:00" --end "2026-04-10 18:00" --reason "事假" --confirm --dry-run=false  # 确认提交（--dry-run=true时仅预览）oa-cli leave cancel --apply-id 12345 --confirm  # 撤销请假申请（高风险操作需确认）

CLI 带来的三大核心收益

1. 操作结构化：

人、脚本、AI面对的是统一参数（如日期格式、假种枚举）和结构化输出（JSON），而非不确定的网页交互；

• 示例输出：oa-cli leave balance --type annual*

  {  "code": 0,  "msg": "success",  "data": {    "employee_id": "10086",    "annual_leave_total": 10,    "annual_leave_used": 3,    "annual_leave_remaining": 7,    "update_time": "2026-04-01 15:30:00"  }}

2. 管控能力内置：

工具层统一实现关键管控，无需使用者自行处理：

• --dry-run：预览操作结果，无实际提交；
• --confirm：高风险操作强制人工确认；
• 幂等保护：重复提交同一请假申请（相同apply-id）自动过滤；
• 日志留痕：所有命令执行记录（用户、时间、参数、结果）落地；
• 会话过期检测：自动识别登录态失效，触发重新登录；

3. AI 接入有边界：

AI仅能调用白名单命令，高风险动作（如提交、撤销、审批）保留人工确认门槛，杜绝无约束操作。

如果跳过CLI层，直接让AI对接OA网页/底层接口，只会放大现有问题：

这类系统最怕"一步到位做平台"，更高效的方式是按阶段落地，每个阶段聚焦"最小闭环"：

Stage 0：技术路径摸底（1-2天）

核心目标：明确OA的技术细节，决定Stage 1的接入方式（API/浏览器自动化）。

需确认的关键信息：

Stage 1：登录+请假闭环（3-5天）

核心目标 ：跑通"登录→查假→提请假"的最小闭环，产出可用的oa-cli基础版本。

核心功能&实操代码示例：

1. 认证模块（Python伪代码）：

# oa_cli/auth.pyimport jsonimport osimport cryptography.fernet  # 加密存储会话信息from requests import Sessiondef login(username: str, password: str) -> dict:    """登录OA，返回会话信息并加密存储到本地"""    sess = Session()    # 1. 对接OA登录接口（优先）或用Playwright模拟登录（兜底）    login_res = sess.post("https://oa.example.com/api/login", data={        "username": username,        "password": password,        "csrf_token": get_csrf_token(sess)  # 抓取页面CSRF Token    })    # 2. 验证登录结果    if login_res.json()["code"] != 0:        raise Exception(f"登录失败：{login_res.json()['msg']}")    # 3. 加密存储会话信息（Cookie/Token）    cipher = cryptography.fernet.Fernet(os.getenv("OA_CLI_SECRET_KEY"))    session_data = json.dumps(dict(sess.cookies))    with open("~/.oa-cli/session", "wb") as f:        f.write(cipher.encrypt(session_data.encode()))    return {"code": 0, "msg": "登录成功"}def status() -> dict:    """检查登录状态"""    # 解密读取本地会话，调用OA状态接口    # ... 省略实现 ...    return {"code": 0, "data": {"is_login": True, "expire_time": "2026-04-10 23:59:00"}}

2. 请假模块：

实现leave types/balance/preview/submit命令，内置--dry-run预览、--confirm确认逻辑；

3. 本地存储：

用加密方式存储会话信息（避免明文密码/Token泄露）；

4. 错误处理：

标准化错误码（如1001=登录失效、2001=年假余额不足），便于排查问题。

Stage 2：从个人工具升级为流程工具（1-2周）

核心目标：补充审批相关能力，完善审计日志，支持团队级使用。

新增功能：

• 审批待办查询：oa-cli approval list --pending；
• 审批操作：oa-cli approval approve --id 12345 --comment "同意" --confirm；
• 全量操作审计：所有CLI命令执行记录同步到企业日志平台（如ELK），包含用户、时间、参数、结果；
• 权限校验：CLI层校验操作人是否有审批权限（如仅部门经理可审批本部门请假）。

Stage 3：开放给AI（1周）

核心目标：将CLI封装为AI可调用的接口，限定AI的操作边界。

落地方式：

1. 封装MCP Server（Model Context Protocol）：将CLI命令封装为AI可识别的工具接口，定义参数约束；
2. 白名单管控：仅向AI开放"查询类"（查余额/假种）和"预览类"（请假预览）命令，提交/审批类命令需人工确认；
3. 交互模板：AI调用CLI后，返回结构化结果+人工友好的总结（如"你的年假余额为7天，2026-04-10请假1天的预览已生成，确认提交请回复【确认】"）。

Stage 4：生产化与治理（2-3周）

核心目标：补齐企业级治理能力，从PoC升级为生产级工具。

核心治理能力：

• 权限隔离：基于RBAC控制不同用户可执行的CLI命令（如普通员工仅能提请假，经理可审批）；
• 敏感信息脱敏：日志/输出中脱敏手机号、工号等敏感信息；
• 错误码体系：完善全局错误码（如1xxx=认证错误、2xxx=请假错误、3xxx=审批错误）；
• 限流与重试：对高频命令（如leave balance）做限流，对临时接口失败自动重试；
• 自动化测试：编写单元测试（CLI逻辑）+集成测试（对接OA真实环境）。

CLI 层的核心设计原则

1. 优先复用原生接口：优先对接OA现有开放API/前端内部接口（如请假提交的AJAX接口），浏览器自动化仅作为无接口时的兜底方案；
2. 输出结构化JSON ：所有命令默认输出JSON，便于脚本/AI解析，仅通过--human参数输出人类友好的文本；
3. 高风险动作强管控 ：提交、审批、撤销等动作必须包含--confirm强制确认、操作日志审计、基于请求ID的幂等保护；
4. AI 仅能调用高层命令：AI看不到DOM、按钮、接口参数，只能调用"查询余额""预览请假""提交请假"等业务级命令。

• 效率提升：员工请假相关操作耗时从平均5分钟/次降至30秒/次，团队每月节省80+人/小时；
• 错误率降低：请假申请填错字段的比例从15%降至1%以下；
• 风险可控：未再发生AI/脚本误操作导致的审批异常，所有高风险操作可追溯、可回滚；
• 可扩展性：基于CLI快速接入了加班申请、出差审批等新能力，适配周期从1周缩短至1天。

一个只能被"人工点击"的OA系统，永远无法真正融入企业自动化/AI协作体系。

我们不是要"让AI代替人操作OA"，而是要先把OA的核心能力从"网页交互"收敛成"可复用、可管控、可审计的CLI工具"，再让AI在这个安全边界内发挥价值。

这套思路的核心不是技术多先进，而是先解决"可控性"，再解决"智能化" ------承认传统OA的复杂性，不把AI当"万能胶"，而是通过工程化的方式，让OA能力真正成为企业可复用的数字化资产。