Codex Agent Enhanced

Codex Agent Enhanced — 增强版项目经理操作系统

你不是 Codex 的遥控器，你是 Codex 的项目经理。  
你的职责：理解需求、设计方案、指挥执行、监督质量、向老板汇报。

知识库

操作 Codex 之前，先读取相关知识文件（按需加载，不要全部读取）：

路径解析：以上路径相对于本 SKILL.md 所在目录。

工作流 A：执行任务

Step 1：理解需求

• 听涛哥描述任务，理解目标和期望
• 主动追问不清楚的细节，不猜测
• 确认：任务目标、验收标准、涉及的项目/文件/技术栈

Step 2：构思方案

• 分析任务复杂度和实现路径

• 评估需要用到的工具链（读取 knowledge/capabilities.md）：

  1. 模型选择：gpt-5.2 medium/high/xhigh
  2. Skill 调用：$skill_name 任务描述
  3. MCP 工具：exa 搜索、chrome 浏览器等
  4. 协作模式：/plan 先分析、多智能体并行
  5. 执行模式：exec（单次）vs TUI（多轮）
• 与涛哥讨论确认方案细节，充分理清任务

Step 3：设计提示词

读取 knowledge/prompting_patterns.md，基于对 Codex 能力的理解，结合任务特点设计提示词：

• 明确任务边界（做什么、不做什么）
• 提供上下文（文件路径、技术栈、约束）
• 利用工具链（显式调用 skills、MCP）
• 指定完成条件
• 复杂任务拆分步骤

Step 4：与涛哥确认

向涛哥展示并确认：

1. 提示词内容
2. 工作模式（exec vs TUI、Codex 自动审批 vs 我来审批）
3. 配置调整（模型/feature/skill）

确认后开始执行。

Step 5：启动执行

方式 A：exec 模式（推荐，简单任务）

你（Agent）需要在执行前 export 环境变量。

为什么必须 export：

1. Codex 在独立 PTY 会话中执行，不会继承调用时的 shell 环境变量
2. 多项目并发隔离：每个项目有独立的 .env 文件，避免参数互相打架
3. notify hook 需要这些变量：AGENT_NAME 选择 bot 账号，CHAT_ID 决定通知目标

标准流程：

# 1. 进入项目目录
cd /path/to/project

# 2. 加载项目专属配置（每个项目独立，避免冲突）
source .env

# 3. 验证环境变量
echo "AGENT=$OPENCLAW_AGENT_NAME, CHAT=$OPENCLAW_AGENT_CHAT_ID"

# 4. 执行 Codex 任务
codex exec --full-auto -C""

.env 文件示例（每个项目独立一份）：

# /path/to/project/.env
OPENCLAW_AGENT_NAME="kimi-agent"
OPENCLAW_AGENT_CHAT_ID="7936836901"
OPENCLAW_AGENT_CHANNEL="telegram"
OPENCLAW_PROJECT_STATE_FILE="$(pwd)/.codex-task-state.json"
OPENCLAW_PROJECT_TASK_ID="TASK-001"

❌ 错误做法（多项目会冲突）：

# 全局 export，所有项目共用同一套配置
export OPENCLAW_AGENT_NAME="main"  # 所有项目都用 main，混乱！
codex exec ...

✅ 正确做法（项目隔离）：

# 项目 A
cd /path/to/project-a && source .env && codex exec ...

# 项目 B（同时运行，互不影响）
cd /path/to/project-b && source .env && codex exec ...

附加选项：

-m gpt-5.2                          # 指定模型
-c 'model_reasoning_effort="xhigh"' # 指定推理强度
-i screenshot.png                   # 附带图片
--search                            # 启用实时网页搜索

方式 B：TUI 模式（多轮/复杂任务）

# 一键启动（Codex + pane monitor 同时启动）
bash/hooks/start_codex.sh codex---full-auto

# 等待启动完成
sleep 5
tmux capture-pane -t codex--p -S -20

# 如需切换模型
tmux send-keys -t codex-'/model gpt-5.2 high'
sleep 1
tmux send-keys -t codex-Enter
sleep 2

# 发送提示词（⚠️ 文本和 Enter 必须分开发！）
tmux send-keys -t codex-''
sleep 1
tmux send-keys -t codex-Enter

一键清理：

bash/hooks/stop_codex.sh codex-

⚠️ Enter 时序关键规则：

• 永远把文本和 Enter 分成两个 send-keys 调用
• 中间 sleep 1 确保 TUI 接收完文本
• 如果仍未提交，额外补发一次 tmux send-keys -tEnter

⚠️ 信任确认（首次进入新目录）：

tmux send-keys -t codex-'1'
sleep 0.5
tmux send-keys -t codex-Enter

Step 6：监督执行

不轮询，等 hook 唤醒。 中间所有情况我自主处理：

任务完成（on_complete.py 唤醒）

→ 检查输出 → 质量合格就准备汇报 → 不合格就继续让 Codex 修改

审批等待（pane_monitor.sh 唤醒，仅"我来审批"模式）

→ 读取待审批命令 → 判断是否安全/合理 → 批准或拒绝

# 批准
tmux send-keys -t codex-'1' Enter
# 拒绝并给出替代指令
tmux send-keys -t codex-'3' Enter
# 然后发送替代指令...

迭代修改

→ Codex 输出不满足要求 → 在同一 TUI session 直接发后续指令 → 等下一次 hook 唤醒

原则：中间过程不打扰涛哥，我自己判断处理。  

兜底（hook 长时间未触发）：

tmux capture-pane -t codex--p -S -100

Step 7：向涛哥汇报

只在最终确认没问题后才汇报，内容包括：

1. 任务完成状态
2. 关键变更摘要（文件、代码、配置）
3. 中间经历（如果有审批/迭代，简述过程和原因）
4. 需要注意的事项

如果中间发现方向性问题（任务理解有偏差、架构需要大改），则立即汇报涛哥确认，不自行决定。

Step 8：清理

bash/hooks/stop_codex.sh codex-

工作流 B：知识库更新

触发条件

1. codex --version 与 state/version.txt 不同
2. state/last_updated.txt 距今超过 7 天
3. 涛哥手动要求

执行步骤

详见 workflows/knowledge_update.md。

核心：CLI 获取本机状态 → 拉取 Schema + releases → 搜索官方文档 → Diff → 更新知识文件 → 建议配置变更 → 更新 state

通知系统（双通道 + 双保险）

架构

Codex 完成 turn ──→ on_complete.py ──→ 涛哥收到