- 综合排序
- 最热优先
- 最新优先
- 来自专栏XINDOO的专栏
Agent设计模式——第 4 章：反思
虽然单个 Agent 可执行自我反思，但使用两个专门 Agent（或两个具有不同系统提示的独立 LLM 调用）通常能产生更稳健和客观的结果。 其设计目标是发现缺陷、提出改进建议并提供结构化反馈 这种关注点分离非常有效，因为它避免了 Agent 审查自身工作时可能产生的"认知偏差"。 generator Agent 设计用于创建关于给定主题的初始草稿段落，被指示撰写简短信息丰富的文章，并将其输出保存至状态键 drafttext。 这种生成、评估和优化的迭代过程逐步提升最终结果质量，从而产生更准确、连贯和可靠的结果 经验法则： 当最终输出的质量、准确性和细节比速度和成本更重要时使用反思模式。 当任务需要通用生产者 Agent 可能遗漏的高客观性或专门评估时，使用独立评审者 Agent 视觉摘要 ** ** 图 1：反思设计模式，自我反思 ** ** 图 2：反思设计模式，生产者和评审者
65510编辑于 2025-10-27 我从 AIP 平台架构设计 Agent 产品经验
我从AIP平台架构设计Agent产品经验软件架构师罗小东，多年架构和平台产品设计经验，目前在Agent场景落地结合中。 这里的经验更多偏向于架构设计与工程实践，每个架构师有自己的思路，我有我思。前期的时候，也是考虑了很久，觉得企业级AI智能体平台在架构设计上相对来说是会有些不一样的。 模型中立架构的设计与权衡前期的时候，AI平台都是绑定单一模型的，比如只用GPT-4或者只用Claude。 这里要说说我们在可视化编排方面的一些经验。拖拽式界面的设计逻辑前期的时候，工作流配置都是代码式的，需要写JSON或者YAML配置文件。但是随着用户群体的扩大，我们发现这种方式门槛太高了。 每个产品设计思路不一，这个是建设企业级AI智能体平台的一些经验，期望给有兴趣的朋友参考，也欢迎交流。
14010编辑于 2026-05-05- 来自专栏后端系统和架构
高可用架构和系统设计经验
TOC高可用架构和系统设计经验图片本文从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六大层面去剖析一个高可用的系统需要有哪些关键的设计和考虑一、高可用架构和系统设计思想可用性和高可用概念可用性是一个可以量化的指标 行业内一般用几个9表示可用性指标，对应用的可用性程度一般衡量标准有三个9到五个9；一般我们的系统至少要到 4 个 9（99.99%）的可用性才能谈得上高可用。 容量规划阶段，更多是要依靠自身和团队的经验，比如要了解我们的 log 的性能、redis 的性能、rpc 接口的性能、服务化框架的性能等等，然后根据各种组件的性能来综合评估自己设计的系统的整体性能情况。 4 个 9(99.99%)的可用性。 推荐阅读推荐阅读我的其他文章：《高并发架构和系统设计经验》《TCP 长连接层的设计和 在 IM 项目中实战应用》《万字解读云原生时代，如何从 0 到 1 构建 K8s 容器平台的 LB（Nginx）负载均衡体系
2K163编辑于 2022-12-19 Agent设计模式（6）：Multi-Agent模式——构建多Agent协作系统
这是"Agent设计模式"系列文章的最后一篇。 可扩展：新增功能只需添加新Agent 二、Agent角色设计：职责分离 Multi-Agent系统的第一步是角色定义。 每个Agent必须明确： 它负责什么 它的输入是什么 它的输出是什么 它和其他Agent如何交互 ▪ 代码审查系统的角色设计 # agent_roles.py from dataclasses import Agent系统复杂，必须有良好的日志和监控 容错设计LLM调用可能失败，要有重试和降级机制 持续评估用真实数据测试，不断优化Prompt和逻辑 ▪ 6.3 推荐资源 论文： "ReAct: Synergizing 在单Agent能解决问题时，不要为了"炫技"而使用Multi-Agent。系统的价值在于解决问题，而不是技术有多复杂。 这个系列到这里就结束了。 希望这几篇文章能给你一个清晰的Agent设计地图。
31411编辑于 2026-05-09Agent设计模式（4）：Tool Use模式——构建安全的多工具Agent
在系统prompt里加一行"新增工具：xxx" 不需要写复杂的工具描述，不需要担心token爆炸。 这就是Tool Use模式的核心思想：Agent写代码，代码执行操作。 添加允许使用的工具 safe_globals.update(global_vars) # 4. 写Python代码调用工具 4. 从输出中提取关键信息 5. 我见过太多项目因为没做沙箱，导致Agent删库、泄露数据。安全不是事后补救，是事前设计。 第二，标准化。 工具接口不统一，Agent就会乱。50个工具有50种接口风格，LLM根本记不住。 设计的时候就要考虑动态发现、自动注册，不要每次加工具都改prompt。 工具调用是Agent最实用的能力，也是最容易出问题的地方。 用好了，Agent能干很多事；用不好，Agent就是个定时炸弹。
23210编辑于 2026-05-09- 来自专栏服务端技术杂谈
用文件系统思路设计Agent记忆系统
用户与Agent的多轮对话过程中会出现很多记忆，包括用户原始的意图、诉求、关键词，还包括Agent的推理、规划、工具调用的执行结果及模型最终的响应。 智能体毕竟是一个软件系统，所以越来越多人用软件设计的思想实现[记忆模块]。 我们将智能体类比于一台计算机，文件系统就是计算机的记忆模块。 如果哪天底层切换存储组件，Agent层完全不需要感知，切换很灵活。 因为在接口层面做了抽象，所以可以很好的面向功能进行接口涉及，而无需关注这个功能接口究竟是用了一个文件系统还是多个类型的文件系统。 回过头来，我们看一下从用户提出问题，到最终Agent给出回答的整个流程如下。 最终实现类似于操作系统的文件系统能力，让智能体的记忆可追溯（每一步有据可查）、可审计（所有操作都有日志）、可演化（新组件无缝接入），整个Agent的记忆历史都是可以回溯的，而不是黑盒了。
26510编辑于 2026-03-11 - 来自专栏菩提树下的杨过
Agent设计模式学习(基于langchain4j实现)(1) - 基础Agent用法
本文将在langchain4j官方示例基础上(不熟悉langchain4j的朋友，请移步langchain4j学习系列），介绍几个主要模式的用法，今天先来看最基本的Agent如何实现 为方便讨论，先交待一下这一系列的业务背景 - 拥有 4 年软件开发经验，其中最近 2 年专注于 Java 后端开发（Spring Boot、PostgreSQL、Kafka 基础）。 、最基础的Agent示例 1 /** 2 该示例演示了如何实现一个基础Agent(改编自langchain4j官网示例) 3 注意：Agent只有与其他Agent结合使用时才更有用，后续步骤中将展示这一点。 4 如果只有一个Agent，使用 AiService 会是更好的选择。 5 这个基础Agent将用户的个人简介转换成一个简洁而完整的简历。
75910编辑于 2026-01-12 - 来自专栏凯云实验室
谷歌Colossus文件系统的设计经验
@ Google》，透露了Colossus设计的深层思考。 Colossus汲取了GFS的经验教训，正如在《Storage Architecture and Challenge》中所提及的GFS的不足。 基础知识: 谷歌的第一个集群级文件系统（2001） 为具有大文件的批处理应用程序设计 同时管理metadata和chunk的单一主程序 为了可靠性，chunk通常被复制3份 GFS教训: 扩展到大约50M Colossus简史 2001年，谷歌设计第一个集群文件系统——GFS。GFS支持P级的数据存储，以及数千客户机与数千服务器的交互。 谷歌需要将系统迁移到集群级的文件系统，该文件系统具有容错能力，设计用于大规模扩展，能够更有效地使用机器资源，并且对面向用户的服务提供最小的干扰。
2.5K30编辑于 2022-04-02 - 来自专栏腾讯Bugly的专栏
超低功耗操作系统的设计经验
介绍完OS整体架构之后，我们会进一步介绍OS中的几个关键设计（双核通信，UI框架等）以及典型功耗问题的解决思路和方法（实战经验）。 4.UI框架 UI框架也是本次设计的核心。我们并没有采用商用的方案，而是选取了libaroma这个开源框架（纯c写的UI框架库），并在此基础上自研了类似安卓的AMS和WMS子系统。 核心方法就是通过针对性的测试以及相关的摘件实验来缩小范围，然后通过软硬件的设计、代码与电路的走查等方式抓住根本原因。下面是一些典型问题的经验总结。 踏踏实实花7-8个月写大概30万行代码，可以收敛到稳定状态 4.做好双核通信的设计与实现，解决稳定性和通信效率问题 5.选择合适的UI框架，设计与封装AMS Task，应用开发可以独立展开，事半功倍 6 1.张巨广 腾讯车联网系统架构师，真时科技操作系统研发负责人 2.秦耕 真时科技操作系统研发负责人，腾讯操作系统研发高级工程师 3.马伟富 真时科技驱动软件高级工程师，TCL驱动软件高级工程师 4.张一凡
2.6K30发布于 2019-01-30 - 来自专栏程序员的成长之路
【经验】一个秒杀系统的设计思考
秒杀无外乎解决两个核心问题，一是并发读，一是并发写，对应到架构设计，就是高可用、一致性和高性能的要求。 关于秒杀系统的设计思考，本文即基于此 3 层依次推进，简述如下： 高性能。 如何保障应用在复杂工况环境下还能高效稳定运行，如何预防和面对突发问题，系统设计时应该从哪些方面着手？ 采集访问URL或 Agent 采集热点日志（一些中间件本身已具备热点发现能力），提前识别潜在的热点数据 聚合分析热点数据，达到一定规则的热点数据，通过订阅分发推送到链路系统，各系统根据自身需求决定如何处理热点数据 spm=a2c4e.10696291.0.0.34ba19a415ghm4 4.3 小结 高读和高写的两种处理方式大相径庭。 尤其在秒杀这一场景下，为了保证系统的高可用，必须设计一个 Plan B 方案来进行兜底。 高可用建设，其实是一个系统工程，贯穿在系统建设的整个生命周期。 ?
1.2K53发布于 2019-12-09 - 来自专栏后端技术
系统设计与分析 作业4
a hotel reserve hotel 50 5 you can reserve a hotel by selecting a hotel and room. manage basket 30 4 查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例 3.
52320发布于 2019-05-25 - 来自专栏蓝天
MOOON-agent发布：MOOON-agent系统设计与使用说明
MOOON-agent系统设计与使用说明.pdf MOOON-agent系统设计与使用说明 易剑 2012/6/16 1. 设计目标 一个通用的agent框架，提供编程接口，并内置通用的功能。 2. 应用场景 ? 3. ，常用需求不用编程直接使用 9) 非单例，单个进程可创建多个agent实例 4. 系统骨架 ? 5. 资源接口 暂略。 6. 内置CommandProcessor 暂略。 7. 编程接口 除宏外，所以内容均位于agent名字空间内。 实例 */ extern void destroy(IAgent* agent); 7.2. message.h #pragma pack(4) // 网络消息按4字节对齐 /*** * Agent
96210发布于 2018-08-07 - 来自专栏XINDOO的专栏
Agent设计模式——附录 G - 编码 Agent
直接模型访问机制： 为实现尖端效果，Agent 必须通过直接访问前沿模型（如 Gemini 2.5 PRO、Claude Opus 4、OpenAI、DeepSeek 等）驱动。 本框架致力于在人类领导与底层模型原始能力间建立最纯净对话通道，确保每个 Agent 均以峰值潜力运行。 该框架构建为专业化 Agent 团队，每个 Agent 针对开发生命周期中的核心功能专门设计。 流程编排者：人类开发者： 在此协作框架中，人类开发者承担编排者职能，作为 AI Agent 的中央智能节点与最终权威。 角色定位： 团队领导、系统架构师及最终决策者。 前沿模型访问权限配置 获取至少两个领先大语言模型（如 Gemini 2.5 Pro 与 Claude 4 Opus）的 API 访问密钥。 明确界定"目标愿景"与"设计 rationale"，借助 Agent 团队加速"实施方案"落地。作为设计决策的最终仲裁者，确保各组件严格遵循项目长期愿景与质量标准。
46510编辑于 2025-10-27 - 来自专栏菩提树下的杨过
Agent设计模式学习(基于langchain4j实现)(4) - 并行工作流
11 备注： 薪资略高于范围；可入职时间晚于预期；分布式系统经验有限。 简介 5 拥有4年以上经验的后端工程师（Java, Spring Boot, PostgreSQL），专注于可扩展系统、API现代化和自动化。 需要改进：个人项目和技术广度（如Kafka基础、React经验）可能不太深入，缺乏对系统设计或大规模处理的具体细节；教育背景中机械工程与软件工程无关，但训练营弥补了部分。 有指导经验。 84 不足之处：金融科技或支付系统直接经验未明确提及，这是一个关键需求。Kafka经验标注为“基础”和“概念验证”，可能不够深入。金融系统所需的可靠性和可观测性技能在简历中未突出。 需要改进：个人项目和技术广度（如Kafka基础、React经验）可能不太深入，缺乏对系统设计或大规模处理的具体细节；教育背景中机械工程与软件工程无关，但训练营弥补了部分。
29610编辑于 2026-01-18 - 来自专栏码
如何设计基于Agent的AI应用系统
那么，我们应该如何来设计一套系统，实现这样的诉求呢？ Agent功能分类 我们按照最小职责原则，将所有的功能进行划分，尽可能的把功能拆分开，每一个功能，都有一个Agent与之对应。 AI系统设计 现在，让我们想象，我们已经有了一台机器人，现在它需要完成一个炒鸡蛋的任务，那么，从我们编程的角度，这里面都由哪些东西构成呢？数据和指令的流动是怎样的呢？ AI系统设计示意图（注意，这里的中枢层和Agent的中枢大脑是两个概念） 对于我们开发者，主要是在软件侧做一些事情，不同的硬件传感器它的数据结构是不同的，因此，我们需要有一个针对性的agent来处理这类传感器的信号 AI应用设计示意图 通过这一架构，我们可以让Agent被无限扩展，而无需调整已有代码。随着agents的数量越来越多，系统能支持的能力也越来越强。 就如上文展示的一样，将来，在AI系统的基础上，我们只需要使用非常简单的自然语言，就能设计出以目标为导向的任务，而无需关心它的具体实现，以及它的内部原理。
3.3K11编辑于 2024-03-26 - 来自专栏菩提树下的杨过
Agent设计模式学习(基于langchain4j实现)(10) - ReACT
这次我们不再讨论前文的招聘场景，而是学习一种更为广泛使用的Agent模式：ReACT (推理+行动)。先来看示意图： 这跟人类解决问题的思考方式很像：loop(思考-行动)。 定义ReAct Agent 1 public interface ReActAssistant { 2 @SystemMessage(""" 3 你是一个使用ReAct 13 """) 14 @UserMessage("问：{{request}}") 15 @Agent("基于用户提供的问题进行思考和回答") 16 String SampleTools sampleTools = context.getBean("sampleTools", SampleTools.class); 8 9 ReActAssistant agent and Agentic AI | LangChain4j
66010编辑于 2026-02-01 - 来自专栏菩提树下的杨过
Agent设计模式学习(基于langchain4j实现)(11) - PlanAndExecute
上篇学习了ReACT，今天继续学习PlanAndExecute模式 与ReACT模式的关键区别如下： 对比维度 ReAct Agent Plan-and-Execute Agent 思考模式 单步思考- 9. queryRefundProgress - 查询退款进度 30 """) 31 @UserMessage("问：{{request}}") 32 @Agent 16 """) 17 @UserMessage("{{step}}") 18 @Agent("基于用户提供的问题生成计划") 19 String executeStep 25乘以4的结果是100.00。 请提供下一步指令。 and Agentic AI | LangChain4j
37110编辑于 2026-02-02 - 来自专栏XINDOO的专栏
Agent设计模式——结论
虽然每种模式都针对特定的设计挑战，但可以通过将它们归类到反映智能 Agent 核心能力的基础类别中来整体理解它们。 核心执行和任务分解： 在最基本的层面上，Agent 必须能够执行任务。 学习和适应模式更进一步，允许 Agent 的行为根据反馈和经验而演变，使其随时间变得更加有效。 协作和通信： 许多复杂问题最好通过协作来解决。 多 Agent 协作模式允许创建系统，其中多个专门的 Agent（每个都有不同的角色和能力集）共同努力实现共同目标。这种劳动分工使系统能够处理对单个 Agent 来说难以解决的多方面问题。 为复杂系统组合模式 Agentic 设计的真正力量不是来自孤立地应用单一模式，而是来自巧妙地组合多种模式以创建复杂的多层系统。 这些 Agentic 设计模式是您的调色板和笔触——使您能够超越简单的提示词并创建动态的、响应式的和目标导向的实体的基础元素。
48310编辑于 2025-10-27 - 来自专栏XINDOO的专栏
Agent设计模式——
情感： 理解何时应用 zero-shot、one-shot 和 few-shot 提示技术，并精心设计和组织示例，对于提升 Agentic 系统的效能至关重要。 在 Agentic 系统中，上下文工程是核心 Agent 行为（如记忆持久性、决策制定和跨子任务协调）的基础。 例如，一个经过上下文工程设计的 Agent 在响应查询前，会整合用户的日历可用性（工具输出）、与邮件收件人的专业关系（隐式数据）以及过往会议记录（检索文档）。 这些技术对于构建能够主动与世界互动、检索实时信息并执行需要与外部系统交互任务的 Agent 至关重要。 底层模型设计为在整个对话过程中始终遵循这些预定义指令。 这允许为专注应用创建高度专业化的 AI Agent。例如，可配置 Gem 作为仅引用特定编程库的代码解释器。
45110编辑于 2025-10-27 - 来自专栏技术汇总专栏
多 Agent 视角下的自动驾驶系统设计：车端 Agent 与 RSU Agent 协同机制解析
多Agent视角下的自动驾驶系统设计：车端Agent与RSUAgent协同机制解析一、引言：为什么自动驾驶需要协作式Agent在传统自动驾驶系统中，车辆往往被设计为高度自治的单体智能体：依赖车载传感器（ 二、协作式Agent系统总体架构1.系统角色划分Agent类型部署位置核心职责车端Agent自动驾驶车辆局部感知、轨迹规划、车辆控制路侧Agent路侧单元（RSU）全局感知、交通协同、策略协调云端Agent 通过合理划分车端Agent与路侧Agent的职责边界，并设计高效、鲁棒的交互机制，可以显著提升系统在复杂场景下的安全性与通行效率。 从工程视角看，这一体系本质上是一个分布式、多智能体协同决策系统，其设计思想对智慧交通、无人系统集群等领域同样具有重要参考价值。 该设计不仅符合自动驾驶工程落地对可靠性与可扩展性的要求，也为后续引入多Agent强化学习、博弈论协同决策等高级方法奠定了清晰、可演进的系统基础。
45810编辑于 2026-01-12
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号