最近两周翻 HN 和 Reddit，能明显感觉到海外AI社区的风向在变：吵了几年的“模型谁更强”正在退烧，取而代之的是三个更务实、也更值得国内开发者抄作业的话题——没有 eval（评测集）的 AI 应用不许上线、Agent 互联协议 A2A 进了 Linux 基金会、“AI 审 AI 代码”的工具爆发式增长。这三个话题国内讨论热度都不高，但每一个都直接影响你明年怎么干活。今天把它们一次讲透。

话题一：Eval-Driven Development，正在成为新教条

过去你问“这个 AI 应用做得怎么样”，答案是“我试了几个 prompt，感觉还行”。现在你去 r/LLMDevs 或者 HN 发这种回答，会被围攻。社区已经形成了新共识：LLM 应用不改测试，跟裸奔没区别——因为模型会静默升级、prompt 改一个字全局行为就漂移、RAG 换个 embedding 全链路重测。

这套实践被叫做 EDD（Eval-Driven Development，评测驱动开发），对标的正是十年前的 TDD。逻辑很简单：LLM 输出是概率的，但你的验收标准必须是确定的。

各方观点

• 支持派：观点很直接——“你不会把没跑过单元测试的代码 deploy 到生产，为什么敢把没跑过 eval 的 prompt deploy 上去？”他们引用的常见教训是：换了个新模型，某个长尾场景（比如日期解析）准确率从 95% 掉到 60%，而团队两周后才发现。
• 反对派：认为 eval 维护成本被严重低估——评测集本身会过时，覆盖的场景永远赶不上真实用户输入的长尾，最后沦为“为了绿而绿”的形式主义。还有人吐槽部分团队拿 LLM 当裁判（LLM-as-judge），“用幻觉模型给幻觉模型打分”。
• 中立派：立场是分层——核心收入链路必须上 eval，玩具项目随缘；而且 eval 不是一次性工程，要跟着用户反馈持续长。

我的判断：这场争论的结局类似当年的“要不要写测试”——反对声音会一直存在，但工程团队的默认动作已经变了。

可以上手的三件工具

1. promptfoo（开源，github.com/promptfoo/promptfoo，官网 promptfoo.dev）——目前社区里最轻量的选择。不写代码就能测：写一个 promptfooconfig.yaml，把 prompt、测试用例、断言列进去，命令行一键跑分。
2. Langfuse（开源可自部署，github.com/langfuse/langfuse，官网 langfuse.com）——主打 tracing + 评测一体化，OpenAI SDK 换个 base_url 就能接入，适合想看“每一次调用到底发生了什么”的团队。
3. Braintrust（braintrust.dev，商业产品有免费额度）——托管式 eval 平台，数据集管理做得比较细，创业团队用得多。

promptfoo 十分钟上手

npx promptfoo@latest init        # 生成 promptfooconfig.yaml 模板
# 编辑 yaml：填 prompt、provider、测试用例与断言
npx promptfoo@latest eval        # 跑评测，命令行直接出对比表
npx promptfoo@latest view        # 打开本地 Web 界面看逐条结果

关键玩法是把 eval 塞进 CI：GitHub Actions 里加一步 promptfoo eval --prompts prompts/，设置失败阈值。从此 prompt 改动和代码改动一样，不过测试不许合并。断言除了关键词/正则，还支持 LLM-as-judge 和语义相似度，可以混着用。

工作流长这样

flowchart LR
    A[收集真实用户badcase] --> B[沉淀进评测数据集]
    B --> C[编写promptfoo断言]
    C --> D{CI: promptfoo eval}
    D -- 达标 --> E[合并上线]
    D -- 回归 --> F[定位漂移原因<br/>模型升级/prompt/RAG]
    F --> B
    E --> G[线上tracing<br/>Langfuse]
    G --> A

注意这是个闭环：eval 数据集的源头是线上真实 badcase，不是拍脑袋编的。只写 10 条理想用例的团队，测不出任何东西。

话题二：A2A 进驻 Linux 基金会，Agent 互联标准开抢

第二个信号烈度更高。Google 在 2025 年推出的 A2A（Agent2Agent）协议——让不同厂商的 Agent 互相发现、派活、收结果的开放协议——已经捐给了 Linux 基金会独立运营（据 Linux 基金会公告，官方称有上百家企业参与），代码在 github.com/a2aproject/A2A。

很多人第一反应：“这不是和 MCP 打架吗？”社区吵的就是这个：

• 互补派（目前的主流观点）：MCP 解决的是“Agent 怎么用工具”（Agent ↔ 工具），A2A 解决的是“Agent 怎么用 Agent”（Agent ↔ Agent）。一个 Agent 完全可以同时通过 MCP 调 API、通过 A2A 把子任务外包给别家 Agent。协议层级不同，不冲突。
• 竞争派：认为两个协议都在往对方地盘渗透，长期必然撞车，最终“谁的应用多谁赢”，别迷信基金会背书。
• 怀疑派：Agent 互联的需求本身还没被验证——“我的 Agent 为什么要信任你一个来路不明的 Agent？”安全、身份、计费这些配套没跟上之前，A2A 更像期货。

A2A 的核心机制值得了解：每个 Agent 在 /.well-known/ 路径下挂一张 Agent Card（JSON 名片），声明自己能干什么、怎么联系；任务以 Task 为单位流转，长任务支持流式更新，还能传文件等 Artifact。设计上明显是冲着“跨企业边界协作”去的。

对国内开发者的启示

这是典型的标准窗口期博弈。协议本身开源、门槛不高，现在读懂 A2A + MCP 的分工，比三个月后看别人案例要值钱得多。国内 Agent 框架（各家平台都在自建协议层）与国际标准如何互通，是一个几乎没人做、但出海团队迟早要面对的问题。务实建议：不必现在 All in，但你的 Agent 架构设计里，应该把“对外暴露一张标准 Agent Card”和“工具调用走 MCP”当成两个独立模块预留，未来切换成本会低一个数量级。

话题三：AI 写的代码，正在被另一个 AI 审

第三个话题最接地气。社区现在默认的爆款组合是：用 Agent 写代码，用 AI Code Review Bot 审代码。这一波代表产品：

• CodeRabbit（coderabbit.ai）：这一品类的头部，PR 一发自动逐行评审、生成摘要。对开源仓库免费，商业版按席位订阅（具体价格以官网为准）。国内出海的开源项目接一个，README 上的“Reviewed by CodeRabbit”徽章都成了某种社区身份标识。
• Greptile（greptile.com）：主打“理解整个代码库再评审”，而不只是看 diff，擅长抓跨文件的逻辑问题。
• Graphite（graphite.dev）：从 stacked diff 工作流切入，把 AI review 作为合并流程的一环。

HN 上的争论也很有意思：

• 支持方晒出数据：Bot 抓出的空指针、越界、漏掉的边界条件不比初级工程师少，而且永远不烦、秒回。
• 反对方核心论点只有一个：AI 评审会制造虚假安全感。“机器人说 LGTM，人就不看第二眼了——可恰恰是最危险的架构级问题，所有 Bot 都看不出来。”
• 中间派的实践最值得抄：Bot 负责第一层“廉价错误”（bug、风格、测试缺失），人只审“该不该做”和“架构对不对”。分级评审，各干各的。

对个人开发者的行动建议很直接：GitHub 开源仓库现在就能免费接 CodeRabbit（在 coderabbit.ai 用 GitHub 登录、选择仓库安装 App 即可），私有仓库可以先靠 Claude Code / Copilot 的 review 模式顶替，等团队规模上来了再上付费方案。

信息差总结

行动指南

1. 今晚：挑一个你手上最不稳的 prompt 功能，npx promptfoo@latest init 建 20 条用例（至少一半来自真实 badcase），跑一次基线。
2. 本周：把 promptfoo eval 加进 CI，设个 80% 通过率阈值；线上接 Langfuse 看真实流量。
3. 本月：读一遍 A2A 的 Agent Card 规范（github.com/a2aproject/A2A），在自己 Agent 项目里做协议隔离设计；给开源仓库接上 CodeRabbit 白嫖一轮 AI 评审。

这三个动作的共同点是：都不追新模型，而是把“概率系统”装上“确定性护栏”——这正是当前海外工程社区审美转向的全部含义。

参考来源

• promptfoo 官网与开源仓库：https://github.com/promptfoo/promptfoo / https://promptfoo.dev
• Langfuse 开源仓库：https://github.com/langfuse/langfuse
• A2A 协议（Linux 基金会项目）：https://github.com/a2aproject/A2A
• CodeRabbit 官网：https://coderabbit.ai
• Graphite 官网：https://graphite.dev

（注：本文观点整理自 HN/Reddit 社区长期公开讨论与上述项目官方文档；涉及价格、参与企业数量等易变信息以官网为准。）

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。