AI 如何真正改变 Web 代理工作流：开发者视角

“AI 正在颠覆一切”——这类文章你大概已经读腻了，后面往往跟着一堆用 ChatGPT 写 alt 文本的提示词模板。但真实发生在 Web 代理公司里的情况，比炒作所描述的更混乱、更有意思，也更值得警惕。

AI 并没有取代开发者，它改变的是开发者时间的去向、哪些技能在增值，以及代理公司的交付流水线如何组织。如果你在专业地交付客户项目，这些变化已经在影响你，无论你是否主动引入了 AI 工具。

AI 在代理工作中真正有用的地方

内容智能管线

我在代理工作流中见过最持久的 AI 集成不是代码生成，而是内容处理。具体来说，是把客户提供的非结构化内容大规模地转化为结构化、SEO 友好的输出。

一个典型场景：客户扔来一堆 Word 文档、产品规格和旧博客文章。以前，开发者需要手动解析成 CMS 可用的内容。现在可以把这些内容送入 LLM，用结构化提取提示词，直接拿回映射到内容模型的 JSON。

原文给出了一个 Laravel 的队列任务示例，关键点在于：使用 response_format: json_object 约束输出格式，并将 temperature 设为 0.2 以保证稳定性。没有这个约束，你就是在解析自由文本，这在生产环境里会不断出问题。

结构化输出（Structured Output）与 JSON 模式

传统上用 LLM 处理内容时，模型返回的是自由文本，你必须用正则或字符串解析从中"抠"出需要的数据，一旦格式漂移（多一个逗号、少一层引号）解析就会失败。结构化输出改变了这一点：通过 response_format: json_object 或更严格的 JSON Schema / 函数调用约束，模型被强制按照你定义的字段结构返回合法 JSON。这相当于把 LLM 的输出接口从"聊天"变成了"API 响应"。temperature 控制采样随机性，取值 0 到 2，越低输出越确定、越重复；0.2 意味着几乎每次都走概率最高的路径，适合需要稳定字段值的提取任务，而不适合文案创作。需要注意的是 JSON 模式只保证语法合法，不保证语义正确——字段可能填错值，所以下游仍然需要校验逻辑。

作为 CI 步骤的自动化代码审查

另一个正在流行的模式是：把 AI 代码审查作为 PR 流水线的一部分，不是替代人工审查，而是作为第一道过滤器，在问题到达高级开发者之前拦截明显错误。

原文的 GitHub Actions 示例中，用 gpt-4o-mini 对 PHP diff 进行安全问题和 N+1 查询的检查，并通过 gh pr comment 自动评论。选择 gpt-4o-mini 是刻意的——它在每个 PR 上运行，成本必须可控。昂贵的模型留给高风险操作。

CI、PR 流水线与 Diff

CI（持续集成）指每次代码提交后自动触发构建、测试、静态检查等流程的服务。PR（Pull Request，合并请求）是开发者把分支改动提交、请求合并到主分支的机制。Diff 则是一次改动相对于基线版本的具体增删内容，通常以 +/- 行表示。把 AI 审查接入 CI，指的是在 PR 创建或更新时自动运行一个脚本，把本次 diff 发给 LLM 分析，再用 GitHub CLI（gh）把结果作为评论贴回 PR。这种做法的成本结构由 PR 频率决定：团队每天几十个 PR 意味着几十次调用，所以模型选择必须是成本敏感的，这也解释了为什么在这类场景里 gpt-4o-mini 这类小模型比旗舰模型更常见。AI 在这里定位是"第一道过滤器"而非终审，目的是减少高级开发者花在低价值审查上的时间。

没人愿意谈的问题

上下文窗口债务

LLM 是无状态的。每次请求都是白纸一张。这一点显而易见，但影响会悄悄找上门来。当你构建跨越多次用户交互的 AI 功能时——比如一个带有 AI 顾问的多步骤引导流程——你需要在每次调用时重建上下文。这意味着序列化对话历史、在超出限制时智能截断，并决定哪些内容可以安全丢弃。

原文提供了一个 ConversationContextManager 类，用粗略的 1 token ≈ 4 字符估算来控制消息长度，从最旧的开始丢弃。作者的评价很直白：这是无聊的基础设施工作，但也是一个能正常工作的聊天机器人和一个五条消息后就失智的机器人之间的区别。

上下文窗口、Token 与无状态调用

上下文窗口是模型单次请求能处理的最大 token 数量（输入加输出之和），超出就会报错或被截断。Token 是模型处理文本的基本单位，英文大致 1 token ≈ 4 个字符，中文通常更密集，1 个汉字约 1 到 2 个 token，所以按字符数估算只是个粗略上界。LLM 的"无状态"意味着服务器不保留任何对话记忆——ChatGPT 里看起来连续的对话，实际上每次都在重新发送全部历史。因此构建多轮 AI 功能时，开发者要自己维护一个消息数组，在接近窗口上限时做截断或摘要压缩。文章里"从最旧开始丢弃"是最简单的策略，但它会丢失早期设定的关键信息，生产系统通常需要更细的策略：保留系统提示、保留最近 N 轮、对更早的内容做摘要而非直接删除。

面向客户内容过度依赖生成

这更多是代理运营层面的问题。AI 生成的内容如果没有经过领域审查就直接上线，会在下游造成 SEO 问题。内容单薄、措辞同质化、技术细分领域的事实错误，都是常见的失败模式。

原文提到，在实践中效果最稳的做法是：用 AI 做结构化和初稿脚手架，然后在内容进入生产 CMS 之前加入人工审查环节。这比全自动管线慢，但搜索表现的质量差异是可测量的。

哪些技能真正在增值

如果你在考虑把学习时间投在哪里，在 AI 增强的代理工作流中，最高杠杆的领域是：

• 结构化输出的提示词工程——JSON 模式、函数调用、模式约束比自由文本解析更可靠。
• 检索增强生成（RAG）——知道如何分块、嵌入和检索客户特定知识，能让通用 LLM 输出真正贴合客户业务上下文。
• AI 调用的可观测性——记录延迟、token 用量和输出质量指标。当 AI 功能静默退化时，你需要数据来诊断。
• 成本建模——每次触发 0.002 美元的功能没问题；每次触发 0.40 美元的功能在上线前需要先谈预算。

RAG 与可观测性

RAG（Retrieval-Augmented Generation，检索增强生成）解决的是"模型不知道客户内部信息"的问题。流程是：把客户的文档、FAQ、产品手册切片（chunking），用嵌入模型转成向量存进向量数据库；用户提问时先检索最相关的若干片段，把它们拼进提示词再交给 LLM 生成回答。关键工程难点在分块粒度和检索质量——块太大浪费上下文，太小则丢失语义。AI 可观测性则借鉴传统 APM 思路，记录每次调用的输入、输出、延迟、token 消耗和用户反馈评分，用于发现"模型静默退化"（供应商更新模型、提示词被误改、上游数据分布变化都会导致输出质量下降，而接口本身不会报错）。成本建模同理：把单次调用成本估算清楚，才能判断一个功能是可持续的还是会在规模扩大后失控。

写在最后

代理工作流中的 AI 不是一个你按下去的开关，而是一个需要小心布设监控的表面。收益是真实的：内容处理、代码审查增强、面向客户的对话界面。但失败模式同样真实：上下文管理不善、成本失控、内容质量退化——这些问题要几个月后才会在分析数据中显现。

从这些工具中获得最大收益的开发者，不是那些用 AI 写所有代码的人，而是那些理解确定性系统在哪里结束、概率性系统在哪里开始的人——并据此构建护栏。像交付任何基础设施一样交付 AI 功能：带日志、带回退方案，并对任何看起来太容易的东西保持健康的怀疑。