雨夜读书记

试试在prompt里明确写“不要生成注释”，或者用/t指令关掉注释补全，我这么调完清爽多了。 模型对上下文的依赖确实大，你给个更具体的函数签名或者TODO，它反而能少废话。

试试把检索结果按更新时间做硬过滤再进rerank，版本号这种直接查最新一条就行。 可以给每个文档加个valid_from时间戳，检索时过滤掉过期chunk，比metadata过滤更稳。

试试把共享State按Agent拆成独立命名空间，用显式字段传递依赖，别让它们直接读写同一份上下文。

中间层做用户映射其实挺靠谱的，别怕性能，几十个人并发真不算啥，重点是把token缓存和刷新做好就行。我之前用nginx+lua写过一层，把企微的userid换成内部token，延迟基本可以忽略。MCP那个认证确实太玩具了，别指望它直接搞定生产环境。你不如看看有没有现成的SSO网关项目，稍微改改就能接上。

说实话我也有同感，最近拿几个真实业务场景去跑了下GPT-5，代码生成确实没比4代强多少，反而在嵌套异步逻辑上绕圈子。感觉现在各家都在卷benchmark，但实际落地时那种“差一点就对了”的隐性错误还是老样子。不过我倒觉得，如果OpenAI真在憋架构大招，那现在这种挤牙膏式更新可能也是故意留的操作空间，毕竟商业节奏和技术突破本来就难两全。

我之前也踩过这坑，后来是加了个预筛选层，先用embedding把TopN块召回来，再让LLM快速生成每块的摘要，最后只把摘要拼进上下文，要细节时再单独调原块。这样“总结全文”也能兜住，就是多了一次模型调用，延迟会高一点。你这情况其实也可以试试让MCP的tool返回结构化数据，比如带offset的分块引用，客户端按需拼接，总比硬塞一大坨强。

说实话我也踩过类似的坑，copilot补全太顺滑了，容易让人放弃思考直接接受。后来我逼自己每次生成代码都先过一遍“这字段真的需要吗”，再跑一遍静态检查，才稍微好点。你那个NPE我觉得不是AI的锅，是设计模式套得太急，重构前应该先让AI解释清楚变更影响面再动手。 换个思路，把AI当结对编程的实习生用，让它先给方案，你自己来挑毛病，而不是直接抄答案。我后来给团队定了条规矩：AI生成的代码必须附上“为

看到这个帖子，我挺感慨的，因为StaffDeck这个项目我关注了有一阵子，也正好在最近一个内部项目中尝试了类似思路的落地。先亮明身份：一线AI工程，做过几个多Agent系统，从零搭过state machine，也写过那种让人想吐的胶水代码。所以对这帖子里的痛点——状态持久化、任务编排可观测性、角色冲突死锁——感同身受。 先说说我对StaffDeck真实价值的判断。帖子说它“名义上是给Agent发