agent
1. Agent 和 harness 的边界 这是我在理解过程中非常关键的一点。 当前我的理解： * Agent 负责“决定做什么” * Harness 负责“把事情做成可调用能力” 也就是说： * Agent 更像策略层、决策层、编排层 * Harness 更像能力层、执行层、适配层 Harness 本身不是 Agent，它更像是 Agent 可调用的工具系统。 2. 这个项目的反馈机制属于哪一类 我之前会自然想到“自我反思型”的 harness： * 会自动评估自己做得好不好 * 会自动调整策略 * 会自动重规划 但这个项目里的 harness 并不强内建这种运行时自我反思。 它更强的是： * 可观察：info、list、status、history * 可验证：真实输出检查、E2E 测试、
agent
1. 为什么我会觉得这个项目里的 harness 有点奇怪 因为我之前接触过的 harness，更像是： * 一个黑盒环境 * 给 LLM 设定边界和工具 * 让 LLM 在里面自己探索、执行、达成目标 而这个项目里的 harness 明显不是这个意思。 2. 这个项目里的 harness 是什么 当前我的理解： 这里的 harness 更像是“站在 Agent 视角，为某个具体软件搭建的一整套能力接入系统”。 它不只是一个脚本，也不只是一个 CLI 文件，而是通常包含： * CLI 入口 * core 业务模块 * backend 真实软件适配 * session 状态管理 * tests * README * TEST.md * SKILL.md
agent
1. 我最开始看到的现象 这个仓库根目录下有很多不同的软件目录，例如： * gimp/ * blender/ * libreoffice/ * drawio/ * zotero/ 所以它不是单一应用，而是一个多软件、多 harness 的总仓库。 2. 项目在做什么 我目前的理解： CLI-Anything 想把原本主要通过 GUI 使用的软件，整理成 Agent 也能稳定调用的 CLI 接口。 它不是简单做几个命令，而是在做一套标准化的软件能力接入方案。 3. 这里的 CLI 到底是什么意思 我一开始容易把 CLI 理解成“黑框里的自由互动”。 后面逐渐明确： * 终端/黑框：只是运行环境 * CLI：是能力暴露出来的命令接口 * 脚本：是实现 CLI 的一种方式 所以这里的 CLI 更接近“面向终端的函数调用接口”
AI
阿里的新发的版本，用同样的图+同样的提示词进行两个模型的测试 三联图： 输入图-banana图-wan2.7pro 图
AI
先把结论放前面：LTX-2.3（22B）这条 pipeline 在 4×RTX 3090（24GB）这套硬件上，按官方默认推理方式基本跑不起来。我最终得到的不是“没跑通”，而是一个更有价值的结果：把它为什么跑不起来、卡在哪、该怎么判断“物理不可行”，完整验证了一遍。 这篇文章是一次本地部署的工程复盘：从模型文件下载、依赖链补齐、环境和代码层踩坑，到显存拆分、多卡 device 规划，再到最终 OOM 的边界判断。希望你在遇到类似“看起来只要把权重放进去就能跑”的大模型工程时，可以少走很多弯路。 TL;DR（1 分钟读完） * LTX-2.3 不是单模型，而是一个多组件 pipeline：文本编码器（Gemma）+ 视频 diffusion 主模型（
Python
背景 一个平时很稳定的服务，在 2026-04-02 这天突然出现“连续失败”。 最让人难受的不是失败本身，而是失败信息太少：日志里只有一串「第 1 次请求失败」，没有异常类型、没有耗时、没有栈。 这种时候人的直觉会把怀疑撒向四面八方：逻辑是不是坏了、参数是不是不对、上游是不是抽风、网络是不是波动……但没有证据，一切都只是猜。 1. 先把故障“照亮”：只补日志，不动行为 线上系统已经跑了很久，第一原则是：先让问题可见，但不要一上来就改主逻辑。 我加的日志只做两件事： * 把“这次请求到底发生了什么”讲清楚 * 保持所有行为不变（重试次数、超时、请求参数、返回解析都不动） 具体补充项包括： * 请求开始时的关键信息（目标地址、超时、参数摘要、prompt 长度） * 当前是第几次重试、总重试次数 * 每次请求耗时
AI
市面上几乎没人聊这个模型，反倒让我很好奇，我决定全面测评使用一下 StreamLakeStreamLake溪流湖是快手toB视频云平台，提供领先的音视频AI解决方案。包含KAT-Coder智能编程助手、万擎大模型平台、视频云服务、直播云、点播云、实时音视频RTC等产品。基于前沿AI技术和音视频算法，为企业提供智能代码生成、视频处理、内容理解、智能审核等全链路服务，助力数字化转型。StreamLakeStreamLake 付完款发现上下文只有256K , 到今天来说 已经落后了 而且不支持视觉，也没有mcp接入 联网搜索之类的东西 确实是远远落后了 时隔半年再次看快手模型的官网，发现现在几乎就主打这一个模型了 coding plan用这个，然后api 调用这个是， 接入openclaw 也是这个，总之一个模型走天下，看上去太穷了，像是随时跑路的状态，但其实我很喜欢这种方式, 一个模型通杀所有场景 哈哈哈 接入 opencode 中使用 开了一个新的项目，决定保守一点，先让写文档， 之后再生成代码 下面是实际的体验 1. 不断 chat
AI
这篇记录的是我在一台 Mac mini（中国大陆网络环境）上安装并跑通 OpenClaw 的全过程：从一键安装开始，接入阿里 DashScope 的 OpenAI 兼容接口（Qwen），一路踩到 Node TLS 证书链问题，最后用 nvm 彻底解决，并成功进入 openclaw tui。 背景与目标 我想在本机快速体验 OpenClaw（一个可执行工具调用的 AI Agent 框架）。目标很明确： * 在 macOS 上装起来 * 不依赖海外大模型（尽量不需要外网） * 用 Qwen（DashScope 的 OpenAI-compatible 接口）作为模型后端 * 最终能启动到交互界面（TUI） 环境 * 设备：Mac mini
agent
这篇写什么 补齐主链路之外的包：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
agent
这篇写什么 把两份偏方法论的笔记（主 Agent 设计、Tools 设计）合并成一篇：给出一套可迁移、可施工的 agent 产品设计方法，不依赖编程场景。 主 Agent：先设计任务闭环，不要先写 prompt 主 agent 不是“一个大 prompt”，而是：任务边界、角色定义、行为规则与闭环运行方式的组合。 一个可用的主 agent，首先要回答： * 核心目标是什么 * 完成标准是什么 * 默认怎么推进 * 何时继续、何时停止 * 遇到失败怎么处理 提示词只是这些设计的表达载体，不是起点。 主 Agent 的设计骨架（建议写清楚） * 目标定义 * 输入定义（用户通常怎么提任务） * 输出定义（你最终返回什么形态） * 完成条件与停止条件 * 默认策略（模糊时问还是猜、
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）就是最直接的场景宣言。 第三层的中心：
agent
这篇写什么 聚焦 pi-agent-core 最关键的运行机制：tool loop（闭环）与工具结果回灌，以及 runtime 如何决定“继续下一轮还是结束”。 先说结论：tool loop 才是 agent pi-agent-core 的核心不是“支持 tool calling”，而是把 tool calling 变成 tool loop： 模型提出工具调用 -> runtime 执行工具 -> 工具返回结果 -> 结果回灌上下文 -> 再次调用模型 -> 判断是否继续 只要这条链路成立，系统才真正像 agent；否则只是“会发工具意图的聊天模型”
陕公网安备61011302002223号