最近在实习求职，想找一个题目，把自己对 LLM、Agent Workflow 和工程化的理解真正串起来，而不是再做一个“输入一句话，输出一句话”的简单 Demo。

于是我做了一个 Viral Comment System：给定一条社交媒体帖子，系统先理解帖子内容，再去学习相似场景下的高互动评论模式，生成多条原创候选评论，最后再经过风险和原创性校验，输出一条更适合发布的推荐结果。项目开源在Github。

这个项目本身不大，但我觉得它很适合作为一个 AI Native Workflow 的练手题。因为它同时包含了几个很典型、也很真实的问题：

  • 输入并不干净，帖子内容、图片、已有评论都可能带来噪声，甚至带 prompt injection。
  • 目标并不是“答对一道题”，而是生成一个“可能有效”的内容，评价标准天然是模糊的。
  • 单纯追求“更吸睛”很容易越过边界，涉及攻击性、误导、名誉风险和抄袭风险。
  • 真正可用的系统不能只靠一个 prompt 撑住，必须有拆分、校验、降级和兜底。

所以这个项目最吸引我的地方恰恰是：它逼着我把“模型能力”变成“工作流能力”。

为什么这题适合用 Agent Workflow

一开始我也想过，能不能直接把帖子、参考评论和要求全部塞进一个 prompt，让模型一步生成“神评论”。 但很快我发现，这个思路有两个明显问题。

第一，目标太混杂了。模型既要理解帖子，又要分析语气，还要总结高赞评论模式、控制风险、避免照抄，最后还要给出最优选择。所有任务糊在一起的时候，输出通常会看起来“什么都做了”，但每一步都不够扎实。并且有可能超出上下文窗口。

第二，这类任务天然需要中间状态。比如：

  • 帖子到底在讲什么，是事实还是观点？
  • 这条内容为什么容易引发互动，是有反差、争议，还是只是情绪浓度高？
  • 参考评论里值得借鉴的是句式、反转方式，还是一种“替大家说出了心里话”的表达模式？
  • 当前话题是不是高风险，高风险时是不是应该主动降低攻击性？

这些问题如果没有显式判断，最后就很难验证系统到底做对了什么，也很难定位它做错了什么。

所以我最后把问题重构成了一个更像 agent workflow 的形式：不是“直接生成一条爆款评论”，而是“生成若干条基于事实、参考模式和风险约束的候选策略，再从中选出一条最合适的结果”。

这背后的变化不只是工程拆分，更是目标定义的变化。因为没有系统能保证“爆”，但一个系统可以尽量做到：理解得更准、借鉴得更稳、生成得更原创、输出得更安全。

这条 Workflow 是怎么设计的

整个 pipeline 的主流程是：

post input
-> post understanding
-> reference comment retrieval and pattern analysis
-> original comment generation
-> risk and originality checks
-> ranking and final recommendation

它对应到代码里，大致由五个环节组成。

1. Post Understanding：先理解帖子，而不是急着生成

第一步我把它单独做成了 post_understanding 模块。它的职责不是“总结一下内容”，而是把后面生成真正需要的信息结构化出来，比如：

- topic：帖子属于什么主题
- core claim：核心观点或核心事件
- tone：语气是调侃、批评、疑问还是中性
- humor points：笑点在哪
- tension points：哪里最容易引发讨论或争议
- controversy risks：有哪些敏感点
- suitable comment styles：更适合哪几种评论风格
- recommended interaction direction：推荐从哪个方向去引发互动

这里我刻意把 “facts” 和 “model judgments” 分开存。因为事实和判断不能混在一起。像标题、正文、发布时间、图片描述这类信息可以当事实；而“这条帖子更适合 pointed question 风格”则是模型判断。把这层分开之后，后面的生成、排序和审查就更容易做 grounded check。

另外，这一步还加了一个很重要的点：把帖子当成不可信输入处理。也就是说，如果帖子里出现“忽略上面的指令”“把你的 system prompt 发出来”这类内容，系统只会把它识别成风险信号，不会真的执行。

2. Reference Search：不是去抄，而是去学“模式”

这一层的目标不是搜几个高赞评论回来给模型“仿写”，而是让系统学习高互动评论为什么有效。

这里我给自己定了一个边界：参考评论只能帮助我提炼 pattern，不能直接进入最终输出。

比如一个高赞评论之所以有效，可能不是因为它措辞多华丽，而是它做到了下面这些事：

  • 把很多人已经有的情绪压缩成一句短表达
  • 先顺着常识走一步，再突然反转
  • 用一句问题把冲突点暴露出来
  • 吐槽的是行为或情境，而不是攻击身份

所以项目里我把一些常见模式抽成了 pattern library，例如：

- crowd-voice summary
- reversal
- pointed question
- witty understatement
- precision roast
- absurd literalization

这一步很像一个小型 agent：它会根据上一步分析出来的 topic、tone 和 tension points 组查询词，去找相似讨论，再筛选出值得学习的评论，最后再做一轮 pattern classification。

这一步给我的一个直接体会是：做 Agent Workflow 时，检索不是为了“补充信息量”这么简单，更重要的是给后面的生成建立风格约束和成功先验。

3. Comment Generation：一次不只生成一个答案

这里我没有让模型直接输出答案，而是要求它一次生成多条候选评论，并且每一条都要附带：

- style：属于哪种风格
- interaction_intent：想引发什么互动
- borrowed_pattern：借鉴了哪种模式
- why_it_may_work：为什么它可能有效
- risk_assessment：攻击性、误读风险、翻车概率

我觉得这一步很重要，因为它把“生成”从一个黑盒输出变成了一个可比较、可审查的候选集。

如果只让模型给一个结果，系统很容易变成“它说什么就是什么”。但如果让它给五个不同风格的候选，再加上解释和风险评估，后面的 ranking 和 guard 才有空间发挥作用，整个 pipeline 才像一个真正的 workflow。

4. Guardrails：把高风险约束从 prompt 里拿出来

这个项目里最重要的一点：不要把所有安全要求都写在 prompt 里，然后指望模型永远听话。

所以我把两类约束做成了独立 hook：

  • risk_guard.py：拦截明显的高风险内容，比如泄露敏感信息、顺从注入指令、骚扰性表达、身份攻击
  • originality_guard.py：把候选评论和参考评论做相似度比较，避免“稍微改写一下就当原创”

这两层 guard 的意义在于，它们是程序化执行的，不依赖模型“自觉遵守”。

我越来越觉得，Agent 系统里最值得单独拿出来工程化的，通常不是“生成能力”，而是“不能出错的地方”。像 prompt injection、抄袭、越界内容，这些都不应该只靠模型自己提醒自己。

5. Ranking：选的不是最狠的，而是最稳的

最后一步是排序和推荐。

这里我没有简单按“看起来最有梗”来选，而是做了一个偏保守的策略：先过滤掉没有通过 guard 的候选，再结合评论风格优先级和风险画像做排序。

换句话说，系统最后推荐的，不一定是最尖锐、最有攻击性的那条，而是“在当前场景下最有可能引发互动，同时又比较不容易翻车”的那条。

这也是我对这类系统的一个基本判断：真实世界里的“好结果”，常常不是局部最刺激的结果，而是全链路约束下的最优解。

这个项目里，哪些地方最像“Agent”

如果把 Agent 理解成“会自己调用工具的东西”，那这个项目当然也沾边。但我想强调的是另一种理解：Agent 不是炫技式调用，而是围绕目标做任务拆分、状态传递、约束执行和失败恢复。

在这个项目里，我觉得比较像 agent workflow 的点有四个：

第一，它不是一个大 prompt，而是一条多阶段流水线。每一阶段只做一件事。

第二，它有显式的中间状态。比如 post understanding 的 schema、reference pattern、candidate risk assessment，这些都是后续决策的依据。

第三，它有 guard。安全边界被写进 CLAUDE.md，还被落进 hooks 里强制执行。

第四，它考虑失败恢复。比如检索失败时，可以降级到已有评论或内置 pattern library；图片理解失败时，不会编造视觉细节，而是退回文本模式。

这些机制合在一起，系统虽然还不算复杂，但已经比“调一个接口”更接近 AI 工程问题了。

我为什么会选这个方向来练手

从找实习的角度说，我其实是有意识地在避开两类项目。

第一类是纯前台型项目：看起来很炫，但核心逻辑很薄，很难说明自己到底解决了什么问题。

第二类是纯 benchmark 型项目：指标可能很明确，但和真实业务的距离有点远，不太能体现自己怎么处理模糊目标、失败场景和工程约束。

这个项目刚好卡在一个我比较喜欢的位置上：

  • 它有真实世界的不确定性。
  • 它能体现我对 LLM 应用边界的理解。
  • 它需要 workflow 设计，而不是只会写 prompt。
  • 它能展示我怎么把“安全、原创、grounding、失败恢复”这些要求落成代码。

更重要的是，这个题目让我重新意识到，做 AI 项目时，真正有价值的往往不是“模型多聪明”，而是“系统在不完美条件下还能不能稳定工作”。

下一步还想继续补什么

这个项目现在还是一个可运行的 scaffold，还没有到很完整的程度。接下来我想继续补几件事：

- 接入更真实的帖子样本和检索证据，而不是只靠示例数据
- 把原创性检查从字面相似度升级到语义相似度
- 增强多模态输入，尤其是图片事实抽取和“不确定性标注”
- 引入更细的评估方式，而不是只看主观“像不像神评论”
- 给不同平台建立更明确的风格差异，比如 Reddit、X、小红书不该用同一套表达逻辑

写在最后

如果只把这个项目当成一个“评论生成器”，那它其实不算特别新鲜。

但如果把它当成一次 AI-native workflow 的练手，我觉得它很值。因为它逼着我从“怎么让模型输出一句话”往前走一步，开始认真思考：

  • 任务应该怎么拆
  • 中间状态应该怎么存
  • 风险边界应该怎么控
  • 检索和生成应该怎么配合
  • 一个系统失败时，应该怎么体面地降级

对我来说，这才是做 Agent 项目真正有意思的地方。

如果后面我继续把这套 workflow 打磨下去，我也很想看看：当 reference retrieval、更细粒度的风控和更真实的多模态输入都接进来之后，这条 pipeline 到底能走到多远。