Agent 能发文却不能回评：鉴权边界踩坑

一个 AI Agent 能读文章指标、选题、发布到 Dev.to，却卡在了回复评论这一步。作者排查后发现，问题出在认证方式：发布文章用的 API key，无法直接满足网页评论表单的要求。

这篇案例值得读，是因为它把 Agent 自动化里容易混在一起的几件事拆开了：模型会不会做、凭证允许做什么、请求能否通过，以及操作最后有没有落到正确位置。

为什么能发文章，却不能回评论

作者搭建了一个定时内容 Agent，可以读取文章指标、选择主题、发布文章并检查结果。发布第一次就成功了，使用的是文档提供的文章接口：

POST /api/articles
api-key: ...

这里解决的是通过 API 发布文章，关键是 api-key 这一行。它能让该接口接受请求，却不能据此推断其他操作也获得了授权。

随后，作者让 Agent 回复尚未收到自己回应的评论。Agent 能找到评论，识别作者、所属文章、讨论串，也能判断是否已有回复，但发送始终失败。

问题有两层。

一层是标识不一致。公开评论接口返回 id_code，网页表单需要的却是 DOM 里的数字评论 ID。它们都与同一条评论有关，但不能直接互换。

另一层是认证不一致。向 API 路由发送回复得到 404；改走网页路由，只携带 API key，又无法通过 CSRF 校验。CSRF 是防止跨站请求伪造的机制，网页写操作有自己的校验要求。

一把有效的 API key，只能证明它对特定接口和操作有效。

把回复评论拆成一条独立流程

作者列出的网页请求条件有三个：

authenticated browser session
CSRF token from the rendered page
numeric parent comment ID from the DOM

这段列的是请求所需条件，没有给出完整实现。尤其要看最后一行：回复要使用 DOM 中目标父评论的数字 ID，不能直接拿公开接口的 id_code 替代。

作者因此调整了工作流：文章指标、文章读取和发布继续走 API key；评论回复使用已登录的浏览器会话，并从渲染后的页面取得所需信息。

发送前，还要将目标评论与 DOM 匹配。发送后，重新加载文章，确认自己的回复在目标评论下恰好出现一次。前者避免回错楼，后者同时检查回复位置和重复发送。

浏览器退出登录时，流程也有明确出口：保留审核过的草稿，报告阻塞原因。

作者当周发现了两条未回复评论，并让拟好的两条回复经过独立审核，检查是否回复自己、是否重复、父评论是否正确，以及措辞是否过于泛泛。由于浏览器会话已经退出登录，最终两条都没有发送。

草稿通过审核，不等于回复已经发布。

这次运行证明了流程能在缺少登录态时停下来。原文没有展示恢复登录后成功回复并完成验证的结果，因此还不能把它当作完整成功案例。

我的判断

作者最有价值的做法，是把凭证、浏览器身份、防伪令牌和操作后验证分别处理。对 Agent 来说，这些条件任何一个缺失，都可能让「已经准备好」与「已经完成」之间隔着一步。

发送后重新加载页面，也比只根据请求是否报错来判断完成更可靠。回复评论不只是写入一段文字，还要求写在正确的讨论位置，并且只出现一次。

但这条路线有前提。浏览器会话会失效，DOM 结构也可能变化，页面匹配需要维护。原文没有说明如何续期会话、如何应对页面改版，也没有给出部分成功后再次运行时的去重实现。

如果平台有文档清楚、权限适配的回复 API，通常可以减少对页面结构的依赖。作者访问某个 API 路由得到 404，不足以证明平台完全没有可用的回复接口，原文没有提供完整排查过程。

所以，这更像一份有价值的工程经验：它说明了失败可能发生在哪些边界，也给出了合理的处理方式；但没有对照数据，不能据此断言浏览器路线在稳定性或维护成本上更优。

能拿来做什么

• 给内容 Agent 按操作记录认证要求，分别写清读取指标、发布文章和回复评论需要什么，避免只留下一个「已配置凭证」状态。
• 在 Node 编排流程里区分草稿已生成、审核已通过、发送已尝试和页面已验证；登录失效时保留草稿，并返回具体阻塞原因。
• 做评论自动化时，先核对接口标识与 DOM 标识的关系，再匹配目标父评论；发送后重新加载页面，检查回复位置及出现次数。