衣舞晨风

这段时间看 Agent 相关的东西，一个很直接的感受是：概念越来越多，但单独看每个概念，又好像都不复杂。

比如 Tool Calling 是让模型选择函数，MCP 是连接工具，A2A 是 Agent 之间通信，AG-UI 负责前后端交互。介绍文章看了不少，真正把它们放到同一个项目里时，还是会遇到很多具体问题：请求从哪里进来，工具结果怎么回给模型，多个 Agent 怎么传递上下文，用户中途取消以后后台任务要不要继续跑。

为了把这些问题串起来，我写了一个 AgentMesh Demo。业务场景很简单，就是查食堂菜单、价格和库存，再加一个模拟订餐能力。场景虽然小，但刚好可以把 AG-UI、AgentScope、MCP 和 A2A 都接进来。

这篇文章不准备逐个介绍协议，而是沿着一次请求看一遍这个项目。它不覆盖模型训练、微调、RAG 等内容，主要讨论的是：拿到一个大模型接口之后，怎样把它做成一个能交互、会调用工具、能委派任务的应用。

最近在微信读书上看林军锋的《当AI开始自主进化，普通人最该守住什么？》，第六章谈到一个很现实的问题：AI用得越顺手，人越容易把自己的判断也一并交出去。

《Harness工程：从上下文管理到Agent系统构建》读书笔记。本书从上下文工程出发，依次讨论意图识别、规划、执行、反思、记忆、Skills、多 Agent 协作，以及 Claude Code、Claw 类产品背后的 Harness 设计思想。

这篇不做具体产品排名，只回答一个问题：怎么判断一个 AI 网关好不好。

我的结论是：好的 AI 网关不是功能最多的那个，而是能在你的生产边界里长期稳定运行的那个。它至少要同时满足四件事：

1. L7 网关基本功扎实：代理、路由、LB、超时、TLS、限流、认证、观测都不能短板明显；
2. 真正理解 AI 流量：能处理模型路由、body 改写、token 治理、SSE 流式、协议转换、Agent / Tool Call；
3. 性能和运行时行为可证：打开 AI 插件后，CPU、内存、GC、p99、流式背压和取消处理都经得起压测；
4. 生产成熟度足够：核心能力可用、可运维、可回滚、可观测，有足够生产背书。

没有绝对最好的 AI 网关，只有最适合当前团队边界的网关。模型平台、日志、告警、安全旁路都成熟时，网关应该“薄而快”；这些能力还不完整时，网关可以“厚而全”，但必须接受数据面复杂度上升，并用压测证明这份复杂度是可控的。

代码逻辑正确，不代表运行时行为正确。本文复盘 API7 AI 网关连续出现的 CPU 饱和问题，以及如何借助 AI 扩展排查思路，再用源码、PR 和实验约束 AI 的结论。

APISIX Anthropic 与 OpenAI 协议互转插件：支持流式、思考、工具调用与多模态

2025年工作聚焦大模型全生命周期管理和多云高可用云原生网关；考取大数据系统开发中级职称和系统架构设计师高级证书。

企业上云后，单一云厂商风险逐渐暴露。本文介绍如何设计云原生网关架构，实现跨云高可用，涵盖集群适配、流量隔离等关键设计。

大家从网上肯定看到过关于Apisix性能高的文章,那么到底是如何实现的呢？
本文是分析也是自己学习《OpenResty从入门到实战》及Apisix官方文档的一个笔记

国内外混合云环境下南北向网关选型实践，对比分析Istio、Envoy等网关方案的优缺点。