杠精派
派聪明
0/512

热门评论

Ψ 2026年05月12日 22:24
工具那块有点看不懂,他是怎么执行的
2
回复1 取消回复
粗心的超短裙 2026年05月14日 14:34
首先会把本地的工具函数的名字、描述和参数等作为提示词发给llm,后续如果需要调用工具,llm的回复中会有一个tool_calls字段告诉需要调用哪些函数,你的程序就要遍历tool_calls里的字段,如果发现函数名为某个函数,就熬取执行对应函数,得到的结果会作为工具消息接下来发给llm
4
回复 取消回复

20 条评论

清净日子 2026年06月16日 17:48
引用原文:GLM-5.1
@派聪明 为什么不用deep seek?
点赞
回复1 取消回复
派聪明 2026年06月16日 17:49
虽然参考资料中并未直接对比 GLM-5.1 和 DeepSeek,但根据文章内容,作者选择 GLM-5.1 的核心原因如下: 1. **工具调用支持极佳**:Agent 的核心是“ReAct模式”(推理、行动、观察循环),高度依赖 LLM 的 Function Calling(函数调用)能力。GLM-5.1 能非常稳定、准确地理解工具定义并生成正确的调用参数。 2. **API 格式兼容**:它兼容标准的 OpenAI API 格式,方便开发者快速封装和替换接口。 3. **个人原因**:作者坦言自己刚好是 GLM 的 Max会员。 **为什么不用 DeepSeek?** 结合 Agent 开发的实际技术需求,作者未选 DeepSeek 可能基于以下考量(实际中两者皆可胜任): * **函数调用稳定性**:早期的 DeepSeek模型在极度复杂的连续工具调用(如多步文件读写与命令执行交替)时,稳定性偶尔会有波动。构建 Agent极其考验模型输出标准 JSON 格式参数的能力。 * **接口生态**:对于从零手写的个人轻量级 CLI 项目,直接使用手头拥有高级会员额度且工具调用验证过的模型是最经济顺手的开发选择。
点赞
回复 取消回复
清净日子 2026年06月16日 17:46
引用原文:GLM-5.1
为什么不用deep seek?
点赞
回复 取消回复
清净日子 2026年06月16日 16:18
@派聪明 这个项目作为秋招项目的亮点和优势在哪里?
点赞
回复1 取消回复
派聪明 2026年06月16日 16:19
将这个“从零手写 AI Agent CLI”项目写进秋招简历,含金量和亮点非常突出。在大家普遍使用现成框架(如LangChain)调包的背景下,这个项目能让你脱颖而出。其核心亮点和优势主要体现在以下四个维度: **1. 直击技术本质,展现极深的底层理解** * **拒绝黑盒调包**:不依赖任何第三方 Agent框架,纯手工实现,证明你真正理解了大模型应用底层的运行逻辑(如 API请求结构、JSON 解析、上下文组装)。 * **吃透 ReAct核心模式**:通过代码实现了“推理 -> 行动 -> 观察”的循环流转,证明你深入掌握了 Agent 的灵魂机制,而不只是停留在概念层面。 **2.紧跟 AI风口,踩中面试官痛点** * **赛道前景好**:AI 编程(如 Claude Code)是目前大模型最成熟的落地场景之一。简历上有一个结合 LLM 的工程化项目,能迅速抓住面试官眼球,展现你对前沿技术的敏锐度。 **3.巧妙的面试“抓手”,可深挖的八股文** 这个项目像是一个“伪装成 AI项目的后端基础工程集”,面试官可以从很多角度提问,你都能对答如流: * **网络与 JSON**:如何用 OkHttp封装大模型请求?如何用 Jackson处理复杂的嵌套 JSON? * **Java基础**:如何用 Java17 的 `record` 定义不可变消息类?如何用 `ProcessBuilder`跨进程执行 Shell命令并捕获输出流? * **提示词与工程**:如何通过 JSON Schema 定义工具?如何编写系统提示词引导 LLM?如何控制 Token消耗和防止死循环? **4.具备极好的扩展性,证明架构设计能力** * **高内聚低耦合**:你设计了统一的工具接口,实现了工具的动态注册机制。这说明你具备产品级架构思维,后续极易扩展“数据库操作”、“Docker沙箱隔离”等高级功能。 **💡简历包装建议:** 不要只写“用 Java 写了个 Chatbot”,要突出核心机制与难点。 * *建议描述*:“基于 Java17纯手写实现极简版 Claude Code,不依赖
点赞
回复 取消回复
syx.hero 2026年06月16日 11:52
引用原文:可以把它存入向量数据库。需要时根据查询检索相关片段。
这个存入向量数据库的内容一般是上下文的对话层吗
点赞
回复 取消回复
受伤的指甲油 2026年06月08日 15:35
引用原文:最强大的工具,让 Agent 能执行任意 Shell 命令。这也最危险,实际产品中需要加权限控制。
execute_command 是自己设计的?还是系统自带的?@派聪明
1
回复1 取消回复
派聪明 2026年06月08日 15:36
`execute_command` 是**开发者自己设计并编写**的,而不是计算机操作系统自带的。 根据参考资料,它属于 Agent框架中自定义的一个“工具(Tool)”,主要有以下几个维度的说明: 1. **自己编写的执行逻辑**:在代码中,开发者定义了该工具的名称(`execute_command`)、描述(让 LLM知道何时该用)以及具体的执行逻辑。其底层是使用 Java标准库中的 `ProcessBuilder` 类来启动进程并执行 Shell命令的。 2. **遵循统一接口规范**:为了方便大模型(LLM)调用,开发者设计了统一的工具接口格式(包含 name、description、parameters等字段),并将这些格式化信息传给大模型。当大模型判断需要执行命令时,会输出对应的参数,再由 Agent框架拦截并调用这段自定义的 Java代码。 3. **强调权限与安全**:因为是自己设计的,它直接赋予了 Agent执行任意命令的最高权限,所以正如文中所说,这也是最危险的。在实际的生产级产品中,需要对这种自定义工具进行**安全改造**(例如加入沙箱隔离环境,或在执行高风险命令前增加“人工确认”环节)。
点赞
回复 取消回复
小塘 2026年06月08日 10:10
引用原文:Agent 要能理解我们的提示词,得能调用大模型。所以我们需要先封装一个 GLMClient,支持普通对话和工具调用。
对于OkHttpClient,是不是应该设计成全局共享变量,目前的设计有缺陷,
1
回复 取消回复
(zz) 2026年06月04日 21:48
引用原文:完整的 chat 方法
为什么不完整@派聪明
2
回复1 取消回复
派聪明 2026年06月04日 21:48
因为您在网页上看到的“完整的 chat 方法”,实际上是作者为了**精简文章篇幅**而做了代码省略(被省略号代替)。 根据参考资料,省略的部分主要包含以下核心逻辑: 1. **解析大模型响应**:提取 JSON 响应体中的 `choices` 等节点数据。 2. **提取消息与工具调用**:从返回的 JSON 中解析出助手的文本回复(`content`)和大模型请求的工具调用列表(`tool_calls`)。 3. **记录 Token 消耗**:提取并统计本次请求消耗的输入和输出 Token 数量(对应文章中展示的 `📊 Token使用`)。 4. **封装并返回**:将提取到的内容、工具调用请求和 Token 消耗数据,组装成一个 `ChatResponse` 对象返回给 Agent 继续流转。 作者在文中保留的代码已经展示了最核心的**组装请求参数**和**发送 HTTP 请求**的过程,而底部的注释 `// ...` 正是提示您解析响应数据的逻辑已被折叠。若要获取真正未省略的源码,需要访问文中提供的 GitCode 仓库链接。
点赞
回复 取消回复
(zz) 2026年06月04日 21:38
引用原文:这里有个关键点
上面代码是不是没给完全啊@派聪明
点赞
回复1 取消回复
派聪明 2026年06月04日 21:38
是的,你观察得很敏锐!文章中的代码确实没有给完全。 在这个教程中,作者为了控制篇幅,仅**截取了核心框架、关键逻辑和接口定义**作为展示。很多具体的实现细节被省略或用注释代替了。你提到的“这里有个关键点”那段代码之后,就有一句明显的省略注释: ```java // 提取消息内容、工具调用、token 使用等信息 // ... ``` 此外,像 `ChatResponse`、`ToolCall` 等关键的实体类,以及 `ToolRegistry` 中的辅助类(如 `createParameters` 用到的 `Param`)在文中都没有完整展现。 作者这样排版的主要目的是为了让读者**把注意力集中在 Agent 的核心原理(即 ReAct 循环和工具调用机制)上**,避免被几百行繁琐的 JSON 解析代码干扰。 如果你想获取包含所有细节、能完整编译运行的代码,文章末尾提到提供了完整的源码仓库,你可以去 gitcode 上获取完整版:`https://paicoding.com/ai-agent-projects-guide`。
点赞
回复 取消回复
沉默王二 2026年06月02日 13:48
引用原文:Claude Code、Qoder CLI
@派聪明 他俩和PaiCLI什么关系呢
点赞
回复1 取消回复
派聪明 2026年06月02日 13:48
根据文章内容,Claude Code、Qoder CLI 和 PaiCLI 的关系是:**它们虽然产品形态和复杂度不同,但在核心原理上是“同类”,本质上都是基于 Agent 循环(ReAct 模式)的不同实现。** 具体关系可以从以下两个角度理解: **1. PaiCLI 是它们的“超级简化版”** 文章作者为了弄清 Claude Code 和 Qoder CLI 等先进 AI 编程工具背后的实现原理,使用 Java 从零手写了 PaiCLI。 PaiCLI 仅仅用约 400 行代码,就提炼并实现了这类 AI 编程助手**最核心的运转机制**。它相当于一个基础骨架。 **2. 核心原理完全一致(都是 ReAct 模式)** 这三者在底层逻辑上没有根本性差异,都离不开三大核心要素: * **推理(LLM思考)**:理解用户需求,决定是否使用工具。 * **行动(工具调用)**:调用读写文件、执行 Shell 命令等外部工具。 * **观察(获取结果)**:将工具执行的结果反馈给大模型,让其继续思考下一步,直到任务完成。 **总结来说:** **Claude Code 和 Qoder CLI** 是功能完善、体验成熟的生产级 AI 编程产品;而 **PaiCLI** 是作者为了向读者拆解、展示上述产品背后底层原理而打造的“教学演示版”。
点赞
回复 取消回复
微信用户 2026年05月19日 15:47
引用原文:后,我们需要一个交互式命令行界面,让用户能输入指令、看到结果。
@派聪明 测试
点赞
回复 取消回复

目录