Agent技术选型分析
Agent 框架选型不能只看谁最火。真正要先问的是:流程有没有分支和重试,任务会不会跑很久,状态要不要恢复,工具和人类审批是不是链路的一部分。
共 37 篇文章。
Agent 框架选型不能只看谁最火。真正要先问的是:流程有没有分支和重试,任务会不会跑很久,状态要不要恢复,工具和人类审批是不是链路的一部分。
我现在更确定的一点是:AI 写得快,不等于系统交付得快。工程师的价值不会只剩“亲手敲代码”,但也不会自动消失,它会更多落在问题定义、执行环境、反馈回路和结果验证上。
ChatCut 值得关注的地方,不是“AI 自动剪视频”这个口号,而是它把视频素材先变成可检索、可推理的语义索引。剪辑的核心动作也就从拖时间轴,变成了找素材、组织叙事和生成可编辑的片段序列。
在传统的金融技术(Fintech)领域,数据展示长期被密集的表格、复杂的K线图和枯燥的财务报表所主导。这种“机构级”的界面设计虽然信息密度极高,但对于普通个人投资者而言,存在着巨大的认知门槛。Simply Wall St(以下简称SWS)的出现代表了金融数据可视化的一种范式转移:它不旨在提供毫秒级的
AG-UI 对我最大的启发,不是又多了一个协议名,而是它把 Agent 和前端 UI 之间的边界讲清楚了:模型怎么想是一层,工具怎么调是一层,运行过程怎么让用户看见、确认和接管,又是另一层。
需要提炼出核心要素,使其适用于任何领域,无论是技术(如前端框架、数据库、机器学习)还是非技术(如语言学习、乐器、商业分析)场景。
单向数据流(Unidirectional Data Flow, UDF)是一种软件设计模式,其核心思想是数据在应用内的流动是沿着一个单一、可预测的方向进行的。该模式的精确定义是"将单向的变更(one-way mutations)应用于一个不可变的数据状态(immutable data state)"
一般是把2、3、4提出来做个链接,其目的是为了解决查询、管理问题,提高可维护性,可以理解为是一个微型数据库,算是个cache。
在追求极致工作流效率的道路上,macOS 的高级用户(Power User)从未停止探索。随着工具的不断演进,我们早已超越了简单的快捷键自定义,进入了一个多层次、可编程的自动化新纪元。在这个生态系统中,Karabiner-Elements 的 Complex Modifications、Raycas
OpenDeepWiki 是一个基于 .NET 的智能文档生成平台,采用模块化管道架构,主要组件包括:
在软件工程的早期发展阶段,开发过程主要遵循传统的软件开发生命周期(SDLC)模型,如瀑布模型。这些模型通常将设计视为编码之前的一个单一、宏大的阶段 。在这种线性思维下,软件开发被视为一个从需求到设计再到实现的顺序过程。然而,随着软件系统的规模和复杂性呈指数级增长,这种方法的局限性日益凸显。实践表明,
最近的资讯可视化项目,在将测试页面部署到服务器的过程中,我遇到了一些问题,现在记录下来作为经验总结。
Coze Studio 最值得看的不是“低代码 Agent 平台”这个标签,而是它怎么把模型、工作流、插件、知识库、数据库和发布管理放到一个工程系统里。它的问题也很典型:Agent 产品一旦从 demo 走向平台,就不只是 prompt 和工具调用,而是领域模型、资源管理、运行时、权限和运维一起上桌
F10的技术选型: https://fellou.ai/eko/docs/getting-started/eko/
最酷的是,这打破了技术壁垒。比如,Claude Code 是用 TypeScript 写的,但我们公司大部分项目用的是 Python。昨天我在 Slack 上看到一个同事,他不懂 TypeScript,但他想修复 Claude Code 的一个问题。于是他直接和 Claude 对话,一个小时内就生成
这篇不是在讨论“再做一个图表生成器”,而是在记录一件更实际的事:已有图表能力怎么变成 AI 可以稳定调用的工具。我的判断是,先把成熟 case、schema 和渲染出口整理好,比从零开始训练一个“会画图”的模型更靠谱。
项目需要用到 RAG,我们选择用 LlamaIndexTS,但是外网功能开发完,在内网准备发布的时候,发现 npm install 报错。
3、多挖掘数据之间的关联关系,用关系图/桑基图展示单个周期的数据之间的关系(关联、流向、强弱等等)
https://zhuanlan.zhihu.com/p/26426054
F10有大量的公司财务数据,而非专业人员在查看这些财务数据的时候,是很吃力的,包括概念难以理解、难以从数据中发现规律和逻辑、难以得出结论辅助自己决策等等。
形成一个自己的程序框架至关重要。程序框架其实就是你抽象自己的设计思路,抽取可复用部分,形成后续项目的基座。里面应该包含了程序目录结构、调试工具、编码规范的约束工具、日志工具、发布工具、常用函数库、常用业务库等等。这样就避免每次你都从头再来一遍,也避免了犯一些低级错误。
https://hanabi.data-viz.cn/index?lang=zh-CN
docker、可视化搭建、sequelize、TypeScript、老项目的熟悉等等。
我工作已经有九年半了,在此期间,也经历了国内互联网行业的各种变更。总体的感觉,大家在工作中的乐趣正一点点的丢失。造成这个问题的原因有很多,我按照自己的想法总结了下:
我们希望上班能带来精神和物质上的收获,希望周末能愉快的和家人一起出游。
我们需要在一开始,就把这三要素给讨论确定下来。这部分内容花费的时间多一点也是很值得的。
公司在金融市场发展到现在,接下去的路可能是如下三方面(都是营造差异化的竞争力): 1、中台战略:借助中台,快速试错、大量试错,不因为开发、效率等问题放过任何一个创新点,找到创新点进行突破 2、可视化战略:视觉、交互的升级,公司发展到一定阶段,这部分内容的重要程度会越来越高 3、技术战略:通过AI技术
修改相关服务器的 /usr/local/nginx/conf/ai.conf 配置
近日同事开发的一个项目出现了主从数据库切换异常的问题,由于大家都是新接触数据库的主从配置,许多基本的配置都是从他人的博客中摘抄而来,难免出现一些意外,这个问题就是在这样的环境下产生的。
如果需要的话,要进行数据评估,将当前需要的容量、今后可能增长的容量,都评估好发给运维
参考自这篇文章:https://www.cnblogs.com/cjsblog/p/9712457.html
单机启动zookeeper: nohup bin/zookeeper-server-start.sh config/zookeeper.properties > zookeeper-run.log 2>&1 &
有一个对外提供指标组信息的接口,返回内容为包含多个指标组信息的数组。接口要求返回的指标组,必须按照数据库中的权重字段(weight)的值排序。
有一个业务的数据库结构,包含很多一对多关系,大致类似下图的result属性的结构:
项目开发结束,马上就要部署上线了。而Java Web应用的部署方式有很多,为了合理的利用资源,我们想先对每种方式进行测试,然后选择最优的作为我们的方案。因此我让组里的实习生YWD同学做了一些测试工作。
昨天头儿反馈wiki系统不能用了,晚上我用请求日志里面比较慢的请求重试了下,请求起来都比较快;从zabbix监控和数据库的日志来看,问题时段也没有发现异常,暂时无法定位具体原因。
经过检查,排除了1和3,最终发现有两个问题: 1.指标评测会将请求结果先写入本地文件,然后再读取本地文件解析入库,这些本地文件最大的达到了37M 2.程序存在BUG,当计算没有完成时,会不停的重复解析本地文件,执行数据库读写操作 ## 解决方案 死循环问题好解决,修复程序就可以了 本地文件的