引言：OA 自动化的真实困境
每天早上9点，某公司行政部的小张都要处理近20条请假申请核对——员工们在OA网页上填错日期、漏选假种、忘记附理由是常事；而研发部的小李，为了把“每月考勤对账”接入自动化流程，写了一堆浏览器脚本，结果OA前端一改版，脚本全部失效，还要重新调试DOM元素；更糟的是，尝试让AI协助处理审批的团队，曾因AI误点“驳回并归档”按钮，导致3条重要的加班调休申请被错误处理，复盘了整整两天。
这就是多数企业OA系统的现状：对人可用，对自动化/AI极不友好。员工手工操作能完成的登录、查余额、提请假、看审批，一旦想接入自动化或AI，就会暴露底层能力未抽象、操作不可控、风险无边界的核心问题。
一、OA 自动化的四大核心痛点
1. 操作高度依赖人工，重复且易出错
- 场景：某企业3000名员工，每人每月平均2次OA操作（查假、提请假、查审批），累计每月6000次重复操作；其中15%的操作因人工填错字段（如日期格式、假种选择）需要返工，每月额外消耗120人/小时。
- 本质：登录、跳转、填表、确认全是“人肉步骤”，效率低且稳定性完全依赖人的细心程度。
2. 系统能力无抽象，对外是“黑盒”
OA的核心能力（如请假提交、审批流转）藏在网页交互背后，外部无法获取稳定、可复用、可组合的接口语义：
- 对人：是“点页面、填表单”的直观操作；
- 对系统/AI：是DOM节点、按钮点击、页面跳转的无序组合，没有“提交请假申请”“查询年假余额”这类业务级语义。
3. 网页自动化≠系统化接入
很多团队用Selenium/Puppeteer做网页自动化，或让AI直接控制浏览器，看似解决了“自动操作”，但存在致命问题：
- 脆弱性：前端结构（如按钮ID、表单字段名）一改，自动化链路直接失效；
- 无管控：权限校验、幂等保护、误操作兜底、审计追踪全靠脚本开发者自行实现，极易遗漏；
- 不可控：AI无法区分“可逆操作（查余额）”和“不可逆操作（提交审批）”，误操作代价极高。
4. 高风险动作缺乏边界
查询类操作（查假种、余额）风险低，但审批、提单、驳回等动作一旦误触发，影响的是真实业务单据：
二、更稳妥的解法：AI 不碰网页，只调用受控 CLI 工具
核心架构对比
反模式（脆弱且高风险）：
最优解（稳定且可控）：
为什么要先做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”更重要？
如果跳过CLI层，直接让AI对接OA网页/底层接口，只会放大现有问题：
| 对接方式 | 稳定性 | 可管控性 | 误操作风险 | 可维护性 |
|---|---|---|---|---|
| AI 直接控制浏览器 | 极低（前端改版即失效） | 无（无法管控AI点击行为） | 极高（不可逆操作易误触发） | 极低（需适配DOM/页面逻辑） |
| AI 调用底层接口 | 中（接口变更需适配） | 低（需手动管控参数/权限） | 中（参数错误易导致业务异常） | 中（需维护接口签名/参数） |
| AI 调用封装后的CLI | 高（CLI屏蔽底层变化） | 高（内置确认/审计/幂等） | 低（仅开放白名单+人工确认） | 高（聚焦业务动作，而非底层交互） |
四、现实可落地的分阶段路线（附实操细节）
这类系统最怕“一步到位做平台”，更高效的方式是按阶段落地，每个阶段聚焦“最小闭环”：
Stage 0：技术路径摸底（1-2天）
核心目标：明确OA的技术细节，决定Stage 1的接入方式（API/浏览器自动化）。
需确认的关键信息：
| 维度 | 需确认的内容 | 应对方案示例 |
|---|---|---|
| 登录方式 | 账号密码/短信验证码/单点登录（SSO）？ | 验证码：对接打码平台/人工扫码；SSO：解析token生成逻辑 |
| 会话机制 | 会话凭证（Cookie/Token）、过期时间、刷新逻辑 | 本地加密存储Cookie，定时调用auth status检测过期 |
| 表单校验 | 请假表单的隐藏字段（如部门ID）、前置校验（如年假余额是否足够） | 提前抓取表单元数据，CLI层内置校验逻辑 |
| 接口安全 | 是否有CSRF Token/请求签名/跨域限制？ | CSRF：抓取页面的CSRF Token并带入请求；跨域：通过代理转发 |
Stage 1：登录+请假闭环（3-5天）
核心目标：跑通“登录→查假→提请假”的最小闭环，产出可用的oa-cli基础版本。
核心功能&实操代码示例：
1. 认证模块（Python伪代码）：
# oa_cli/auth.py
import json
import os
import cryptography.fernet # 加密存储会话信息
from requests import Session
def 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的操作边界。
落地方式：
- 封装MCP Server（Model Context Protocol）：将CLI命令封装为AI可识别的工具接口，定义参数约束；
- 白名单管控：仅向AI开放“查询类”（查余额/假种）和“预览类”（请假预览）命令，提交/审批类命令需人工确认；
- 交互模板：AI调用CLI后，返回结构化结果+人工友好的总结（如“你的年假余额为7天，2026-04-10请假1天的预览已生成，确认提交请回复【确认】”）。
Stage 4：生产化与治理（2-3周）
核心目标：补齐企业级治理能力，从PoC升级为生产级工具。
核心治理能力：
- 权限隔离：基于RBAC控制不同用户可执行的CLI命令（如普通员工仅能提请假，经理可审批）；
- 敏感信息脱敏：日志/输出中脱敏手机号、工号等敏感信息；
- 错误码体系：完善全局错误码（如1xxx=认证错误、2xxx=请假错误、3xxx=审批错误）；
- 限流与重试：对高频命令（如
leave balance）做限流，对临时接口失败自动重试； - 自动化测试：编写单元测试（CLI逻辑）+集成测试（对接OA真实环境）。
五、常见问题与应对策略
| 问题场景 | 解决方案 |
|---|---|
| OA 登录需要验证码 | 1. 优先申请企业免验证权限； 2. 对接打码平台自动识别； 3. 支持人工扫码登录，缓存会话 |
| 会话频繁过期 | 1. 定时调用auth status检测会话状态； 2. 会话过期时自动触发重新登录； 3. 延长OA会话超时时间（需运维配合） |
| 前端无公开接口，只能用浏览器自动化 | 1. 用Playwright/Puppeteer封装底层操作，对外暴露稳定CLI； 2. 监听前端DOM变化，通过特征（而非固定ID）定位元素； 3. 前端改版时仅需修改自动化层，CLI命令保持不变 |
| AI 误触发高风险命令 | 1. 高风险命令需人工回复“确认”才能执行； 2. 给AI返回“操作需确认”的提示，而非直接执行； 3. 限制AI每日调用高风险命令的次数 |
CLI 层的核心设计原则
- 优先复用原生接口：优先对接OA现有开放API/前端内部接口（如请假提交的AJAX接口），浏览器自动化仅作为无接口时的兜底方案；
- 输出结构化JSON：所有命令默认输出JSON，便于脚本/AI解析，仅通过
--human参数输出人类友好的文本； - 高风险动作强管控：提交、审批、撤销等动作必须包含
--confirm强制确认、操作日志审计、基于请求ID的幂等保护； - AI 仅能调用高层命令：AI看不到DOM、按钮、接口参数，只能调用“查询余额”“预览请假”“提交请假”等业务级命令。
六、落地价值参考
- 效率提升：员工请假相关操作耗时从平均5分钟/次降至30秒/次，团队每月节省80+人/小时；
- 错误率降低：请假申请填错字段的比例从15%降至1%以下；
- 风险可控：未再发生AI/脚本误操作导致的审批异常，所有高风险操作可追溯、可回滚；
- 可扩展性：基于CLI快速接入了加班申请、出差审批等新能力，适配周期从1周缩短至1天。
七、结语
一个只能被“人工点击”的OA系统，永远无法真正融入企业自动化/AI协作体系。
我们不是要“让AI代替人操作OA”，而是要先把OA的核心能力从“网页交互”收敛成“可复用、可管控、可审计的CLI工具”，再让AI在这个安全边界内发挥价值。
这套思路的核心不是技术多先进，而是先解决“可控性”，再解决“智能化” ——承认传统OA的复杂性，不把AI当“万能胶”，而是通过工程化的方式，让OA能力真正成为企业可复用的数字化资产。
