V2EX › pppwww 的所有回复 › 第 1 页 / 共 2 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 2

❮

❯

5 月 22 日

回复了 murongxdb 创建的主题 › 程序员 › 很好奇 RAG 真的是现代 ai agent 所需要的吗，还有 langchian 这种框架，没有看到太多知名开源项目用到了

@Jiahim 大佬，基于知识图谱的 RAG 这个有没有开源项目推荐，目前也涉及到一些报表生成，SQL 生成上的问题

5 月 22 日

回复了 pppwww 创建的主题 › 程序员 › 分布式的 Agent 协调服务

@lel020 我基于 openagents 的思路，改造了一个简单的版本，可以满足有个 LeaderAgent 可以做任务协调之类的，然后我看还有一些开源的项目向 multica 、ruflo 这种也有类似的能力。不过 multica 是通过拉起你本地的 Claude ，帮你创建一个新的 agent ，并没有用到你已经建好的 agent 能力

5 月 22 日

回复了 pppwww 创建的主题 › 程序员 › 分布式的 Agent 协调服务

@YanSeven 差不多，目前我们底层提供了 agent 部署的能力

3 月 23 日

回复了 pppwww 创建的主题 › 程序员 › AI Coding 如何更好的描述需求

其实我也尝试使用 TDD 来驱动开发，然后你就会发现一个是 token 的花费会很高，另一个就是要花时间去审核 Ai 生成的测试用例，以及 Ai 生成的用例是否正确...

3 月 23 日

回复了 pppwww 创建的主题 › 程序员 › AI Coding 如何更好的描述需求

@kasusa 是的，现在每天的工作就变成了花大量的时间写需求描述，然后审核方案，再就是 review code ，其实就算花了很多时间来做这个功能，仍然会有一些问题在编码/测试过程才能发现

2025 年 9 月 25 日

回复了 pppwww 创建的主题 › 程序员 › AI+BI 面临的困境

@brianinzz 我们也是搞了一个大宽表，在数据资产的建设上下功夫

2025 年 9 月 8 日

回复了 pppwww 创建的主题 › 程序员 › AI+BI 面临的困境

@goodryb 确实，当前准确性是 AI 在 BI 领域面临的比较大的挑战，数据问答层面，能选择到正确的数据来源是第一个要面临的问题

2025 年 9 月 8 日

回复了 pppwww 创建的主题 › 程序员 › AI+BI 面临的困境

@levelworm 哈哈哈哈，我倒也想，目前 ai 在 BI 领域最大的难题就是准确性问题或者信任问题，这块恰恰是 BI 最看重的问题

2025 年 9 月 8 日

回复了 pppwww 创建的主题 › 程序员 › AI+BI 面临的困境

@red13 是的，如何把复杂的业务逻辑和关系型数据库中的库表之间的联系建立起来是个问题

2025 年 9 月 8 日

回复了 pppwww 创建的主题 › 程序员 › AI+BI 面临的困境

@irockytan 首先感谢大佬的恢复，第一条路目前在研究这个，通过比较详细的 table schema 信息+相似问题的输出 sql 来一起给到 LLM 。第二条之前确实没有怎么考虑，这个我研究研究

2025 年 3 月 27 日

回复了 pppwww 创建的主题 › 程序员 › [讨论] 如何把现有服务改造支持 MCP

@neptuno 大佬你的想法应该和下面 yrzs 提出的类似？

2025 年 3 月 27 日

回复了 pppwww 创建的主题 › 程序员 › [讨论] 如何把现有服务改造支持 MCP

@lambdaq 就是问过了，然后感觉还是不太清晰，wwwww

2025 年 3 月 27 日

回复了 pppwww 创建的主题 › 程序员 › [讨论] 如何把现有服务改造支持 MCP

@FriedRiceNoodles 感谢，我研究一下

2025 年 3 月 27 日

回复了 pppwww 创建的主题 › 程序员 › [讨论] 如何把现有服务改造支持 MCP

@Depth 感谢我看下一下

2025 年 3 月 27 日

回复了 pppwww 创建的主题 › 程序员 › [讨论] 如何把现有服务改造支持 MCP

@yrzs 其实还一点困惑在于，sever 返回的 tools 列表，其中关于 input_schema 是不是没有严格要求，只要能返回 name, description 还有 inputSchema 的三元组就可以了，具体 inputSchema 的组织形式没有严格定义。因为还没看过 mcp 协议的原始论文规范，所以这一块有点模糊。

2025 年 3 月 27 日

回复了 pppwww 创建的主题 › 程序员 › [讨论] 如何把现有服务改造支持 MCP

@Tink 看了 openManus 中关于 client 端的调用实现以及官方给的使用示例( https://modelcontextprotocol.io/quickstart/client)，其实就是 client 向 server 查询 list_tools ，然后把这些 tools 转换成了 LLM 调用时的 tool 列表。对于不同的 LLM 模型，可能要自己做 adapter

2025 年 3 月 27 日

回复了 pppwww 创建的主题 › 程序员 › [讨论] 如何把现有服务改造支持 MCP

@yrzs 这个是 client 调用 server 进行执行 tool 的时候么，这个我倒可以理解； mcp server 不是还要支持 toolList 这种的获取么，这种是如何把我们项目中的接口转换成 mcp server 认为的 tools 的呢

2025 年 3 月 26 日

回复了 pppwww 创建的主题 › Starbucks › [请教] 有木有大佬用 StarRocks 做过用户路径分析的哇

@superliy 我们这里是有专门的团队来维护开发，同类型的用的比较少，pg/ck 等只是简单的用过几次，没法给出对比

2025 年 2 月 16 日

回复了 pppwww 创建的主题 › Starbucks › [请教] 有木有大佬用 StarRocks 做过用户路径分析的哇

@Jim2Chen 有空了写个文章分享下，目前整理的方案和公司的数据结合的比较多，不方便直接发，主要步骤就是：
1 、如何识别会话
通过窗口函数，计算相邻两次行为的时间间隔，按照规定的 sessionPeriod 切割会话
2 、识别会话后，如何实现路径的裁剪
通过窗口函数，找到路径的起始或者结束节点，然后进行一次裁剪
再次通过窗口函数，对每个会话的行为节点编号，进行一次深度上的裁剪
3 、最终返回给展示层的数据格式
这里有两种返回形式，一种是直接返回路径，然后业务层做计算，另一种是返回节点对之间的统计信息。可以根据业务需求自由选择

2025 年 2 月 13 日

回复了 pppwww 创建的主题 › Starbucks › [请教] 有木有大佬用 StarRocks 做过用户路径分析的哇

@Jim2Chen 用 4 层窗口函数实现了一个版本，但是查询性能感觉不是很好.. 4 个行为，13E 数据要 30s

1 2

❮

❯