xiaohack's Blog - 工程化落地
type: channel
link: https://blog.xiaohack.org/tag/207a6bc0-f42220/
items: AI 智能体从 0 到 1 的工程化落地与系统构建实践
items: 智能体来了从0到1：为什么几乎所有能落地的 AI Agent，本质都是工作流系统？
items: 国内首个可复现！萝博派对公开人形机器人 “从 0 到跑” 全开源方案 ｜
items: Manus 高溢价收购背后，是 Agent 开发落地困境

AI 智能体从 0 到 1 的工程化落地与系统构建实践
type: item
date: 2026-01-29T16:54:18+08:00
description: 随着大模型能力不断增强，越来越多团队开始尝试构建 AI 智能体（AI Agent）。但在实际应用中，很多智能体项目停留在演示阶段，难以长期运行，也无法真正进入业务流程。问题往往不在模型本身，而在系统设计方式。智能体不是一次性调用模型的工具，而是需要长期运行、持续决策和不断反馈的系统。只有完成工程化构建，智能体才能从概念走向稳定可用。工程化智能体的核心特征，是能够在没有人工持续干预的情况下，稳定运行完整流程。在实践中，一个可落地的智能体系统至少需要具备以下能力：目标明确、任务可拆解、执行可控、状态可维护、结果可反馈。这些能力共同构成智能体的决策闭环。从工程视角看，智能体本质上是一种长期运行的系统组件，而不是临时生成内容的工具。在智能体从 0 到 1 的阶段，最容易导致失败的原因是边界不清。很多项目一开始就尝试解决过多问题，导致系统复杂、难以稳定。更稳妥的方式，是只让智能体处理一类任务、运行一个流程、调用有限工具，并尽量保证输入和输出结构清晰。边界越清楚，系统越容易测试、调试和扩展。在工程实践中，一个可落地的智能体系统通常由多个相互独立但又协同运行的模块构成。这些模块负责目标解析、任务规划、执行控制、工具调用和状态维护。它们共同形成一个循环，使智能体能够持续运行而不是一次性完成任务。需要注意的是，系统逻辑应由程序控制，而不是全部写入提示词。提示词只负责配置，不应承担系统职责。任务规划是智能体与普通模型调用之间的本质区别。一个没有规划能力的系统，无法持续执行复杂流程，只能完成一次性任务。在工程实践中，规划能力应从简单开始，逐步增强。早期使用线性规划即可满足大多数场景，随着需求复杂度提升，再逐步引入多路径或反思机制。过早复杂化，反而会降低稳定性。智能体要进入真实业务流程，必须具备可靠的工具系统。工具是智能体与外部世界交互的接口，包括数据查询、接口调用、文件操作和结果输出等能力。工程上，工具设计应遵循职责单一、输入输出清晰、可独立测试的原则。工具越稳定，智能体系统的整体可靠性就越高。没有记忆的智能体，只能完成一次性任务，无法真正运行流程。工程化智能体需要至少具备短期和中期记忆，用于保存当前任务状态和阶段结果。长期记忆可以在系统稳定后再逐步引入，用于存储知识和经验。在早期阶段，过早引入复杂记忆机制，往往会增加系统不确定性。反馈机制决定智能体是否具备自我修正能力。一个没有反思能力的系统，一旦执行失败，就会不断重复错误。工程实践中，应为智能体设置明确的结果评估机制。当结果不符合预期时，系统应能够重新规划并限制循环次数。这是智能体从“能跑”到“能用”的关键一步。从实践经验看，智能体从 0 到 1 的实现应遵循循序渐进的原则。先构建单目标、单工具、无记忆的简单系统，再逐步增加记忆、反馈和多工具能力，最后处理并发、异常和持久化问题。遵循顺序，可以显著降低返工成本。在智能体工程化落地过程中，常见问题包括：目标定义过大、提示词承担系统职责、工具不可控、缺少回退机制、没有日志监控、系统模块耦合严重。这些问题通常不是模型问题，而是工程设计问题。智能体是一种系统工程，而不是提示词工程。智能体真正的价值，不在于模型是否足够聪明，而在于系统是否足够稳定。当结构合理、边界清晰、流程可控，模型能力的提升将自然转化为系统能力。工程化，是智能体真正进入行业、进入流程、进入长期运行阶段的起点。

智能体来了从0到1：为什么几乎所有能落地的 AI Agent，本质都是工作流系统？
type: item
date: 2026-01-23T15:40:40+08:00
description: 如果说大模型决定了智能体“能想多聪明”，那么工作流，决定了它“能走多远、能不能落地”**。在过去一年中，AI Agent 成为开发者与企业管理层共同关注的核心概念。但大量实践已经证明：阻碍智能体进入真实业务的关键因素，并不是模型能力，而是系统是否具备“工作流意识”。本文将从工程视角回答一个关键问题：为什么几乎所有真正跑进业务系统的 AI Agent，本质上都是工作流系统？一、什么是智能体工作流（Agentic Workflow）？​智能体工作流​，可以被定义为：通过流程编排、状态管理与工具调用，将大模型的概率推理能力，约束在一个确定性的业务执行框架中。在工程上，它的作用不是增强模型“思考能力”，而是​控制模型的行为边界​。一个常见的类比是：大模型：引擎智能体工作流：变速箱 + 底盘 + 制动系统没有工作流的 Agent，本质只是一个具备自然语言能力的交互 Demo，而不是业务系统的一部分。二、为什么“纯 Prompt 智能体”无法进入真实业务？许多团队在 Agent 的 0→1 阶段都会遇到同一个困惑：“模型已经足够强，为什么还需要设计复杂流程？”原因在于一个根本性冲突：业务系统要求确定性，而大模型的输出天生具有概率性。智能体工作流的价值，并不在于“让模型更聪明”，而在于解决以下三个工程级问题。1️⃣ 将模型幻觉限制在可控边界内在工作流系统中，复杂任务会被拆解为​最小原子能力​：分类信息抽取条件判断模型不再被允许“自由发挥”，而是只在明确约束下完成局部认知任务。模型负责推理，系统负责兜底。2️⃣ 事实来源于系统，而非模型生成在可落地的 Agent 系统中：库存数据 → 数据库 / SQL金额信息 → 财务系统订单状态 → 业务服务模型只负责​逻辑决策​，而不负责​事实生成​。**这是智能体工作流最核心的一条原则：逻辑交给模型，事实交给系统。**3️⃣ 从“调 Prompt 玄学”到“可调试系统工程”在工作流中，每一步都是可观测、可回放、可重试的：是意图识别失败？还是外部 API 异常？还是条件分支判断错误？这类工程级调试能力，是纯 Prompt Agent 永远无法具备的。三、智能体工作流的三个成熟阶段（工程共识）在大量真实项目中，成功落地的 Agent 几乎都经历了以下三个阶段。第一阶段：顺序链（Sequential Chain）Input → Step A → Step B → Output适用于：摘要翻译单次生成任务这一阶段的 Agent 更接近“流程化生成”，适合作为 Demo，而非业务系统。第二阶段：条件路由（Conditional Routing）系统先进行判断，再根据条件进入不同流程分支。典型应用包括：客服意图分流售后 / 退款 / 技术支持内容审核策略分支这一阶段，Agent 开始具备基础的“系统意识”。第三阶段：闭环 Agent（Loop & Multi-Agent）Plan → Act → Observe → Reflect核心特征：任务失败可回退行为可自我修正支持长流程与多角色协作到这一阶段，智能体才真正开始“像一名员工”，而不是脚本。四、真正的工程难点：不是设计流程，而是“编排成本”在真实系统中，Agent 落地面临的最大挑战并不是逻辑设计，而是工程复杂度：图结构难以维护状态在多节点间难以传递重试、超时、中断处理极其复杂这也是大量 Agent 项目停留在 Demo 阶段的根本原因。五、为什么 Agent 基础设施正在平台化？行业正在形成一个清晰共识：Agent 的基础设施必须被平台化、低代码化。越来越多团队选择使用类似 「智能体来了」 这样的智能体平台：底层负责：流程调度、上下文管理、失败重试上层专注：业务流程与策略设计其核心价值在于：让业务专家，而不是工程师，定义智能体的行为逻辑。六、结论：未来 Agent 的核心竞争力是什么？不是模型参数规模，而是三点工程能力：是否具备清晰的流程拆解能力是否能将不确定性约束进工作流是否支持持续复用与演进Agent 的上限，不在模型，而在工作流。「智能体来了」正在做的，正是把复杂的 Agent 工程，转化为​人人可设计的流程系统​。

国内首个可复现！萝博派对公开人形机器人 “从 0 到跑” 全开源方案 ｜
type: item
date: 2026-01-15T21:40:53+08:00
description: 国内首个可复现！萝博派对公开人形机器人 “从 0 到跑” 全开源方案0%展开列表国内首个可复现！萝博派对公开人形机器人 “从 0 到跑” 全开源方案今天联发科天玑9500s、8500发布：GPU、光追拉满，红米Turbo 5Max将搭载今天通用级PixVerse P1的技术突破，揣着进入平行世界的密码今天Mira公司内乱？CTO被开除，带团队回OpenAI，翁荔上推发言今天Nature丨清华等团队揭示AI科研双重效应：个人效率亦或是科学边界今天刚刚，喝到了千问APP给我点的奶茶今天人脸机器人登上Science Robotics封面：用AI教会仿生人脸机器人「开口说话」今天实测夸克「千问划词快捷指令」，这7个邪修Prompt，建议收藏今天已证实！清华姚班陈立杰全职加入OpenAI，保留伯克利教职今天解锁任意步数文生图，港大&Adobe全新Self-E框架学会自我评估今天5分钟定制一个AI采购专家：讯飞发布“招采智能体工厂”，重新定义行业开发范式今天Agent时代，为什么多模态数据湖是必选项？今天大模型长脑子了？研究发现LLM中层会自发模拟人脑进化今天性能提升60%，英特尔Ultra3这次带来了巨大提升01月14日继宇树后，唯一获得三家大厂押注的自变量：具身模型不是把DeepSeek塞进机器人01月14日Sebastian Raschka 2026预测：Transformer统治依旧，但扩散模型正悄然崛起01月14日端到端智驾新SOTA | KnowVal：懂法律道德、有价值观的智能驾驶系统01月14日仅用10天？Anthropic最新智能体Cowork的代码竟然都是Claude写的01月14日AAAI 2026｜AP2O-Coder 让大模型拥有「错题本」，像人类一样按题型高效刷题01月14日用AI从常规病理切片重建空间蛋白图谱：基于H&E图像的高维蛋白质表达预测01月14日国内首个可复现！萝博派对公开人形机器人 “从 0 到跑” 全开源方案2026 年 1 月 15 日，萝博派对（Roboparty）在官方 GitHub 仓库正式完整开源双足人形机器人 “萝博头原型机（Roboto_Original）”，并同步启动全球开发者共创计划。这款搭载拟人步态的 AMP 运控算法、跑步速度达 3m/s 的原型机，凭借全栈透明的技术开放模式，成为目前全球范围内技术成熟度领先的全开源人形机器人。不同于“只开源代码或只开源结构图”的碎片式开放，本次开源以“可复现、可二开、可验证”为目标，覆盖参考硬件、控制/训练栈、工程化调试与验证方法，以及长期维护的行业 Know-how 共创知识库。萝博派对希望把“从 0 到跑”做成行业共享的具身 Infra 底座：把路径标准化、把经验工具化、把验证流程公开化，推动行业把时间用在真正的场景与能力突破上。全栈开源，直击人形机器人开发痛点人形机器人真正的门槛，往往不在某一个算法点，而在“从设计—装配—标定—训练—验证—迭代”的系统工程。基于此，萝博派对针对行业长期存在的三大核心痛点——闭源导致开发壁垒高、设计规范缺失、架构标准不统一——以“可复现、可二开、可验证”为目标，正式发布双足人形机器人“萝博头原型机”的全栈开源方案，并同步推出“动手学人形机器人问题清单”Know-how 共创文档，推动行业经验从“各自积累”走向“公开共享”。在硬件层面，萝博头原型机公开 1.2m 身高、30kg 重量级本体的全套结构图纸，覆盖关节排布、线束收束方案以及金属结构件选型标准等关键设计细节。同时，项目同步开放关节模组核心参数、选型指南与拆机报告，并提供国内优质供应商清单，配套完整 EBOM 物料清单与 SOP 组装流程，从采购、装配到复现路径形成闭环，显著降低硬件研发与复刻门槛。在软件与控制层面，项目开放底层控制全量代码，涵盖模仿运动、感知运动与导航运动三大核心模块，并支持 SMPL-X 人体模型适配，使开发者能够直接复用海量人体动捕数据，减少新任务开发中的微调成本，提升能力迁移效率，缓解传统控制方案在泛化性与工程落地上的不足。同时，萝博头原型机同步开源拟人步态的 AMP 运控算法代码，为步态自然度与运动稳定性的进一步迭代提供可直接复用的技术基础。在工程化落地层面，萝博派对将研发过程中形成的 sim2real gap 弥补方案、样机测试矩阵与调试经验总结系统化公开，并同步沉淀关键避坑要点与流程规范，帮助开发者与合作团队减少重复试错、提升调试效率，让“跑起来”不再依赖隐性经验，而是可以被复现、被验证、被持续迭代的工程流程。与此同时，萝博派对长期建设并持续维护“动手学人形机器人问题清单”共创知识库，覆盖行业发展、硬件研发、软件研发与生产制造等关键环节，旨在将行业讨论从“表演型炫技”拉回“实用落地”。该知识库主张人形机器人优先解决行…

Manus 高溢价收购背后，是 Agent 开发落地困境
type: item
date: 2026-01-09T22:48:00+08:00
description: 撰稿：李文朋编辑：王一鹏最近，“Meta 以 20 亿美元收购 Manus”的消息传得很热。Manus 曾被嘲讽“套壳”，但业内人士认为，虽然 Manus 整体架构和理念不算颠覆式“新”，但在任务连通性、容错、回退机制等实现上，极度考验工程能力，远不是“换个皮”那么简单。 在 Manus 创始团队与媒体的最近一次访谈中，联合创始人季逸超提出目前 Manus 定位只是一位“通用型助手”，帮普通人把复杂工作流做完，不能完全替代用户本身。这也是因为在 ToC 场景里，普通用户对体验要求很苛刻——慢一点不行，错一点也不行，Manus 团队很清楚这一点。 如果说 ToC 用户已经够“难伺候”，那 ToB 客户对 Agent 的要求只会更高：一方面，企业希望 Agent 真正“上生产”，意味着要接入复杂的权限体系、业务系统和合规要求；另一方面，任何一次错误操作、脏数据写入、流程走错，带来的代价都远比个人用户高得多。 所以会看到，过去一年很多企业在这条路上吃了不少苦：投入人力、投入预算，最后做出来的 Agent 用不了。MIT《2025 年商业 AI 现状》报告里提到，约 95%的生成式 AI 试点项目很难进入生产环境，很多最终都卡在上线前后。 问题出在哪？就在于这些一连串的工程难题。 比如代码标准不统一、系统接口五花八门、工具调用不稳定、开发周期被拉得很长；数据资产混乱、想用调不出；安全合规和权限管理一碰就痛；甚至出现“越用越退化”的优化难题。 说到底，并不是模型不行，也不是工程师不会做，而是整个 Agent 开发还不够成熟，大家还在摸索阶段，没有提前规划一套更清晰、更稳定的“做法”。 所以，国内的云厂商开始认真思考一个问题：到底怎样才能帮助企业把 Agent 的难题解决掉？有没有一种更适合落地的开发范式？ 2025 云栖大会上，阿里云 CTO 周靖人就曾提出过「AI 时代的 Agent 开发范式」。而在 1 月 7 日，阿里云百炼对“1+2+N”体系和开发范式做了一次更系统的升级，把它落成一个工程化的体系。 这套“1+2+N”体系的想法并不复杂，本质是把 Agent 落地拆成三层： 稳底座（1）：把模型和云资源这些基础能力做稳定、可扩展、可治理。地基不稳，再漂亮的 Agent 也只能停在 PoC。 定范式（2）：给企业一套把 Agent 做成“工业产品”的开发与运行体系，能开发、能部署、能迭代，交付不再反复折腾。 理杂活（N）：把真实业务里最难、最碎、但最致命的集成、权限、评测、成本这些“脏活累活”，做成可插拔的组件，让企业能按需拼装。 从这个角度看，这次阿里云百炼迭代背后体现的是一种更务实的方向：要用更工业化的方式，让企业的 Agent 在真实业务里跑起来。 一、“N”：通用大方案，不如啃硬骨头的“高手组件” 经过大量 Agent 的试错，企业如今在启动一个 Agent 项目时，最先拎出来掂量的往往不是模型，而是数据怎么处理与调用、安全问题能不能搞定、上线后怎么评估和优化。 这些硬问题不先解决，再漂亮的 Agent 构想也很难真正走进生产环境。而在阿里云百炼的“1+2+N”体系里，“N”恰恰就是优先来啃这些硬骨头的。 更关键的是，这一次“N”做了很大的升级：它把落地过程中那些最常见、最难啃、最容易反复踩坑的环节抽象出来，沉淀成一组可插拔、可组合的模块化组件。Agent 开发的难题看起来五花八门，但很多难题其实有共通的解法，可以被提炼、被复用。 “N”组件的存在，可以让企业缺什么就用什么、按需组合，把时间花在业务价值上，而不是重复造轮子。 这次升级里，一个直观的变化在应用广场：阿里云百炼把同类 Agent 做成了十多个精选合集，提供新的多模态模板，支持免登录体验，也能一键调用 API，把“试试到跑起来”的路径压得更短。 真正决定“能不能落地”的挑战，还有数据连接与知识管理、安全与权限控制、可观测与持续优化等问题。 企业做 AI 转型，数据治理永远是“卡脖子”环节。尽管大家都知道数据重要，但真落到工程上，标注、清洗以及让模型读懂私有数据的成本极其高昂。 目前，企业内部约 80%的数据以 PDF、图像、视频或会议录音等非结构化形式存在。据 IDC 预测，这些数据多处于“不可检索、不可复用”的沉睡状态。随着全球数据量预计在 2026 年激增至 221ZB，如何将这些碎片资产转化为 Agent 可调用的知识，成为企业发展的关键。 阿里云百炼的思路是把这条链路做成“工具化”：用多模态 RAG、多模态数据库、Connector 连接器，把数据处理变成更工业化的流水线。 多模态数据库通过智能解析、分类归档，打破图像/音频/视频等模态壁垒；多模态知识库 RAG 不再局限于纯文本，支持数十种格式的高精度解析，包括扫描件 PDF、复杂报表、音视频会议记录等…

Manus 高溢价收购背后，是 Agent 开发落地困境
type: item
date: 2026-01-09T22:35:17+08:00
description: 撰稿：李文朋编辑：王一鹏最近，“Meta 以 20 亿美元收购 Manus”的消息传得很热。Manus 曾被嘲讽“套壳”，但业内人士认为，虽然 Manus 整体架构和理念不算颠覆式“新”，但在任务连通性、容错、回退机制等实现上，极度考验工程能力，远不是“换个皮”那么简单。 在 Manus 创始团队与媒体的最近一次访谈中，联合创始人季逸超提出目前 Manus 定位只是一位“通用型助手”，帮普通人把复杂工作流做完，不能完全替代用户本身。这也是因为在 ToC 场景里，普通用户对体验要求很苛刻——慢一点不行，错一点也不行，Manus 团队很清楚这一点。 如果说 ToC 用户已经够“难伺候”，那 ToB 客户对 Agent 的要求只会更高：一方面，企业希望 Agent 真正“上生产”，意味着要接入复杂的权限体系、业务系统和合规要求；另一方面，任何一次错误操作、脏数据写入、流程走错，带来的代价都远比个人用户高得多。 所以会看到，过去一年很多企业在这条路上吃了不少苦：投入人力、投入预算，最后做出来的 Agent 用不了。MIT《2025 年商业 AI 现状》报告里提到，约 95%的生成式 AI 试点项目很难进入生产环境，很多最终都卡在上线前后。 问题出在哪？就在于这些一连串的工程难题。 比如代码标准不统一、系统接口五花八门、工具调用不稳定、开发周期被拉得很长；数据资产混乱、想用调不出；安全合规和权限管理一碰就痛；甚至出现“越用越退化”的优化难题。 说到底，并不是模型不行，也不是工程师不会做，而是整个 Agent 开发还不够成熟，大家还在摸索阶段，没有提前规划一套更清晰、更稳定的“做法”。 所以，国内的云厂商开始认真思考一个问题：到底怎样才能帮助企业把 Agent 的难题解决掉？有没有一种更适合落地的开发范式？ 2025 云栖大会上，阿里云 CTO 周靖人就曾提出过「AI 时代的 Agent 开发范式」。而在 1 月 7 日，阿里云百炼对“1+2+N”体系和开发范式做了一次更系统的升级，把它落成一个工程化的体系。 这套“1+2+N”体系的想法并不复杂，本质是把 Agent 落地拆成三层： 稳底座（1）：把模型和云资源这些基础能力做稳定、可扩展、可治理。地基不稳，再漂亮的 Agent 也只能停在 PoC。 定范式（2）：给企业一套把 Agent 做成“工业产品”的开发与运行体系，能开发、能部署、能迭代，交付不再反复折腾。 理杂活（N）：把真实业务里最难、最碎、但最致命的集成、权限、评测、成本这些“脏活累活”，做成可插拔的组件，让企业能按需拼装。 从这个角度看，这次阿里云百炼迭代背后体现的是一种更务实的方向：要用更工业化的方式，让企业的 Agent 在真实业务里跑起来。 一、“N”：通用大方案，不如啃硬骨头的“高手组件” 经过大量 Agent 的试错，企业如今在启动一个 Agent 项目时，最先拎出来掂量的往往不是模型，而是数据怎么处理与调用、安全问题能不能搞定、上线后怎么评估和优化。 这些硬问题不先解决，再漂亮的 Agent 构想也很难真正走进生产环境。而在阿里云百炼的“1+2+N”体系里，“N”恰恰就是优先来啃这些硬骨头的。 更关键的是，这一次“N”做了很大的升级：它把落地过程中那些最常见、最难啃、最容易反复踩坑的环节抽象出来，沉淀成一组可插拔、可组合的模块化组件。Agent 开发的难题看起来五花八门，但很多难题其实有共通的解法，可以被提炼、被复用。 “N”组件的存在，可以让企业缺什么就用什么、按需组合，把时间花在业务价值上，而不是重复造轮子。 这次升级里，一个直观的变化在应用广场：阿里云百炼把同类 Agent 做成了十多个精选合集，提供新的多模态模板，支持免登录体验，也能一键调用 API，把“试试到跑起来”的路径压得更短。 真正决定“能不能落地”的挑战，还有数据连接与知识管理、安全与权限控制、可观测与持续优化等问题。 企业做 AI 转型，数据治理永远是“卡脖子”环节。尽管大家都知道数据重要，但真落到工程上，标注、清洗以及让模型读懂私有数据的成本极其高昂。 目前，企业内部约 80%的数据以 PDF、图像、视频或会议录音等非结构化形式存在。据 IDC 预测，这些数据多处于“不可检索、不可复用”的沉睡状态。随着全球数据量预计在 2026 年激增至 221ZB，如何将这些碎片资产转化为 Agent 可调用的知识，成为企业发展的关键。 阿里云百炼的思路是把这条链路做成“工具化”：用多模态 RAG、多模态数据库、Connector 连接器，把数据处理变成更工业化的流水线。 多模态数据库通过智能解析、分类归档，打破图像/音频/视频等模态壁垒；多模态知识库 RAG 不再局限于纯文本，支持数十种格式的高精度解析，包括扫描件 PDF、复杂报表、音视频会议记录等…