Agent 开发实践：我撸了个交互式 AI 问题解决可视化助手（附完整开发实录）

[wantDoraemon]

今年来 Agent 开发风风火火的，作为一个后端开发也要跟上技术发展的脚步，看了挺多文档总感觉都是在纸面上，还是得动动手才行，于是就有了 ThinkingMap 这个项目。

简单来说，这是一款基于多智能体协作的交互式 AI 问题求解平台。它将复杂的思考过程可视化为动态生长的节点树（ Thinking Map ），支持用户实时干预、修正和协作。

技术栈（全栈）：

• 后端：Go (Gin) + Eino (字节开源的那个 Agent 框架) + Redis + PostgreSQL 。
• 前端：Next.js 15 + ReactFlow + Shadcn/ui + Zustand 。

这项目的两个特点：

1. 不是单纯的套壳：在后端尝试了比较完整的 Agent 编排（ Orchestration ），处理了流式输出（ SSE ）和一些稍微复杂的上下文逻辑，目前整个交互打磨得还算顺手。
2. 详细的填坑记录：因为使用 AI 编程，文档的重要性不言而喻，所以在完善项目的过程中，把从架构设计、Agent 开发思路到具体落地的全过程都记录下来了。如果你也在学 Go 或者想了解 Agent 怎么落地到实际业务里，这些文档可能比代码更有参考价值。

项目开源，功能基本完善，欢迎大家试玩或者 Review 代码。

• GitHub: github.com/PGshen/thinking-map
• 文档: docs
• 体验地址：thinking.zero-zero.cc （随便注册下便可，当前无验证邮箱）

求 Star ，求轻喷 :D

对 Agent 开发感兴趣的朋友一起交流下呀～

老师们不要爆破哈，体验一下就可以🐶

[CathayChen]

不理解注册为啥要填姓名，这个 ai 给你出的主意吗？

[CathayChen]

注册不了，注册按钮点了下，请求了 4 下，然后这个是 response：
{
"code": 400,
"message": "invalid request parameters",
"data": {
"error": "Key: 'RegisterRequest.Username' Error:Field validation for 'Username' failed on the 'min' tag"
},
"timestamp": "2025-12-17T15:07:17.941558595+08:00",
"requestID": "eaef3f46-cb3e-4994-8353-33eb76653fa0"
}

[MIUIOS]

用户名填 admin 炸了，ERROR: duplicate key value violates unique constraint \"idx_users_username\" (SQLSTATE 23505)

[wantDoraemon]

@CathayChen 随便填就可以了。没做邮箱验证，单纯是为了 agent 实践，所以这方便比较随意

[wantDoraemon]

@MIUIOS 不要乱来呀 🐶。不过这个服务没有后台，注册 admin 也是和平常账号没有区别😂

[wangyaominde]

@MIUIOS 去酒吧点了一个老板

[Albertcord]

注册不了，登录不了

[wantDoraemon]

@Albertcord 报错吗？我试了下没问题呢，可能网络问题，服务使用 cloudflare 代理了

[SoldierL]

楼主很强，可以接私活了。我最近正好也在用 eino 写这种。

体验下来，第一步交互很好，就是问题拆解那里，相当于引导用户更完整的填写了问题，输出的准确性会变高。
后面的全局整理，交互实在是有点复杂，不过可能也是你这个项目的核心功能，个人认为作为可选项就可以了，大部分还是用不到。

用户痛点：答案过程不透明、难以理解和信任；多步骤思路难以清晰展示；过程难以随时干预与调整；缺乏结构化拆解与可视化。
针对你提出的用户痛点，think 过程展示出来就可以解决了，用户不需要理解那么多的过程。

建议重点还是丰富 agent ，提升单个 agent 的准确性。提供可选的 agent 就可以了。

[wantDoraemon]

@SoldierL 最开始是想不同场景需要的不一样吧。有些场景我只要答案，中间的过程我不想管，那么前期很火的 deep research 就能满足。这个项目的目标是侧重主动干预，适合需要人主导的场景，不是 AI 输出什么我就要什么，而是我要 AI 输出我想要的。
当然这个项目还不能用于生产，还有很多可以优化，但是我干不动了😂