ladydd

banan2 对比 wan2.7 pro

阿里的新发的版本，用同样的图+同样的提示词进行两个模型的测试 三联图： 输入图-banana图-wan2.7pro 图

LTX-2.3 本地部署完整复盘

先把结论放前面：LTX-2.3（22B）这条 pipeline 在 4×RTX 3090（24GB）这套硬件上，按官方默认推理方式基本跑不起来。我最终得到的不是“没跑通”，而是一个更有价值的结果：把它为什么跑不起来、卡在哪、该怎么判断“物理不可行”，完整验证了一遍。 这篇文章是一次本地部署的工程复盘：从模型文件下载、依赖链补齐、环境和代码层踩坑，到显存拆分、多卡 device 规划，再到最终 OOM 的边界判断。希望你在遇到类似“看起来只要把权重放进去就能跑”的大模型工程时，可以少走很多弯路。 TL;DR（1 分钟读完） * LTX-2.3 不是单模型，而是一个多组件 pipeline：文本编码器（Gemma）+ 视频 diffusion 主模型（

一次 generate-prompts 服务连续超时事故的完整排查记录

背景 一个平时很稳定的服务，在 2026-04-02 这天突然出现“连续失败”。 最让人难受的不是失败本身，而是失败信息太少：日志里只有一串「第 1 次请求失败」，没有异常类型、没有耗时、没有栈。 这种时候人的直觉会把怀疑撒向四面八方：逻辑是不是坏了、参数是不是不对、上游是不是抽风、网络是不是波动……但没有证据，一切都只是猜。 1. 先把故障“照亮”：只补日志，不动行为 线上系统已经跑了很久，第一原则是：先让问题可见，但不要一上来就改主逻辑。 我加的日志只做两件事： * 把“这次请求到底发生了什么”讲清楚 * 保持所有行为不变（重试次数、超时、请求参数、返回解析都不动） 具体补充项包括： * 请求开始时的关键信息（目标地址、超时、参数摘要、prompt 长度） * 当前是第几次重试、总重试次数 * 每次请求耗时

快手 KAT-Coder-Pro V2 模型测试

市面上几乎没人聊这个模型，反倒让我很好奇，我决定全面测评使用一下 StreamLakeStreamLake溪流湖是快手toB视频云平台，提供领先的音视频AI解决方案。包含KAT-Coder智能编程助手、万擎大模型平台、视频云服务、直播云、点播云、实时音视频RTC等产品。基于前沿AI技术和音视频算法，为企业提供智能代码生成、视频处理、内容理解、智能审核等全链路服务，助力数字化转型。StreamLakeStreamLake 付完款发现上下文只有256K , 到今天来说 已经落后了 而且不支持视觉，也没有mcp接入 联网搜索之类的东西 确实是远远落后了 时隔半年再次看快手模型的官网，发现现在几乎就主打这一个模型了 coding plan用这个，然后api 调用这个是， 接入openclaw 也是这个，总之一个模型走天下，看上去太穷了，像是随时跑路的状态，但其实我很喜欢这种方式, 一个模型通杀所有场景 哈哈哈 接入 opencode 中使用 开了一个新的项目，决定保守一点，先让写文档， 之后再生成代码 下面是实际的体验 1. 不断 chat

在 Mac mini 上把 OpenClaw 跑起来：从证书坑到 Qwen 接入（实战记录）

这篇记录的是我在一台 Mac mini（中国大陆网络环境）上安装并跑通 OpenClaw 的全过程：从一键安装开始，接入阿里 DashScope 的 OpenAI 兼容接口（Qwen），一路踩到 Node TLS 证书链问题，最后用 nvm 彻底解决，并成功进入 openclaw tui。 背景与目标 我想在本机快速体验 OpenClaw（一个可执行工具调用的 AI Agent 框架）。目标很明确： * 在 macOS 上装起来 * 不依赖海外大模型（尽量不需要外网） * 用 Qwen（DashScope 的 OpenAI-compatible 接口）作为模型后端 * 最终能启动到交互界面（TUI） 环境 * 设备：Mac mini

08｜其余包扫盲：tui / web-ui / mom / pods 各自负责什么

这篇写什么 补齐主链路之外的包：tui、web-ui、mom、pods。它们不是前两层核心抽象，但决定了这套体系如何被真正使用、展示和部署。 快速定位 * tui：终端 UI 引擎（输入、渲染、选择器、弹层等体验基础设施） * web-ui：Web 场景的 chat/agent UI 组件库 * mom：Slack 里的 agent bot 产品 * pods：远程 GPU pod 上的模型部署与运行管理 packages/tui 它不参与模型调用和 agent loop，但决定 terminal 产品是否“像一个真正应用”而不是 stdout 脚本。 packages/web-ui

07｜主 Agent 与 Tools：一套可迁移的设计方法

这篇写什么 把两份偏方法论的笔记（主 Agent 设计、Tools 设计）合并成一篇：给出一套可迁移、可施工的 agent 产品设计方法，不依赖编程场景。 主 Agent：先设计任务闭环，不要先写 prompt 主 agent 不是“一个大 prompt”，而是：任务边界、角色定义、行为规则与闭环运行方式的组合。 一个可用的主 agent，首先要回答： * 核心目标是什么 * 完成标准是什么 * 默认怎么推进 * 何时继续、何时停止 * 遇到失败怎么处理 提示词只是这些设计的表达载体，不是起点。 主 Agent 的设计骨架（建议写清楚） * 目标定义 * 输入定义（用户通常怎么提任务） * 输出定义（你最终返回什么形态） * 完成条件与停止条件 * 默认策略（模糊时问还是猜、

06｜pi-coding-agent：把通用能力装配成“可用的编程代理产品”

这篇写什么 讨论 packages/coding-agent 这一层如何把 pi-ai 与 pi-agent-core 装配成一个面向编程场景的真实产品：它关心 session、默认工具集、动态 prompt、扩展点，而不只是抽象。 先说结论 pi-coding-agent 的定位更准确地说是：面向编程场景的 agent 产品装配层。如果前两层分别是：pi-ai：统一模型调用pi-agent-core：统一 agent loop那么第三层做的是：把模型、runtime、prompt、tools、session、settings、extensions 与交互模式一起装配成一个终端里的 coding product。 为什么第三层才开始真正绑定编程场景 前两层更通用；第三层必须选择一个明确落点。这里的落点非常清晰：代码仓库工作流。默认工具集（read/write/edit/bash）就是最直接的场景宣言。 第三层的中心：

05｜pi-agent-core：闭环、回灌与“继续/停止”到底谁说了算

这篇写什么 聚焦 pi-agent-core 最关键的运行机制：tool loop（闭环）与工具结果回灌，以及 runtime 如何决定“继续下一轮还是结束”。 先说结论：tool loop 才是 agent pi-agent-core 的核心不是“支持 tool calling”，而是把 tool calling 变成 tool loop： 模型提出工具调用 -> runtime 执行工具 -> 工具返回结果 -> 结果回灌上下文 -> 再次调用模型 -> 判断是否继续 只要这条链路成立，系统才真正像 agent；否则只是“会发工具意图的聊天模型”

04｜pi-agent-core：为什么 tool calling 不等于 Agent

这篇写什么 只讲一个关键点：为什么“模型会吐 tool call”不等于“系统是 agent”，以及 pi-agent-core 这一层到底补上了什么。 先说结论 pi-agent-core 的本质不是“再包一层模型调用”，而是：把一次模型调用变成一个可以持续推进任务的运行时闭环。 * pi-ai 解决：怎么把不同模型统一接起来 * pi-agent-core 解决：怎么让模型不只是回答，而是真正持续工作 为什么第一层还不够 如果系统只有模型抽象层，能力更接近： * 把上下文发给模型 * 接收模型返回 * 把流式输出展示出来 即便模型支持 tool calling，这时也还没有“agent 感”。 因为“模型会吐出 tool call”不等于“系统能把任务做完”。 用户真正感知到的 agent 能力通常是： * 它会自己去查信息 * 它会自己调用工具 * 它会根据结果继续下一步 * 它不是一轮问答，

03｜pi-ai 的输入输出：事件流、最终消息与可重放上下文

这篇写什么 聚焦 pi-ai 的统一输入输出协议：为什么要把输出分成“事件流”和“最终消息”，以及为什么“可重放性”是 agent 系统的关键约束。 先说结论 pi-ai 的核心价值是：把多厂商模型调用统一成一套对 agent 友好的输入输出协议。 对 agent 友好意味着它要覆盖： * 多轮上下文 * 工具调用 * 流式增量输出 * thinking/reasoning * usage/cost * 失败与中断 * 跨模型继续对话 统一输入：上层真正需要表达的只有四类 1. 用哪个模型 2. 当前上下文是什么 3. 这轮可以用哪些工具 4. 这轮调用的运行参数是什么 模型输入不是字符串 模型对象应携带能力与调用语义：provider、协议类型、上下文窗口、是否支持 reasoning/多模态、成本与兼容配置等。

02｜pi-ai：为什么需要单独一层来统一模型调用

这篇写什么 只讲 packages/ai（pi-ai）的设计动机与职责边界：它到底统一了什么、为什么对 agent 很关键、它和 pi-agent-core 的分工是什么。 先说结论 pi-ai 的本质不是“又一个模型 SDK”，而是：一个面向 agent 场景的多模型统一抽象层。 它的目标是把不同厂商、不同协议、不同风格的大模型调用方式，收敛成一套统一输入输出标准，让上层系统稳定工作。 为什么值得单独做一层 如果没有这一层，上层会直接面对： * 不同厂商的 API 结构、消息格式、流式协议差异 * tool calling 表达差异 * reasoning/thinking 支持差异 * usage / cost 统计差异 最终会导致： * agent 层被 provider 细节污染 * 每加一个