Conversation as Database：OpenHands 的无状态 Agent 与事件运行时
凌晨两点，Agent 准备给一个 GitHub issue 添加“修复已完成”的标签。 ActionEvent 已经写进日志。GitHub API 也返回了 200。就在 SDK 把结果包装成 ObservationEvent 之前，进程崩溃。 重启以后，历史里只剩一条没有 observation 的 action。 ...
Monitoring
多 Agent 辩论真的增加了信息吗：TradingAgents 的组织图与相关性风险
法庭里坐着九位证人。 四位负责市场、情绪、新闻与基本面；两位分别坚持看多和看空；三位从激进、中性与保守的风险偏好发言。最后还有研究经理、交易员和组合经理逐层裁决。 ...
OpenClaw 的常驻网关：连续性不是把所有消息塞进同一会话
假设同一家公司有两个 Telegram bot：一个服务欧洲客户，一个服务美国客户。两个 bot 都把消息交给同一个 support agent，session 隔离策略写成了 per-channel-peer。 某个平台用户 ID 恰好同时出现在两个账号里。 ...
n8n 的确定性外骨骼：Queue、Worker 与副作用从不承诺 Exactly-Once
前一篇 n8n 入门 已经从 Manual Trigger → Edit Fields → IF 开始，讲过 Growth OS、受限 Agent、人工审批、operation ledger、结果回流和 alternatives。 ...
n8n 入门：给超级个体搭一条会被结果改写的增长流水线
先别连接邮箱、CRM 或社媒账号。打开一张空白的 n8n 画布，只放三个节点： Manual Trigger → Edit Fields → IF 在 Edit Fields 里写入一条假的内容信号，让 IF 根据证据数量把它送进 True 或 False 分支。先把 evidence_count 设为 3 执行一次，再改成 1 执行一次。两条路线都跑对以后，你已经碰到了工作流自动化最重要的五件事：触发、结构化数据、规则、分支和执行记录。 ...
如何建立对无人值守 AI Agent 的真实信任
假设你现在真的有一个 agent，能把一件事从头做到尾——拉数据、写代码、跑测试、发 PR、改文档，一条龙。它不需要你在旁边一句一句喂提示词。你晚上把任务丢给它，去睡觉。 ...
超级个体的情报系统：从信源监测到可靠行动
最危险的简报，可能一条内容都没有 早上打开每日简报，页面上显示 0 条新内容。也许昨夜确实风平浪静；也可能是 RSS 路由坏了、API 开始返回空页，或者凭据在凌晨过期。从读者这一端看，这几种完全不同的状态只有同一个样子：安静。 ...
让 AI 自动帮你追全网资讯，最后会卡在哪里
如果你搭一个 AI，让它追某个领域的论文、发布、benchmark、观点和 changelog，它到底能替你走到哪一步？从 2026 年 1 月到 6 月，我持续试用了自己能接触到的一批资讯聚合、页面监控和自动简报工具。这个样本不覆盖市场上的全部产品，也不是严格的横向测评；它只是我在同一套技术资讯任务上的长期观察。结论是：AI 很擅长搬运和整理；但缺少用户目标、工作上下文与结果反馈时，它不能可靠替代最终判断。 ...
LLM 推荐系统工程指南：语义召回、排序、强化学习与评估
推荐系统最容易制造一种错觉：模型越新，系统就越先进。 真正做过推荐的人会知道，模型只是水面上的一小部分。水面之下还有曝光偏差、延迟预算、特征新鲜度、库存约束、探索风险和反事实评估。大语言模型（LLM）确实给推荐系统增加了新的语义入口，却没有替我们消除这些旧问题。它甚至会带来新的麻烦：成本更高、输出不稳定、解释可能看似合理却与排序依据无关。 ...
AI Gateway 选型指南：LiteLLM、Kong、APISIX、Cloudflare 与 Portkey 怎么选
AI Gateway 不是“给大模型套一层反向代理”这么简单。真正进入生产以后，模型调用同时带着长连接、流式响应、令牌计费、供应商限额、敏感数据和不可预测的输出。普通 API 网关能处理其中一部分，却很难独自回答三个问题： ...
2024 AI 现场笔记：从大模型涌现到生产级 RAG，2026 再校准
这篇文章最初写于 2024 年 1 月的一场大语言模型分享会。那时，行业的问题还是“模型能做什么”；两年后，更重要的问题变成了“系统凭什么值得相信”。 我没有把旧笔记涂成一篇仿佛从未犯错的新文章。时间留下的误判也有价值：它提醒我们，技术判断不是预言，而是带着证据期限的下注。以下每节都保留 2024 年的观察，并用 仍成立 / 已变化 / 当时误判 做 2026 年校准。 ...
管理后台和监控的部署与设计
OpenIM 提供了多种灵活的部署选项，适用于不同的环境和需求。以下是这些部署方案的简化和优化描述： 源码部署: 普通源码部署：使用 nohup 方式进行部署。这是一种基础的部署方法，适合于开发和测试环境。详情参见：普通源码部署指南 。 生产级部署：采用 system 方式，更适合于生产环境。这种方法提供了更高的稳定性和可靠性。详情参见：生产级部署指南 。 集群部署: Kubernetes 部署：提供两种方式，包括通过 helm 和 sealos 进行部署。这适用于需要高可用性和可扩展性的环境。具体方法请参考：Kubernetes 部署指南 。 Docker 部署: 普通 Docker 方式：适用于快速部署和小型项目。详细信息请见：Docker 部署指南 。 Docker Compose 方式：提供了更便捷的服务管理和配置，适合于复杂的多容器应用。 接下来，我们将逐一介绍这些部署方法的具体步骤、监控和管理后台的配置，以及使用技巧，帮助您根据自己的需求选择最合适的部署方案。 ...