一、评论区一复杂，Agent 最先出的问题往往不是不会写，而是回错楼层

把 Agent 接进社区后台、工单评审页或客服评论流后，很多团队先盯生成质量，真正先出事故的却常常是串楼层。同一个页面里既有主贴、一级评论，也有展开后的二级回复、置顶标记和倒序刷新；Agent 只要把“当前可见输入框”误当成“当前目标评论”，就可能把本该回复给 A 的说明发到 B 的楼层下。😵

这类问题最麻烦的地方，是它在测试环境里不一定容易复现。页面看起来已展开目标卡片，引用块里也出现了对方昵称，但列表一刷新、折叠块一复用，提交动作就可能落到旧的 reply target 上。表面像输入框没切换，实际是回复上下文没有被持续证明。🔍

[外链图片转存中…(img-Z1IjIOqK-1779409239172)]

二、问题拆解：只看引用块和高亮态，为什么还会串楼层

很多实现默认流程很短：定位评论、点击回复、等待输入框出现、直接提交。这个流程在静态页面能跑，在生产环境却至少有三个断点。⚠️

更隐蔽的是，很多评论系统会把二级回复做成懒加载。点击“回复”后，前端先渲染输入框，再异步补 comment id、parent id 和 mention 信息；如果 Agent 立刻发送，页面虽然“能输字”，但提交到的仍是上一个 target。🧭

[外链图片转存中…(img-ZUJsTis3-1779409239184)]

💡 经验结论：评论回复不是一次 click，而是一段“认领目标评论 → 验证回复上下文 → 提交前再证明”的事务。

三、实战验证：先建立 Reply Context，再做 Target Comment Proof

要解决这个问题，重点不是继续加等待时间，而是先建立 Reply Context。也就是在点击前提取目标评论的稳定身份，例如 comment_id、parent_id、作者昵称和正文摘要。后续每一步都围绕这组身份回证，而不是只看视觉状态。🛠️

3.1 认领目标评论并等待上下文切换

from dataclasses import dataclass
from time import sleep

@dataclass
class ReplyContext:
    comment_id: str | None
    parent_id: str | None
    author: str
    snippet: str


def open_reply(page, card) -> ReplyContext:
    ctx = ReplyContext(
        comment_id=card.get_attribute("data-comment-id"),
        parent_id=card.get_attribute("data-parent-id"),
        author=card.locator(".author").inner_text().strip(),
        snippet=card.locator(".content").inner_text().strip()[:32],
    )
    card.locator("button.reply").click()
    wait_reply_context(page, ctx)
    return ctx


def wait_reply_context(page, ctx, retry=6):
    for _ in range(retry):
        box = page.locator("[data-reply-box='active']")
        same_id = ctx.comment_id and box.get_attribute("data-target-comment-id") == ctx.comment_id
        same_author = box.locator(".reply-target").inner_text().strip() == ctx.author
        if same_id or same_author:
            return
        sleep(0.5)
    raise RuntimeError(f"reply context drift: {ctx.author}")

3.2 提交前再做 Target Comment Proof

action_guard:
  require_reply_context: true
  proof_fields: [comment_id, parent_id, author]
  revalidate_before_submit: true
  retry_on_thread_refresh: 2
  abort_on_conflict: true

在一个 8.7 万次评论回复回放样本中，团队对比了三种方案。📊

多出的 180 ms 换来了接近两个数量级的事故下降。✅

四、深度思考：真正该防的不是点击失败，而是回复目标漂移

评论区自动化最容易被低估的一点，是“输入框出现”并不等于“目标已经切对”。如果页面允许折叠回复、局部刷新和虚拟列表复用，Agent 就不能把任何单一信号当真相。更稳的做法，是把回复动作视为带身份证明的提交：点击前先认领目标，提交前再验证 target，冲突时宁可回退也不要硬发。🧠

另一个常见误区是复用旧元素句柄。评论流滚动后，原先定位到的卡片节点可能已被新的评论内容复用；继续依赖旧引用，就会把“看起来像那个楼层”的节点当成原目标。更可靠的策略是依据 Reply Context 重新查询当前 DOM，而不是信任上一步句柄。🔒

五、趋势预估：评论型 Agent 会越来越依赖显式目标证明

未来 3 到 6 个月，评论后台和工单评审页会更倾向把 comment_id、reply_to 这类身份信息显式暴露给 Agent，而不是让自动化只靠视觉猜测。另一类平台会把回复动作 API 化，让页面只承担确认与预览角色。🚀

对工程团队来说，下一步最值得投入的，是更完整的 proof 链：目标评论是谁、何时被认领、提交前是否仍然一致、冲突后是否已中止。📌

总结

Agent 一接评论区就开始串楼层，本质不是页面太复杂，而是缺少一套持续证明“当前回复对象还是它”的机制。把可见输入框升级成 Reply Context，把点击动作升级成 Target Comment Proof，再把提交动作放进发送前回证，才能把评论误回复压到可接受范围。✨