Roog's BLOG & TOOLS

[系统已在线] :: 2026-01-30 16:10:21 :: 终端 v1.0

Posts

算法工程化算力方案设计

我们的根本需求其实有两点:

  • 解决不确定的算力需求
  • 解决算法同学工程化能力不足
  • 解决后端同学集成难读过高

硬需求：

  • 入口与流量
    • 流量可视化
  • 进程/部署
    • 自动化算力动态扩缩
    • 自动化部署
  • 健康观测
    • 指标收集与可视化
    • 服务健康查询
  • 韧性

值得一提的是，任何一个硬需求部分都不是一蹴而就的，也许我们需要按照优先级先实现其中一部分，或者实现其中大部分的一个起点

Claude Code 基础分享IV - 提示词与工作流

什么是工作流

我不太希望把工作流和n8n搭建的自动化工作流混淆，n8n搭建的工作流很大程度上是为了适配固定的情景和模式，在我们的日常工作中，工作流更多是变化的，需要根据具体需求进行定制和调整。

好消息是这并非很复杂或者耗时，你更多的是在着手工作之前为任务制定一个小目标，然后试着思考如何达成它，你自己的工作流很大程度上是关于“我该如何操作claude code”，而不是我该如何搭建一个自动化工作流。

梳理你的工作

在任务开始之前，你需要至少做两件事

  • 明确的目标
  • 可被量化分解的计划

让我们以一个图书管理系统来做例子

“我想要一个图书管理系统” 是一个不够明确的目标。

Claude Code 基础分享III - MCP 和 Subagent

在上一篇内容中，我们叙述了Claude Code的上下文机制，包括了Slash Command、Skills和Context的使用方法。

本篇内容将深入探讨Claude Code的两个核心概念：MCP（Model Context Protocol) 和 Subagent。

  • MCP是Agent和外部服务的通信协议，它定义了Agent如何与外部服务进行交互，如果对技术细节感兴趣，可以查阅官方文档。
  • Subagent是Agent的子Agent，它可以在Agent中运行，可以访问Agent的上下文，可以与外部服务进行交互。总的而言Subagent就像一个由Agent委派任务的小兄弟，帮它完成一些任务。

虽然看起来Subagent和MCP都是全新的概念，但事实上它们实际的表现形式仍旧和上下文高度相关，它们都是为了扩展Agent的能力而设计的。

Claude Code 基础分享II - SKILL COMMAND COMPACT 一切都是上下文

在我个人粗鄙的理解中，所有，所有这一切

都是上下文

什么是上下文？

上下文，是claude code 与你交互时，所有信息的总和，包括你发送的prompt，claude code的回复，claude code执行的命令，claude code编辑的文件，claude code的思考过程，claude code的计划文件，所有这些全都是上下文。

Claude Code 基础分享I - 安装与基础使用

安装与基础使用

使用如下命令全局安装即可(你需要node >= 22.0)

npm install -g claude-code

基础配置

配置文件位于 ~/.claude-code/config.json，你可以通过编辑该文件来配置Claude Code的行为。

如何配置opencode在web场景下工作

opencode 简介

opencode 是一个基于 OpenAI API 的工具，旨在帮助开发者更高效地进行代码开发和调试。它通过提供智能提示、代码补全和错误修复等功能，极大地提高了开发效率。在 web 场景下，opencode 可以通过浏览器扩展或集成到 IDE 中，为开发者提供实时的代码支持。

Claude Code vs OpenCode：AI 编码助手能力对比

概述

Claude Code 和 OpenCode 都是终端 AI 编码助手，但它们在设计理念、开放性和功能上存在显著差异。

核心差异

开源性

  • Claude Code：闭源，由 Anthropic 官方开发维护
  • OpenCode：开源（GitHub: anomalyco/opencode），社区驱动

模型支持

Claude Code

Crush 代码修改工具学习

Crush 代码修改工具学习

概述: Crush是什么?

Crush 是由 Charm 开发的一款开源 AI 编程助手框架，它将大语言模型（LLM）与开发工具深度集成到终端环境中。本文将深入分析 Crush 中负责代码修改的核心工具实现，揭示其如何在保证安全性和可靠性的前提下，实现智能化的代码编辑功能。

ARS 第一版草稿设计（V）Tools Provider（Agent 提供者）

在前两篇中，我们已经完成了 **ChatSession / Message / SSE 和 Orchestrator 的基础实现， 目前已经可以顺利的用Dummy(假接口)做成了一个 可以正常交互的应用。(Orchestrator 目前还是非流式，这个可以回头再说)

ARS 第一版草稿设计（IV）Agent Provider（Agent 提供者）

在前两篇中，我们已经完成了 **ChatSession / Message / SSE 和 Orchestrator 的基础实现， 目前已经可以顺利的用Dummy(假接口)做成了一个 可以正常交互的应用。(Orchestrator 目前还是非流式，这个可以回头再说)

ARS 第一版草稿设计（III）Agent Orchestrator（Agent 编排器）

在前两篇中，我们已经完成了 ChatSession / Message / SSE 等基础设施的设计与实现， 至此，一个“可持久化、可回放、可续传”的对话系统已经成型。

这一篇开始进入 ARS 的核心能力：

为什么我没有用 LangChain（以及我为什么一点都不后悔）

LangChain 不是不好，而是它解决的问题，和我正在解决的问题，并不一致。

我在做一个偏底层的 Agent Runtime Server（不是写 Demo 那种），被朋友问了一句：

“你为什么不用 LangChain？不是很方便吗？”

ARS 第一版草稿设计（II）ChatSession

💬 Chat Session - 会话管理

Chat Session 的本意是一次完整的对话上下文，由于这个系统需要维持多套的上下文存在所以必须有实体ID。

同时 session 中不可能仅包含一次对话，我们需要进一步拆分成同一个 session 中的多个 message。 Message 是事实（source of truth），Session 是投影（projection / cache）。 这样遇到“双写不一致”时才有可依赖的裁决标准。 结构上，差不多是这么个样子

ARS 第一版草稿设计（I）愿景与主体

🎯 愿景

我要构建一个 Agent Runtime Server，最终的愿景如下:

✅ 核心目标

  1. 🔄 能兼容大部分的Agent 模型
  2. 💻 随时能在web终端中输入新的指令
  3. 📊 随时在web终端中查看Agent运行日志
  4. 🔌 即便在web终端断开链接，Agent也能正常执行
  5. 🔙 重新连入web终端，能继续之前的Agent会话

💡 我需要的真正能力 - 改变现有的开发方式：