犀利豆的博客

高质量的技术博客

一、起因:LLM 一次调用不够

我做了个工具—— text2everything.vip 自然语言描述流程,LLM 出 Mermaid 代码,右边实时渲染。

第一版是单次调用:用户输入 → LLM → 出图。跑了几个月发现两类问题:

  • 语法错了没救 —— LLM 生成的代码看着对,Mermaid 渲染直接 Parse error,用户看到红色堆栈就走了。
  • 语义偏了不自知 —— 用户说”画个登录流程”,LLM 惯性给你加个”发送验证码”,既不问,也不告诉你它加了。

这两个问题都不是”再调 prompt”能治的:第一次失败得有第二次机会;补常识没错,但必须留痕才能审计。

所以第二版做成一个 agent:能多轮对话,能自己纠错,能记住用户说过什么。这篇讲一下这个 agent 长什么样。

Read more »

介绍我最近做的一个小工具 text2mermaid(text2everything.vip)——用自然语言描述流程、时序、表关系、状态机等,AI 直接生成 Mermaid 代码并实时预览,支持 flowchart / sequence / ERD / state / class / mindmap / gantt 七种图,可导出 SVG / PNG,免注册免费用。文章讲清楚了做这个工具的动机、和手写 Mermaid / 传统画图工具的对比、以及三个真实使用场景。

Read more »

用 Obsidian 替代 idea 作为 AI 时代的"认知承载层"——把 Andrej Karpathy 的「Obsidian is the IDE, LLM is the programmer, wiki is the codebase」落到实处:Claudian 插件 + 根 CLAUDE.md schema + Ingest / Query / Lint 三个操作,再加上一次两周跨度重构的实战复盘和两条可直接跑的 Vault Lint prompt。

Read more »

AI in Harness 系列收官篇——把前三篇(Loop / Tools / Skill / Memory、Error Recovery / Task System / Background Task、Multi-Agent 协同)串起来给出 Harness 的完整定义:让 LLM 在"受控循环"中工作的一整套基础设施。附模块总览图、每个模块的职责边界、模块之间的调用关系,回答"什么是 Agent Harness、和 Agent Framework 有何区别"。

Read more »

AI in Harness 系列第三篇——为什么 Subagent + Background Task 之后还需要多 Agent 协同:Agent 之间的通信 Protocols、Autonomous Agents(自主 Agent)如何让主控在长任务中"托管"给下游、以及用 git Worktree 做并发文件写入隔离避免相互覆盖,让多个 Agent 真正能同时改代码。

Read more »

AI in Harness 系列第二篇——LLM 长周期任务如何跑得稳、跑得远:错误恢复(Error Recovery)如何区分可重试/致命错误并降级、Task System 如何做任务规划与依赖调度、Background Task 如何在主循环之外并发执行长耗时子任务并回写结果。以 Java Harness 框架的实现代码作为落地参考。

Read more »

AI in Harness 系列第一篇——从 Prompt Engineering 到 Loop Engineering 再到 Agent Harness 的演进:为什么"能跑"的 Loop 还不够,Harness 需要在此之上补齐 Tools、Skill、Memory 三块能力,以及 CLAUDE.md / 系统提示词 / 用户消息 / 工具结果的上下文分层加载策略。以 Java 视角剖析 Claude Code 实现,配可运行的开源 Java Harness 框架。

Read more »

负载均衡

前端

使用 DNS 进行负载均衡。在 DNS 回复中提供多个 A 记录或者 AAAA 记录。
虽然 DNS 看起来简单,但是存在不少问题。

  1. DNS 对客户端行为的约束很弱:记录是随机选择的。
  2. 客户端无法识别“最近”的地址
  3. 权威服务器不能主动清楚某个解析器的缓存,DNS 记录需要保持一个相对低的失效值(TTL)。
Read more »

事后总结:从失败中学习

哲学

保证事故能够被记录下来,理清所有根源问题。确保实施有效的措施是的未来重现的几率和影响得以降低,甚至避免。

书写事后总结不是一种惩罚,而是整个公司的一次学习机会。

需要书写的标准:

  • 用户可见的宕机或者服务质量下降到一定标准
  • 任何形式的数据丢失
  • on-call 工程师需要人工介入
  • 问题解决耗时超过一定限制
  • 监控问题
Read more »
0%