AI Agent 开发实战：从单轮到多Agent协作，踩过的坑和总结
我在做一个自动写技术博客并发布到 WordPress 和微信公众号的项目。一开始单个 Agent 既写又改还要发，经常出错，后来拆成了多 Agent 协作体系。
问题是什么
一开始我把所有能力塞给同一个 Agent：选主题、写文章、润色、发布，全塞进一个 prompt。结果呢？文章写到一半开始胡扯，发布时搞错平台配置，改一个地方的 prompt 影响所有环节。最离谱的一次，Agent 在生成正文时突然开始吟诗——就因为 prompt 末尾写了句"要有创意"，被过度泛化了。
核心问题很简单：一个 prompt 里塞的职责越多，每个职责的表现就越差。这不是模型能力问题，是 prompt 工程的基本规律——职责耦合。
解决思路
我对比了三种方案：
| 方案 | 思路 | 缺点 |
|---|---|---|
| 单 Agent + 超长 prompt | 一个 prompt 列清楚所有规则 | 相互干扰，越改越乱 |
| 单 Agent + 工具调用 | Agent 自己决定调用哪个函数 | 模型决策不稳定，经常选错工具 |
| 多 Agent 流水线 | 每个 Agent 只做一件事 | 需要中间状态传递，架构成本略高 |
选了方案三。原因很直接：每个 Agent 的 prompt 可以压缩到 20 行以内，职责单一，调试时一眼就能看出哪个环节出了问题。
操作步骤
步骤1：梳理业务环节，拆解 Agent 职责
先画出文章生产的完整流程：
选题 → 写作 → 润色 → 脱敏检查 → 发布
每个环节拆成一个独立 Agent。关键原则：每个 Agent 的输出格式要明确、可解析。
我的 Agent 划分：
| Agent | 输入 | 输出 |
|---|---|---|
| topic-gen | 兴趣方向 | 选题标题 + 大纲 + 优劣分析 |
| blog-gen | 选题 | 完整 Markdown 文章 |
| article-edit | 文章 + 修改意见 | 修改后的文章 |
| send | 文章 | 发布到各平台的结果 |
# 目录结构
daily-publish/
├── prompts/ # 每个 Agent 的 prompt 模板
│ ├── select_topic.txt
│ ├── generate_article.txt
│ ├── polish_article.txt
│ └── send.txt
├── lib/ # 各平台发布脚本
│ ├── wechat.sh
│ └── wp.sh
├── articles/ # 中间产物目录
│ ├── drafts/ # Agent-1 输出
│ ├── polished/ # Agent-2 输出
│ └── published/ # 最终结果归档
└── run.sh # 编排脚本
步骤2：用文件系统做 Agent 间通信
Agent 之间不直接调 API 互相通信——那样会引入额外的错误点。我用文件系统作为"消息队列"：
Agent A 写入文件 → Agent B 读取文件
# run.sh 核心编排逻辑
step() {
echo ">>> [$1] $2"
}
# Step 1: 选题
step "1/5" "选题中..."
claude -p "$(cat prompts/select_topic.txt)" > articles/drafts/topic.md
# Step 2: 写文章
step "2/5" "生成文章中..."
TOPIC=$(head -1 articles/drafts/topic.md)
claude -p "$(cat prompts/generate_article.txt)" \n "$(cat articles/drafts/topic.md)" > "articles/drafts/${TOPIC}.md"
# Step 3-5: 润色、脱敏、发布
用文件做中间状态有个大好处——任何一个步骤挂了，可以手动修文件然后从失败步骤重跑，不用整条流水线重来。
步骤3：给每个 Agent 写"极简 prompt"
我的 prompt 模板经过反复删减，最终原则是：
以 select_topic.txt 为例：
你是一位资深技术选题编辑。
你的任务：从以下主题列表中选一个近期值得写的技术方向。
规则：
1. 只选你真正能写出干货的方向
2. 优先选读者有痛点、但解决方案不普及的方向
3. 输出格式：标题（一句话） + 大纲（3-5个二级标题） + 优劣分析（各2点）
4. 标题不要"从入门到精通"、"一篇文章学会"这类烂大街句式
5. 不要解释你为什么选这个，直接输出结果
主题池：
{pool_content}
历史已选（不要重复）：
{history_content}
每个 prompt 都控制在 15-25 行。越短，模型执行越稳定。
步骤4：用 git 做版本控制和回滚
生产文章时最怕的是：发完才发现有问题，但已经没法撤回了。
我用 git 做中间产物的版本管理：
# 每次生成后自动 commit
git add articles/drafts/ articles/polished/
git commit -m "article: add draft and polished versions"
# 出问题时回滚到某个中间步骤
git checkout <hash> -- articles/drafts/
实际踩坑：有一次 publish 脚本把文章标题搞成了乱码（文件名中的中文字符被错误处理），因为之前手动修改过文件名。git diff 一眼看出了问题，回滚重来只花了 30 秒。
步骤5：加一个"脱敏检查" Agent 做安全门禁
这是后来加的。某次生成文章时，Agent 在示例代码里写了一个真实的 API Key：
# 错误的做法
api_key = "sk-xxxxxxxxxxxxxxxxxxxx" # 这是我测试用的key
虽然 key 已经 revoke 了，但这是个危险信号。于是加了一个专门的脱敏检查步骤：
step "脱敏检查" "扫描敏感信息..."
# 检查常见敏感模式
grep -n -i "sk-\|api_key\|password\|secret\|token" articles/polished/*.md || true
# 用 Claude 再做一轮语义检查
claude -p "$(cat prompts/sanitize_check.txt)" "$(cat articles/polished/*.md)"
正则检查只能扫明显模式，语义层的敏感信息泄露（比如示例中的数据看起来像真实数据）需要模型判断。两个配合使用才靠谱。
结果与总结
改造后整体效果：
坑和注意点：
延伸思考
这套单文件流水线在小规模下够用，但如果要扩展到每天多篇文章、多作者协作，有几个方向可以改进：
评论已关闭！