引言：OA 自动化的真实困境
每天早上9点，某公司行政部的小张都要处理近20条请假申请核对——员工们在OA网页上填错日期、漏选假种、忘记附理由是家常便饭；而研发部的小李，为了把“每月考勤对账”接入自动化流程，熬夜写了N套浏览器脚本，结果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 工具
核心架构对比
反模式（脆弱且高风险）： （此处插入反模式架构示意图，展示浏览器直接操控网页的脆弱路径）
最优解（稳定且可控）： （此处插入最优解架构示意图，展示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 lea ve types # 查询所有可用假种（年假/事假/病假等）
oa-cli lea ve balance --type annual # 查询年假余额
oa-cli lea ve list --start 2026-01-01 --end 2026-04-01 # 查询指定时间段请假记录
oa-cli lea ve preview --type annual --start "2026-04-10 09:00" --end "2026-04-10 18:00" --reason "事假" # 预览提交结果（无实际提交）
oa-cli lea ve 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 lea ve cancel --apply-id 12345 --confirm # 撤销请假申请（高风险操作需确认）
CLI 带来的三大核心收益
1. 操作结构化
人、脚本、AI面对的都是统一参数（比如日期格式、假种枚举）和结构化输出（JSON），再也不用面对不确定的网页交互了。举个例子：oa-cli lea ve balance --type annual 的输出就是下面这样的JSON数据，干净利落。
{"code": 0,"msg": "success","data": {"employee_id": "10086","annual_lea ve_total": 10,"annual_lea ve_used": 3,"annual_lea ve_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. 请假模块
实现lea ve 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的操作边界。具体做法是先把CLI命令封装为MCP Server（Model Context Protocol），定义好参数约束；然后做白名单管控，只向AI开放“查询类”（查余额、假种）和“预览类”（请假预览）命令，提交和审批类命令必须人工确认；最后设计交互模板——AI调用CLI后，返回结构化结果外加人工友好的总结，比方说“你的年假余额为7天，2026-04-10请假1天的预览已生成，确认提交请回复【确认】”。
Stage 4：生产化与治理（2-3周）
核心目标：补齐企业级治理能力，把PoC真正升级为生产级工具。包括基于RBAC的权限隔离（控制不同用户能执行的CLI命令）、敏感信息脱敏（在日志和输出中脱敏手机号、工号等）、全局错误码体系完善（比如1xxx是认证错误、2xxx是请假错误、3xxx是审批错误）、对高频命令的限流与重试，以及全面的自动化测试（单元测试加集成测试）。
五、常见问题与应对策略
| 问题场景 | 解决方案 |
|---|---|
| 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能力真正成为企业可以复用的数字化资产。
