不再把 AI Coding Agent 当聊天工具用了

不再把 AI Coding Agent 当聊天工具用了

两种用法的反差

先看一张对比表：

维度	聊天工具思维	工程系统思维
交互方式	打开对话框 → 问 → 复制 → 关掉	Agent 在后台定时运行，人只管审批
输出物	聊天记录（转瞬即忘）	落盘报告、草稿文件、状态数据库
可复用性	下次问还得重新组织语言	Skill 一次编写，反复触发
安全约束	靠人肉检查	14 种正则检测 + 敏感词拦截 + 故障复盘禁发
资源管理	用完了才发现额度没了	5 分钟轮询 + 多阈值钉钉预警
知识沉淀	无	40 份 diff 分析 + 10 份需求报告 + 日报周报

三个月前，我就是左边那列。每次打开 AI Agent，问一个问题，拿到答案，关掉窗口——跟用搜索引擎没什么区别，只是答案质量更高。

现在我的 ~/.codex 目录下有 4000 多行自写的 Python 代码、3 个 macOS LaunchAgent 定时任务、2 套自建 Skill、一个完整的博客发布管线，还有一份记录了演化历史的内部文档。

这篇文章想说的不是"我多牛"，而是——当你真正把 Agent 当成工程系统的一部分来用，你会发现之前的聊天式用法浪费了它 90% 的价值。

聊天够用了吗？——我踩过的三个坑

所有工程系统都不是一开始就设计出来的。我的也一样，每一套工具的诞生都是因为踩了一个实实在在的坑。

坑一：Agent 把报告扔到了 /tmp 下

有一次我让 Agent 帮忙做需求与代码的一致性检查——PRD 一份，代码 diff 一份，分析完输出一个 Markdown 报告。Agent 做得很好，分析很到位。

问题是：我找不到报告了。

Agent 把报告写到了 /tmp 下某个随机路径。我翻了半天终端历史才找到，下次重启机器就没了。

这件事让我意识到：聊天模式下，Agent 的输出是临时的、不可追溯的。如果你想要长期积累的知识资产，你必须对 Agent 的输出路径做约束。

于是我写了第一个 Skill——requirement-consistency-check。它不是一句 prompt，而是一套完整的工具包：

skills/requirement-consistency-check/
├── SKILL.md        # 触发条件 + 使用方法 + 输出路径约束
├── config/
│   └── default.json  # 检查维度：需求遗漏/理解偏差/过度实现/边界缺失...
└── scripts/
    └── analyze.sh    # 可直接执行的分析脚本

SKILL.md 里有一条硬性规则：

若用户未提供 --output，脚本应固定输出到 ./reports/requirement-check/requirement_consistency_时间戳_report.md。禁止输出到随机路径。

这不是提示词模板，是工程规范。Skill 和 prompt 的区别在于：prompt 是一次性的对话输入；Skill 是可复用的能力单元，包含触发条件、参数约束、输出规范和可执行脚本。

坑二：Codex Plus 额度突然用完

某天下午正写代码，Agent 突然罢工。查了一圈才发现——5 小时窗口的额度被耗尽了，毫无预警。

如果 Agent 只是聊天工具，额度用完了大不了明天再来。但当你把 Agent 嵌入日常开发流程——每天用它做 diff 分析、需求对照、代码审查——它的额度就变成了生产资源。生产资源需要监控。

于是我写了额度监控脚本。第一版解析本地 Codex 会话文件里的 token_count 事件；发现本地数据不够准之后，重写了 Web 版，通过 API 直接获取用量。

现在我有 3 个定时任务，覆盖了 Codex 和 Copilot 共 4 个付费账号，每 5 分钟查一次额度，剩余 30% 时钉钉第一次预警，之后在 20%、10%、5%、0% 各触发一次。额度恢复到 80% 和 100% 时也会通知。所有告警做了去重持久化——不会重复轰炸，也不会漏掉。

脚本自带 install-launch-agent 子命令，一条命令就能注册 macOS LaunchAgent，不需要手动编辑 plist。

写监控脚本的过程本身也说明了一个问题：当 Agent 消耗付费配额时，它就不再是聊天对象，而是需要被观测和管理的资源。

坑三：Agent 自动生成的博客草稿差点泄露敏感信息

我开始让 Agent 帮我写技术博客草稿——输入工作笔记，输出一篇结构化的 Markdown 文章。效率确实高。

直到有一次我在发布前抽查，发现文章里嵌着一个真实的邮箱地址和一段疑似 API token 的字符串。Agent 并非故意的——它在润色笔记时把原始内容里的敏感信息原样搬了过来。

那一刻我明白了：Agent 产出的内容越多，安全审查就越不能靠人肉。

这个坑直接催生了 review.py——一个发布前自动审查引擎，包含 14 种正则检测器：

EMAIL_RE      # 邮箱地址
PHONE_RE      # 手机号
TOKEN_RE      # token/secret/api_key
ID_CARD_RE    # 身份证号
PASSPORT_RE   # 护照号
BANK_CARD_RE  # 银行卡号
COMPANY_RE    # 公司名称
BIZ_LICENSE_RE # 营业执照号
PASSWORD_RE   # 硬编码密码
INTERNAL_DOMAIN_RE  # 企业内网域名后缀
LOCAL_IMAGE_RE      # 本地图片路径
ORDER_NO_RE         # 订单号/流水号

另外还有外部 sensitive_words.txt 文件支持自定义敏感词，以及一条硬规则：故障复盘类内容（incident_review）默认禁止直接发布。

给 Agent 立规矩——不是多余，是救命

踩完坑之后，我开始给三个 Agent 平台都设置了"规矩"。

Codex 的 config.toml：

model = "gpt-5.4"
model_reasoning_effort = "high"
[features]
multi_agent = true

搭配 default.rules 里的 8 条白名单规则——Agent 能执行哪些 git/curl 命令是明确限定的，不在白名单里的命令会被拦截。

Claude 通过本地代理转发，模型映射到 xianyu-claude-sonnet-4-6。三个业务项目各有独立的 Claude 项目指令。

Copilot 的全局 instruction 里有一条看似奇怪的规则：

当你完成工作时，不要直接结束对话，而是主动询问用户是否有进一步的需求。

这条规则的来由是：Copilot Agent 经常做完一件事就"拍拍屁股走了"，不给你继续指挥的机会。一条 instruction 就解决了。

三个不同的 AI 平台，三套不同的"驯服手段"。聊天工具不需要 rules 文件和自定义 instructions；当你开始写这些东西的时候，说明你已经在做工程化了。

Blog 发布管线——Agent 只是流水线上的一个工序

这是我目前工程化程度最高的一套系统，也是回答"为什么不聊天了"的最佳案例。

全流程

笔记采集 → AI 写稿 → draft import → review 门禁 → 人类审批 → publish → 博客园

整条管线由一个名叫 bloga 的 CLI 驱动，11 个子命令，1481 行 Python。

采集：通过 bloga note add 或 bloga note import 把工作笔记录入 SQLite 数据库。

写稿：两条路径——

• API 路径：bloga draft generate <note-id>，调用 AI API 直接生成
• Agent 路径：Codex Agent 自己写好 Markdown，然后 bloga draft import 导入

审核：bloga draft review 跑三层检查——格式检查（标题、正文、标题层级）→ 风险检查（14 种正则 + 敏感词）→ 质量检查（正文长度）。error 级别的问题会阻止发布。

发布：bloga publish run <draft-id> 调用博客园 OpenAPI。凭证存在 macOS Keychain 里。

Codex Automation 的关键设计

我配了一个 Codex Automation 任务，每天 21:30 自动触发：

Review today's new raw notes... Write the Markdown draft to a local file, import it with python3 -m blog_assistant draft import, run review checks, and open an inbox item that includes the draft id, title, risk status, draft path, and the exact command to publish after approval. Do not publish automatically.

注意最后那句——Do not publish automatically。

这不是对 Agent 能力的不信任。这是工程系统的设计原则：Agent 负责生成和检查，人类负责最终审批。信任，但验证。

已经跑通了多少？

drafts/ 目录下有 13 篇博客草稿，主题覆盖了：

• ai-agent-build-from-zero — Agent 工程化实践
• codex-monitor — 额度监控系统
• three-usage-monitors — 三套监控的对比
• bloga-cli-pipeline — 博客管线本身
• codex-skills-pitfalls — Skill 开发踩坑
• launchd-pitfalls — macOS 定时任务踩坑
• openclaw-model-routing — 本地代理模型路由
• ……

每一篇都经过了 review 门禁检查。

知识不是聊完就扔的

最后聊一件聊天模式下几乎不可能做到的事：知识沉淀。

我的 ~/Documents/diff-analysis/ 下有 40 份 diff 分析报告。其中一个业务分支 feature_8g5xi7_yz_order_dn 从下午 4 点到晚上 6 点，产出了 19 轮迭代分析——每次代码修改后重新跑一轮。

这不是"问完即走"的聊天式用法。这是 Agent 作为持续集成分析人在工作。

~/Documents/requirement-analysis/ 有 10 份需求分析文档，覆盖多个业务系统。这些文档不是 Agent 的临时输出，而是经过 requirement-consistency-check Skill 结构化处理后落盘的正式报告。

连我的 Agent 工具体系本身也做了文档化——docs/usage-monitors/README.md 记录了监控系统的历史演化、双账号配置、Bearer token 有效期、旧任务停用说明：

旧的 com.openai.codex-usage-dingtalk 任务已停用，不再作为主用提醒来源。

这句话说明什么？说明这套系统本身经历过迭代，有自己的运维历史。当你开始维护 Agent 基础设施，记录变更日志，规划版本演进的时候——你绝对不是在"聊天"。

写在最后

回到标题的问题：我为什么不再把 AI Coding Agent 当聊天工具用了？

不是因为聊天式用法没价值。能快速得到一个问题的答案，这本身就是效率提升。

但当我发现自己在写 rules 文件约束 Agent 能跑的命令、在写 review.py 审查 Agent 的产出、在写 launchd plist 让监控脚本每 5 分钟自动运行、在写 Automation Prompt 里加上 "Do not publish automatically"——

我意识到，Agent 的真正价值不在于"聪明"，在于它能被编排、能被约束、能被持续运行。

聊天是一对一的即时交互。工程系统是一组规则、流程和自动化任务的集合，Agent 只是其中一个执行节点。

把 Agent 从聊天对象变成工程组件，需要做三件事：

1. 定义输出规范——Skill 不是提示词，是可复用的能力单元
2. 建立安全防线——Agent 做得越多，审查就越不能靠人肉
3. 接入自动化——不是你去找 Agent，而是 Agent 按时来找你

当你发现自己在给 Agent 写审核规则和定时任务的时候，你就已经不在聊天了。