#自媒体运营频道 #@yunying23
小红书这个平台的审核为什么会这么恶心呢？前年曾经玩过两个月小红书，我当时发现自己发的帖子基本上10条有8条是被限流的，而只要不被限流的内容基本互动数据都非常好。
被限流的原因就是个黑盒，有时候换几个关键词重发就可以解除，有时候就是一些莫名其妙的原因。比如说前年发过一条分析茶百道招股书的帖子，后来发现和茶百道相关的内容当时都被小红书限流了，原因是因为有加盟商在闹事…
这样的事情经历多了就会特别恼火，原本只是想在发点有意思的东西玩玩，但接二连三的限流让我彻底断绝了发帖的欲望。真的很好奇小红书在这方面到底是怎么想的，有没有朋友可以说说？
小红书这个平台的审核为什么会这么恶心呢？前年曾经玩过两个月小红书，我当时发现自己发的帖子基本上10条有8条是被限流的，而只要不被限流的内容基本互动数据都非常好。
被限流的原因就是个黑盒，有时候换几个关键词重发就可以解除，有时候就是一些莫名其妙的原因。比如说前年发过一条分析茶百道招股书的帖子，后来发现和茶百道相关的内容当时都被小红书限流了，原因是因为有加盟商在闹事…
这样的事情经历多了就会特别恼火，原本只是想在发点有意思的东西玩玩，但接二连三的限流让我彻底断绝了发帖的欲望。真的很好奇小红书在这方面到底是怎么想的，有没有朋友可以说说？
如果你在使用Next.js 框架，刚好还在用 Better Auth 对接登录，也要使用 Stripe 支付，那推荐看看 Better Auth 提供的Stripe 插件，地址：https://www.better-auth.com/docs/plugins/stripe 。可以一次性集成网站中核心的登录&支付，极大降低开发工作量。
并且官方还有 demo，提供完整的登录、支付、管理后台源码，还有线上体验地址：https://demo.better-auth.com/。源码地址：https://github.com/better-auth/better-auth/tree/main/demo/nextjs
作为曾经使用过 Nuxt 开发的人来说，由衷的感慨使用 Next.js 的便利性，很多插件、模板等都会有 Next.js 版本，开发效率++
并且官方还有 demo，提供完整的登录、支付、管理后台源码，还有线上体验地址：https://demo.better-auth.com/。源码地址：https://github.com/better-auth/better-auth/tree/main/demo/nextjs
作为曾经使用过 Nuxt 开发的人来说，由衷的感慨使用 Next.js 的便利性，很多插件、模板等都会有 Next.js 版本，开发效率++
浅谈这段时间开发 AI Agent 的局限性和难点
1：LLM + Tools 局限性：
- 常见场景：Chatbot 为主的（FuntionCall、MCP）
- 局限性：长链路的延迟和幻觉、多步骤的模型注意力有限、上下文受限、工具规模管理问题、Tools 与模型相互弱化。缺少记忆、规划、流程管理的能力，Agent 状态持久化开发成本高，单次 LLM 处理能力有限，多轮对话上下文太高
2：LLM + Tools + Memory（代表 langchainJS）
- 场景：存储用户对话和个人偏好、以及使用习惯等等个性化场景，成为用户的第二分身。
- 局限性：见第 1 点，缺少复杂流程链路的管理，比如某个节点出现问题、中断、循环问题（比如生成代码）、hunman介入，无法从原来的位置恢复，分支逻辑等等
3：LLM + Tools + Memory + workflow（代表 langgraphJS）
- 场景：类似于 Manus、Genspark 代表等等 Planing Agent
- 局限性：对上下文要求高，需要训练小模型，大量的工具维护与开发，对资源需求很高、还要设计复杂的 AgentState，需要贯穿整条workflow，可能还涉及子图，前后端协议
4：LLM + Tools + Memory + workflow + Protocol（Google Adk + A2A协议）
- 场景：富文本信息流（AI 每条消息可能有长文本、视频、图像、文件等）类似于 Manus、Genspark 信息流。
- 局限性：需要对接与设计 Agent 2 Agent 之间和 富文本 UI 的数据协议，特别是数据流的前后端的时序处理（细节特别多），复杂度和开发成本高，需要训练更多的数据来提升增强每一个环节的效果。
我个人认为第 4 点的难点在于对于复杂业务系统的实现，常见的是代码生成。需要具备指定场景的项目经验，构建架构和模板项目提供样板支撑，才能保证每次生成的效果非常好。且每次涉及Bug调整和修改都有可能进入死循环（参照 cursor / cline）
抛砖引玉，有限的经验分享
1：LLM + Tools 局限性：
- 常见场景：Chatbot 为主的（FuntionCall、MCP）
- 局限性：长链路的延迟和幻觉、多步骤的模型注意力有限、上下文受限、工具规模管理问题、Tools 与模型相互弱化。缺少记忆、规划、流程管理的能力，Agent 状态持久化开发成本高，单次 LLM 处理能力有限，多轮对话上下文太高
2：LLM + Tools + Memory（代表 langchainJS）
- 场景：存储用户对话和个人偏好、以及使用习惯等等个性化场景，成为用户的第二分身。
- 局限性：见第 1 点，缺少复杂流程链路的管理，比如某个节点出现问题、中断、循环问题（比如生成代码）、hunman介入，无法从原来的位置恢复，分支逻辑等等
3：LLM + Tools + Memory + workflow（代表 langgraphJS）
- 场景：类似于 Manus、Genspark 代表等等 Planing Agent
- 局限性：对上下文要求高，需要训练小模型，大量的工具维护与开发，对资源需求很高、还要设计复杂的 AgentState，需要贯穿整条workflow，可能还涉及子图，前后端协议
4：LLM + Tools + Memory + workflow + Protocol（Google Adk + A2A协议）
- 场景：富文本信息流（AI 每条消息可能有长文本、视频、图像、文件等）类似于 Manus、Genspark 信息流。
- 局限性：需要对接与设计 Agent 2 Agent 之间和 富文本 UI 的数据协议，特别是数据流的前后端的时序处理（细节特别多），复杂度和开发成本高，需要训练更多的数据来提升增强每一个环节的效果。
我个人认为第 4 点的难点在于对于复杂业务系统的实现，常见的是代码生成。需要具备指定场景的项目经验，构建架构和模板项目提供样板支撑，才能保证每次生成的效果非常好。且每次涉及Bug调整和修改都有可能进入死循环（参照 cursor / cline）
抛砖引玉，有限的经验分享
❤1