KatzenyaSax: Hello!

AI Coding 从 vibe coding 到 spec coding，再一步步发展到 Harness Engineering，已经有了众多实证，正确使用 AI 非但不会带来破坏，反而带来了增益，相信每一个使用过 AI 的开发者，都无法回到古法编程了，AI 的开发效率就是高于人类，人类没有必要否认，更没必要对抗，所以问题已经转变为：怎样使用 AI 写出我们想要的代码？每个开发者有自己的工作流，也有自己的理解，不必分个高下，只要能实现需求交付那就是好的。 我本人在26年3月接触过当时还是最佳实践的 superpowers + gstakc 构成规划、执行、验证的工作流，但是后来将精力投入到其他去了，后面出现的 trace、审计这些完全没有接触过了，所以对 AI Coding 实践算是重新开始学习，我的想法是使用 AI Coding 从立项到真实上线，完成一个类贴吧论坛项目，全程不自己写一行代码，找到适合自己的 AI Coding 实践方法。 项目之前在项目开始之前，我想尽可能地表达一下我目前对 AI Coding 如何写出可靠代码这个问题的理解。 打铁还需自身硬使用 AI 写需求的前 ...

LLM/Agent 安全实战：从 Prompt Injection、工具越权到沙箱隔离

ki 核心设计Ki Agent Loop主要入口是 runTurn，由 RpcServer 和 Subagent 调用，当用户输入一条 query 时正式开启 agent loop。 主要有以下流程：发起事件 -> 处理会话标题（新会话专属，旧会话跳过） -> 等待 loop 完成 -> 处理异常（如果有的话） 等待 loop 完成 中的 #loop 才是内部主要运行主体，根据 llm 的工具意图作为循环依据，主要流程为：开始循环 -> 是否压缩 -> 构建 context -> 流式调用 llm -> 处理工具意图 -> 继续循环。 构建 context#buildRequest 方法用于构建 context，主要拼接：系统提示 + 历史消息 (含工具调用/结果/压缩) + 完整工具信息 + 模型 + 中断信号 + 思考预算。 这个方法做了什么： 123456789101112return { system: this.#buildSystemPrompt(), messages: this.#toPr ...

Ki - 工具结果留痕机制开发 - 记一次失败的开发工具结果索引化这个想法来源于一个客观事实，就是工具结果往往有一大段，但是真正对 LLM 来说有用的部分却很少（比如），其余的绝大多数文本（比如各种打印日志、输出语句、结构化关键字关键符号）都是没用的，但是这些文本都会被统一收入到上下文，在上下文压缩前，这些大段的无用文本一直占用上下文，随着工具调用频次增加，上下文累积速度会不断加剧；同时无用文本的大量存在也会极大地影响 LLM 的工作，俗称上下文污染。 针对这个问题，我设想了一套机制，通过动态剔除无用信息，只保留有用信息，从而优化上下文管理。因为工具结果作为文本，其具备行的概念天然可以索引化，只有有行号就可以用来表示正文。 初版方案是，在工具结果回填给 LLM 时，我们就让 LLM 输出一个 json schema 来标明该工具结果的哪些行是有用的，随后落实到 session.jsonl 时做出增量标记：该工具结果只有某些片段有用。而后续 runtime 从 session.jsonl 读取数据加载到 context 时，就只保留这些区间内的文本，忽略之外的文本。 也就是说，针对工具调 ...

RAGRAG 基础概念RAG 基础概念：检索、生成与工程取舍 RAG（Retrieval-Augmented Generation，检索增强生成），就是为用户的 query 匹配更多信息，强化 LLM 是生成。 基于向量数据库的 RAG 聚焦的核心问题：不同表达、同一语义 知识时效性：能够为停止更新知识的 LLM 提供更新的知识。 私有数据：一些私有数据，不可能直接在训练中喂给 LLM，将其部署在外部数据库，更加安全。 幻觉问题，严格来说幻觉是 LLM 本身的缺陷，设置 RAG 只能降低幻觉。反而 RAG 系统本身更有可能助长幻觉，比如检索失败，检索错配等问题。 不过，以上三点都是胡扯，这些问题是个数据库都能解决，RAG 或者说目前主流的基于向量数据库的 RAG 系统聚焦的核心反而是词不一样，但意思一样问题，就比如 Redis 里面 数据过期了 key过期了 TTL过了，三个不同的词语对应同一个意思：数据怎么没了，这是传统检索方法无法做到的。 然而，正因如此，主流 RAG 又面临一个检索准确性的问题，传统的关键词检索，检索出来就百分之百准确，而 RAG 检索大概率同时存在多个语 ...

HarnessEngineeringHarness Engineering：六层检查框架、上下文管理与工程实践 Harness一个很有名的公式将 Agent 概括为：Agent = Model + Harness。 其中 Model、LLM 虽然是 Agent 的决策中枢，却完全没有任何活动能力，堪称“缸中之脑”，它既没有记忆能力，无法选择上下文，也无法使用工具，甚至无法感知到外界，只能处理输入的文本。 而 Harness 就是为了补足裸露 LLM 的缺陷而被创造出来的产物。LLM 没有记忆？不能用工具？不能感知外界？没关系，由我们人类为 LLM 创造一个沙箱环境，只要能完成工作，它需要什么，我们就给它什么，一切以 LLM 的判断为准，我们只做后勤工作，换言之，我们要做一个全盘支持 LLM 运作的环境。 然而，我认为 Harness 还应当再次分层，将其分为 Runtime 和 Capacity 。前者为 Agent Loop 的运行时环境，包括工具系统、记忆系统、上下文管理系统、Agent Loop 感知反馈循环等，将之组成为一套独立的软件系统，缺少任何一个组件就无法使 R ...

Agent面试题总结Agent 基础 AI Agent 是什么？和普通 Chatbot 有什么区别？ 一句话：Agent 是一套能够感知环境、理解任务、自主规划、能调用一定外部工具最终完成任务的一套系统。 区别：普通的 ChatBot 围绕 “对话”，其中只有 LLM 一个环节，即 用户输入 -> LLM处理 -> LLM直接输出；而 Agent 则是 用户输入 -> LLM理解任务 -> LLM规划任务 -> 调用工具 -> 完成执行 的复杂流程，LLM 的输出不会直接一次性展示给用户，而是用于完成任务，这就是两者的核心区别：前者至少为了生成内容，后者则是完成任务。 细分维度：可以从以下维度对比：核心目标、行为模式（文本生成 vs 理解+决策+执行）、工具调用、自主性、记忆、任务复杂度、环境感知、反馈闭环。 更深：Agent 的核心组成？下一道题 Agent = LLM + Planning + Memory + Tools + Enviorment + Action Loop 这条公式怎么理解？ 一句话：即目前 Agent 的主流 ...

MultiAgent多 Agent 协作系统设计：任务拆分、状态共享、冲突处理与失败恢复 MultiAgent & PromptChain什么叫 PromptChain？这是 Agentic Workflow 中的概念，LLM 在 Workflow 中不再负责整体规划，而只负责节点的实现，针对每个节点预先输入 Prompt，LLM 跟随 Workflow 进程就能依次执行。 二者对比： 对比项 多阶段 Prompt Chain 多 Agent 执行单元 一条 Workflow 中的处理节点 可以独立完成子目标的 Agent 工作方式 节点按照既定逻辑处理输入并产生输出 Agent 可以选工具、观察结果并迭代执行 控制方式 Workflow 负责节点跳转和状态流转 可以用固定编排，也可以由模型动态委派 上下文 上下文通常沿处理链路传递 可以按 Agent 隔离上下文、工具、权限和状态 运行状态 主要关注整条链路执行到了哪个节点 还要区分各 Agent 的任务、状态、尝试次数和交付结果 结果交付 节点输出通常作为后续节点的输入 可以传消息、共享状态， ...

MCP什么是 Model Context Protocol (MCP)？和 Function Calling、Agent 什么关系？ MCP 是为 Agent 提供工具的，只不过它的工具是运行在云端或本地其他服务上的，Agent 需要经过一层 MCP客户端 -> JSON RPC协议 -> MCP服务器（其他服务） 才能注册和使用 MCP 提供的工具，省了我们手动定义工具，也防止 Agent 和 Tool 的高度耦合。 前 MCP 时代在前 MCP 时代，工具是与 Agent 高度耦合的，不管是 Agent 内部的函数工具，抑或是对象工具都是如此。 在 Agent 启动时，会将自己所有的工具的 name 和 description 以列表的形式加载到内存内，并最终拼接到上下文的系统提示词内，到运行时 LLM 判断需要使用工具时就查看 system prompt 中有哪个工具直接告诉 Agent 调用就行了。 这样一来缺点很明显，不能复用、依赖手动编写、Tool 间容易重复定义。 MCP 三要素与 MCP 工作流程MCP 问世之后，MCP 将 Agent 与 Tool 解耦了 ...

SkillAgent Skills 是什么？和 Prompt、MCP 到底差在哪？ Skill本质本质：一串 Prompt，告诉 LLM 某个任务该怎么做（经过哪些步骤、怎么才算合格等），相当于一个用自然语言描述的 Workflow。 一个 Skill 通常采用文件夹存储，其结构如下： 12345skill-name/├── SKILL.md # 主文件，触发时加载├── scripts/ # 实用脚本（执行，不需要加载到上下文）├── references/ # 参考资料（按需加载）└── assets/ # 模板和静态文件（按需加载） SKILL.md 是正文，每次调用时加载到 Context 中。 元数据Skill.md 的内容包含元数据和正文，元数据举个例子 matt 的 teach 如下： 123456\---name: teachdescription: Teach the user a new skill or concept, within this workspace.disable-model-i ...