Agent 的五种用法
五个每天都在跑的真实场景 —— 不讲 benchmark、不讲框架。
五种形状
每日简报
订阅 → 过滤 → 摘要 → 归档
做成一条每天自动跑的 pipeline。
每天早上，三分钟
一条 cron、一个 skill、一个 knowledge base。
每天长出来，不用我操心。
小工具
"手动做两次"
就已经值得做一个工具。
都是一个 session 写完的
多机 GPU 监控。
把 nvidia-smi 聚合成 JSON，
我的 agent 排队前会先读它。
投稿前校验 .bib，
对照 OpenAlex / Crossref 找死链和版本漂移。
一个典型 .bib 通常能捞出 20+ 处。
PDF → 打印就绪的会议 poster（HTML）。
省掉两天 InDesign 调版。
关键不是"这些工具多新"
而是决策规则反了：重复两次就值得做。
快速学习
要 reading list 是弱 prompt；
要 learning trajectory 才是强 prompt。
关键在于 prompt 的形状
给回来的路径会错。
但它是一个可以吵架的脚手架 —— 比我自己从零写快得多。
auto-research
不是"自动写论文"。
是把"从直觉到第一条信号"
压到一个下午。
三个角色，一个下午
KILL / PIVOT / CONTINUE。
最近一次 PIVOT 省掉了两周的 scaling。
Agent 是仪器，不是 collaborator —— 决策始终在我。
vibe coding
验证一个产品想法的最短路径 ——
让自己当第一个用户。
从"想要它"到"能跑"
"构建"几乎免费之后，真正的问题回到了该在的地方：
这个东西值不值得用。
变的不是
能力的上限 ——
是"试一下"的
成本。
五个 case 共享的三件事
taste、framing、取舍仍然在我。
它做的是我懒得写的那部分。
一上午跑五次烂的，
好过一周只跑一次"很仔细的"。
"给我 10 篇"很弱；
"按因果顺序 + 前置依赖"永远更好。
Thank you
欢迎提问、反驳，
或者丢一个你想让 agent 帮你做的问题。