Agent 专题开篇：与大模型共事的这一年

1918 年，洛威尔（Percival Lowell）用望远镜反复观察火星，坚信看到了「运河」——他画的图精确而详尽，却与真实地貌毫无关系。工具提供了新的感知边界，但用好它需要的从来不只是工具本身。

这一年的折腾，让我越来越觉得：大模型本质上是一台新的望远镜——它扩展了认知边界，但「看到什么」「信什么」「怎么用」，仍然是人的判断。

这个专题就记录这些判断：大模型的使用心得、Agent Skills 的实践、以及人机协作中那些反直觉的体会。不追热点，不写科普，只写真正踩过之后的结论。

---

为什么「能用」和「用好」之间差了三年

2023 年底第一次接触大模型 API，调通 Demo 时的兴奋感记忆犹新——感觉自己手里有了一个万能的东西。然后呢？

然后就是漫长的「我知道它很厉害，但不知道该拿它干什么」阶段。

真正让我越过这个阶段的是一个朴素的认知转变：不要问「它能做什么」，要问「我每天花时间做的哪件事最烦」。

对我来说是这几类：

• 读论文后的结构化笔记整理（读完就忘，需要一个留存结构）
• 代码片段的反复修改 vs 只想专注算法逻辑本身
• 各种平台（GitHub、文档、内部系统）之间的信息同步
• 开车时的思考需要随时记录，到公司就能整理成文档

这些场景有一个共同特征：高重复、低创造、需要准确记忆。这正好是大模型的强项——不是替代我思考，而是替代我「把思考过的东西再操作一遍」。

---

几个这一年才悟出来的结论

1. 上下文窗口不是越大越好

刚出来 128K token 模型时，觉得上下文是瓶颈解决了一切。后来发现：

• 模型在超长上下文里的 中间遗忘问题（位置编码衰减）是真实存在的，给它 200K 上下文不一定比 32K 表现更好
• 更重要的：在对话早期把任务边界定义清楚，比后期塞大量信息进去有效得多
• 实践结论：把任务背景、输出格式、禁止事项放在 system prompt 前几条，比放在第 30 条效果好 30% 以上

# 好的 system prompt 结构示例
SYSTEM_PROMPT = """
你是一位专注于{领域}的资深工程师。

输出格式（必须严格遵守）:
- 使用 Markdown
- 代码块标注语言
- 每节附上关键公式

禁止:
- 未经核实的技术细节
- 超过3个未经引用的统计数据
"""

2. Skills 是可积累的工作流，不是提示词模板

很多人把「提示词工程」理解为写好一段 prompt，这其实窄化了它的价值。更持久的做法是：

把重复的任务封装成 Skill——一套包含目标、约束、工具调用约定和输出格式的结构化指令。

好的 Skill 有几个特征：

• 触发条件明确：什么情况下用这个 Skill，而不是直接问
• 输出格式稳定：同样的输入，每次输出结构一致（便于后续自动化）
• 自我纠错机制：在 Skill 里预设边界情况（“如果信息不足，明确说明而不是猜测”）

QClaw 的 Skill 体系就是这种思路的体现——把「用 Git 管理博客发布」封装成一个 Skill，之后每次发布不需要重新描述流程，只需触发 Skill 执行。

3. 最好的 Agent 是「不知道边界在哪」的 Agent

这一年见过最没用的 Agent 是那种过度保守的：每步都问「你确定吗？」，遇到模糊情况立刻投降。

真正有用的 Agent 需要 有底气的不确定——在能力边界内果断行动，遇到真正无法处理的才停下来提问。这需要两点支撑：

• 信任但验证：给 Agent 足够的自主权，但输出结果在关键节点有人 review
• 容错文化：把 Agent 的失误当作流程改进信号，而不是责备理由

---

这个专题会写什么

后续文章会覆盖这几个方向：

• Skills 教程：具体场景的工作流封装（博客发布、论文精读、代码审查……）
• 使用心得：提示词工程、上下文管理、输出稳定性
• 工程实践：多模型协作、Agent 记忆设计、闭环反馈
• 反直觉观察：大模型让人变懒 / 变聪明 / 变焦虑的瞬间

「从脉冲星到自动驾驶」是这个博客的主题，Agent 专题也一样——用大模型扩展自己，而不是被它替代。

开篇就到这里。有想聊的具体场景或问题，留言或者直接找我。