文章写作 Agent 从提示词工程到本地小模型落地：结构、训练与成本优化

写一篇高质量技术文章，既要逻辑清晰又要信息准确，很多团队开始用 LLM Agent 来辅助生产。但实践中普遍遇到两个问题：一是纯用 API 模型（如 DeepSeek）做写作，成本会随产量线性增长；二是通用模型不熟悉你的风格和知识体系，需要反复微调与提示词迭代。

本文给出一个可私有化部署、成本可控的文章写作 Agent 方案。它的核心能力分四层：

1. 提示词工程：驱动 Agent 理解写作目标与格式规范。
2. 优质文章训练：用少量范文微调或上下文内指导，让输出风格对齐。
3. 知识库参考：基于 RAG 将内部资料注入生成流程。
4. 线上检索：遇到不确定数据时自动联网获取实时信息。

最后，我们以 DeepSeek API 为参考，对比分析本地小模型（8B量级） 的成本优势，并给出一个基于 Ollama + 8B 模型的最小运行示例。

本文所有技术方案基于 2025 年主流开源模型与工具链（llama.cpp v2808, Ollama 0.5.x, LangChain 0.3），版本变动不改变核心逻辑。

一、为什么需要文章写作 Agent 的四层能力

传统写作者靠大脑记忆、搜索引擎和剪切板。AI 写作 Agent 则把这三个环节数字化，形成闭环：

• 提示词工程：定义角色、风格、输出结构（如 markdown、json）。没有这一层，模型会随意发挥。
• 优质文章训练：让 Agent 学习你认可的范文——不是让模型记住全文，而是提取行文节奏、段首句模式、过渡方式。
• 知识库参考：企业内部文档、技术手册、产品说明，模型无法预训练记忆，必须通过 RAG 实时注入。
• 线上检索：时效性信息（版本号、价格、事件）必须从最新网页获取，否则生成内容会过期。

这四层缺一不可。其中，提示词工程是“方向盘”，后三层是“燃料”。

二、提示词工程：定义 Agent 的行为骨架

我们用一个结构化提示词模板来约束 Agent。以技术文章写作为例，提示词通常包含以下字段：

实际工程中，我们会将提示词存储为一个 system_prompt 模板文件，并支持动态插入用户输入（如标题、关键词）。

【配图建议】一张流程图：左侧是 prompt template (变量槽位)，中间通过 LLM 生成，右侧输出 markdown 结构；alt：提示词工程模板与LLM输出关系图

关键点：提示词不能一次写死。需要经过 3-5 轮迭代：给模型一篇范文→调整语气约束→检查输出是否包含“根据……”。我们发现，在 system_prompt 末尾加一条 “如果无法确定，说‘此处需核实’并跳过细节”，可大幅降低幻觉率。

三、利用优质文章训练：Few-shot 与微调的选择

3.1 Few-shot 示例法（零成本启动）

将 2-3 篇你认可的文章片段直接放入 prompt 的 examples 字段。例如：

examples = [
    {
        "title": "MCP 协议实战",
        "opening": "MCP 不是 mcp.vc，而是一个……",
        "structure": ["背景", "核心设计", "代码演示", "局限"]
    }
]

模型会模仿 examples 中的行文节奏和段落长度。我们的实测表明，3 个示例足以让 8B 模型的输出风格贴近 target，无需微调。

3.2 参数高效微调（追求一致性）

如果每周产出 >20 篇，推荐用 LoRA 微调。将 30-50 篇优质文章整理成 instruction -> output 格式（instruction 是简短写作要求，output 是成文片段）。用 Unsloth 在消费级 GPU（RTX 4090 24GB 即可）上微调 7B 模型，耗时约 2 小时，推理时只需加载 base model 和 adapter。

微调后的效果：命中的是站位、过渡词、引用习惯，而非具体知识。这样模型不会“记住”旧数据中的事实。

四、知识库参考：RAG 架构与踩坑

RAG 是避免模型胡诌技术细节的关键。我们的方案使用 LangChain + Chroma 向量库：

用户提问 → 嵌入模型（all-MiniLM-L6-v2）→ 检索 TopK=3 → 上下文拼接 → LLM 生成

关键参数与坑：

常见问题：当检索到的两篇文档结论矛盾时，模型会尝试“平均”导致错误。解法：在 prompt 中指定“如果资料信息冲突，说明两个观点并给出哪个更权威（按发布日期）” 。

五、线上检索：让 Agent 学会“查一下”

对于版本号、价格、会议日期等时效信息，纯 RAG 不够。我们集成 serper（Google 搜索 API）或 tavily，让 Agent 在生成特定字段时自动发搜索请求。

实现方法：在 prompt 中定义工具描述

当你需要最新版本号、价格、人名年龄等信息时，调用 search_event。返回结果用 JSON 包裹。

然后在代码层面用 @tool 装饰器包装搜索函数。注意要加缓存：同一问题 24 小时内不重复搜索（节省成本并避免因网络抖动中断）。

六、为什么要用本地化小模型：以 DeepSeek 为例的成本对比

这可能是全文最重要的决策点。我们以 DeepSeek API 为对比基准，分别算一笔账。

6.1 DeepSeek API 方案的成本

微调成本

假设你准备了 100 篇 500 字以上的优质文章，并扩散为 3 倍选题（共 300 组训练对）。在 DeepSeek 平台进行模型微调（以 DeepSeek 官方微调服务为例，按 token 计费）：

• 单次微调费用：约 ￥20~￥30
• 一般需要 3~6 轮 微调才能达到稳定的风格与质量
• 启动总成本：￥20 * 3 = ￥60 至 ￥30 * 6 = ￥180，平均约 ￥100~￥300

实际开销的上限可取为 ￥300，即可覆盖大多数场景。

推理成本

一篇 1500 字的技术文章，加上系统提示词、内容提示词、用户要求文本，总输入 token 约 2000~3000，输出约 1500 token。DeepSeek API 的推理价格（以官方公开价格为例）：

• 输入：￥0.001/1K tokens（约）
• 输出：￥0.002/1K tokens（约）

单篇推理成本约为： (3K * 0.001 + 1.5K * 0.002) = ￥0.006，但实际由于上下文更长、重试、角色定义等因素，一篇完整的文章往往需要多次调用。根据实测，一篇常规文章（不含 RAG 和 MCP）的推理成本约 ￥0.02~￥0.1。

当引入 RAG 知识库检索、MCP 工具调用（如网页搜索、数据库查询）以及多轮重写优化后，每次生成都会增加 token 消耗。综合估算，一篇附带完整 RAG + MCP 并经过 1-2 次重写的文章，最终成本可能达到 ￥1.0 左右。

全年成本推算

假设每周生产 20 篇文章（含 RAG 和 MCP），一年 52 周：

• 单篇成本 ￥1.0 × 20 篇 × 52 周 = ￥1040
• 微调成本（首年）：￥300
• 总成本约 ￥1340/年，且随产量线性增长。

6.2 本地小模型方案的成本

我们使用 Ollama 部署 8B 模型（如 gemma4:e4b 或 Qwen 3.5 9B）在单张消费级显卡（二手 RTX 4090 约￥6000，或 Mac Mini M2 Pro ￥5000）。

推理成本

• 一次推理 1500 tokens 约 0.8 秒（4-bit 量化，RTX 4090）
• 功耗约 80W，电费按 0.7 元/度计算：0.8 秒 × 80W / 3600秒 * 0.7 = 0.000012 元
• 一篇完整文章包含 RAG 检索和多步推理，总推理时间约 200 秒：200 × 0.000012 = 0.0024 元
• 即使加上 MCP 工具调用（如本地搜索、本地数据库），成本仍小于 ￥0.01/篇

微调成本

本地微调不按 token 收费，仅消耗电费和硬件折旧。使用 Unsloth 对 8B 模型做 LoRA 微调，每轮耗时约 2 小时（RTX 4090），5 轮共 10 小时。电费：80W × 10h × 0.7 = 0.56 元，硬件折旧忽略不计。微调总成本可以视为 ￥0。

硬件折旧

硬件按 3 年折旧（1095 天），每周约：

• ￥6000 / 1095 * 7 ≈ ￥38.4/周（RTX 4090）
• ￥5000 / 1095 * 7 ≈ ￥32/周（Mac Mini）

总成本计算（每周 20 篇）

但注意：本地小模型的硬件是一次性投入，第二年硬件折旧会降低（或硬件可继续使用），而 API 方案是持续性支出：若产量翻倍，API 成本翻倍，本地方案仅电费增加。

当 周产量超过 40 篇 时，本地方案开始全面优于 API 方案（硬件折旧相对固定，而 API 成本线性增长）。

6.3 本地小模型的额外收益

• 隐私：所有知识库内容（未公开文档、竞品分析）不出机器，无需脱敏审计。
• 无速率限制：可同时进行多路推理，适配合写作矩阵。
• 可定制性强：可自由调整量化、推理参数、输入上下文窗口。

6.4 性能局限与分级策略

本地 8B 模型在高级事实推理（如复杂代码生成、数据校对）上仍弱于大型 API 模型。我们采用分级架构：

• 常规初稿、结构搭建、风格润色 → 本地小模型
• 涉及数值计算、代码级查错、复杂指令跟随 → 自动调用一次 DeepSeek API（仅此步骤用 API，单篇成本增加 ￥0.1~￥0.2）

此策略下，综合成本仍比全 API 方案低 80% 以上。

七、坑与局限

1. 提示词工程并非万能：很多问题源于模型对指令的理解偏差，而非 prompt 不完善。我们曾遇到模型正确识别了“不要用被动语态”但依然用被动，原因是训练数据中多被动句。此时需加入 ## 反例 片段。
2. RAG 检索质量不稳定：chunk_size 和 embedding 模型选择对结果影响巨大。建议用 sentence-transformers/all-MiniLM-L6-v2 作为起点，中文场景换 BAAI/bge-small-zh-v1.5。
3. 本地模型对长上下文支持有限：8B 模型 context window 多在 8K–32K，若知识库拼接后过长，需裁剪或滑动窗口。
4. 线上检索可靠性依赖源网站：如果源站 404 或返回错误，搜索可能返回过时结果。我们在搜索工具后加了一层响应校验：当搜索结果的摘要中不含查询词时，标记为不可靠，交给人工。

八、完整可运行最小示例

以下是一个基于 Ollama + LangChain 的文章写作 Agent 骨架（简化示意，仅供本地运行验证）。需要先安装 Ollama 并拉取模型：ollama pull llama3.2:8b

# requirements.txt: langchain==0.3.0, chromadb==0.5.0, ollama==0.4.0
from langchain.llms import Ollama
from langchain.prompts import ChatPromptTemplate
from langchain.schema import HumanMessage

llm = Ollama(model="llama3.2:8b", temperature=0.7)

prompt = ChatPromptTemplate.from_messages([
    ("system", "你是一位技术文章作者。请按以下要求写作：\n"
               "1. 开头用场景或问题引入\n"
               "2. 每个 H2 前给一句话结论\n"
               "3. 代码块用 python 语法标记\n"
               "4. 不编造版本号，不确定写‘以官方文档为准’\n"
               "标题：{title}\n"
               "主题：{topic}"),
    ("human", "请写一篇 800 字的技术文章。")
])

def write_article(title: str, topic: str):
    msgs = prompt.format_messages(title=title, topic=topic)
    result = llm(msgs)
    return result

# 测试
article = write_article("MCP 协议入门", "MCP 是一种轻量级 AI Agent 通信协议")
print(article[:500])  # 打印前 500 字

注意：实际生产需增加 RAG 检索步骤（另写 retrieve 函数），此处为简化示范。完整代码可参考 LangChain 官方 cookbook。

九、总结

1. 文章写作 Agent 的四层能力：提示词工程（骨架）、优质文章训练（风格对齐）、知识库参考（事实注入）、线上检索（时效保障），缺一不可。
2. 以 DeepSeek API 为例的对比：单篇含 RAG 和 MCP 的成本约 ￥1.0，微调启动成本 ￥300；而本地 8B 模型推理成本每篇 ￥0.01 以下，微调成本接近 ￥0（仅耗电）。
3. 本地小模型是中长期成本优解：硬件一次性投入（约 ￥5000~￥6000）可覆盖 3 年以上，规模越大优势越明显。
4. 分级生成策略：大部分工作交给本地小模型，仅高精度片段委托 DeepSeek API，综合成本再降低 80%。
5. 每次迭代都要检查标准提示词：提示词模板需要单独维护版本，关键字段（角色、约束）用变量而非硬编码。

最后一句本质：写作 Agent 不是替代写作者，而是将写作者的思维模式固化为可重复运行的工程系统。