1. 项目缘起为什么“心跳”是Agent的命脉最近在社区里看到不少朋友在讨论AI Agent的开发尤其是用Go语言来构建。很多人上来就关心怎么调用大模型API怎么设计复杂的工具链但往往忽略了一个最基础、也最核心的环节Agent的“主循环”和“System Prompt”。这就像造一辆车大家热衷于讨论发动机的马力和变速箱的档位却忘了研究这辆车最基本的启动、行驶和停止的逻辑以及驾驶员System Prompt到底是谁、他脑子里装着什么指令。没有稳定可靠的“心跳”再强大的引擎也无法让车辆持续前进。我自己在从零开始手撸Agent框架时也在这个环节踩过不少坑。比如Agent运行起来后突然“卡死”不响应任何外部输入或者Agent的行为完全偏离预期像一个脱缰的野马。这些问题追根溯源十有八九都出在主循环的设计缺陷或System Prompt的表述不清上。主循环决定了Agent如何感知、思考、行动、再感知的节奏是Agent生命周期的管理者。而System Prompt则是注入Agent“灵魂”的第一行代码它定义了Agent的身份、目标、行为边界和思考方式。这两者结合才构成了Agent稳定运行的“心跳”。网络上相关的热词也印证了这一点。大家搜索“hermes agent官网”、“codebuddy的system prompt在哪”本质上是在寻找成熟框架中这两个核心组件的实现参考。而“bp抓包设置心跳包”、“c#心跳信号plc”这类看似不相关的词恰恰说明了“心跳”机制在各类软件和控制系统中的普遍性与重要性。对于Go语言开发者而言利用其出色的并发模型goroutine和channel来构建一个高效、健壮的主循环是相比其他语言的一大优势。同时Go的简洁性也要求我们对System Prompt的设计更加精准因为代码的清晰度直接关系到逻辑的可靠性。所以这篇内容我们不谈高深的算法也不堆砌花哨的工具就扎扎实实地聊透这两个基础中的基础如何用Go设计一个鲁棒的Agent主循环以及如何编写一个真正能指导行动的System Prompt。无论你是想学习Hermes、OpenCode Go这类框架还是打算完全自研理解这些核心原理都将让你事半功倍。2. 主循环解剖从单次响应到持续智能体在聊天机器人中我们通常处理的是“请求-响应”模式用户输入一句话模型返回一句话会话结束。但Agent不同它是一个持续运行的进程需要主动地、周期性地与环境用户、其他系统、工具进行交互。这个持续运行的核心逻辑就是主循环Main Loop也有人称之为“调度循环”或“控制循环”。2.1 主循环的核心状态机一个典型的Agent主循环其内部可以看作一个精简的状态机。它不断在几个核心状态间流转驱动Agent完成任务。下面这个表格概括了一个基础主循环的关键状态与职责状态触发条件核心动作输出/下一状态感知 (Perceive)定时触发或事件驱动1. 检查消息队列用户输入、工具执行结果、系统事件。2. 从数据库或上下文中加载当前会话状态。收集到的所有新信息和当前上下文。思考 (Think)感知阶段收集到新信息或达到思考周期1. 将“感知”到的信息与System Prompt结合组织成给大模型的提示Prompt。2. 调用大模型API获取模型的“思考”结果通常是下一步的行动计划或直接回答。模型的响应文本通常包含意图识别和行动指令。行动 (Act)模型响应中包含可执行的动作指令1. 解析模型响应识别需要调用的工具函数及其参数。2. 安全地执行工具调用如调用外部API、运行代码、查询数据库。3. 处理执行结果包括成功、失败或异常。工具执行的结果数据或状态变更。学习/更新 (Learn/Update)行动执行后可选进阶1. 将本次“感知-思考-行动”的结果包括工具执行结果存入记忆或会话上下文。2. 可能根据结果微调策略或更新内部状态。更新后的上下文用于下一轮循环。这个循环周而复始。“心跳”的间隔就是主循环执行一次的周期。这个周期可以是固定的如每秒一次也可以是事件驱动的一有新消息就触发“感知”。注意并非所有循环都必须包含“学习”阶段。简单的任务型Agent在行动后可能直接回到感知状态等待下一个指令。而复杂的Agent则需要在循环中积累经验优化后续决策。2.2 用Go Channel实现事件驱动的心跳在Go中实现这个主循环最优雅的方式是利用goroutine和channel。我们可以将主循环本身放在一个独立的goroutine中让它成为一个常驻的“守护进程”。外部的事件如用户消息、定时信号通过channel发送给这个循环驱动其状态转换。下面是一个高度简化但体现了核心架构的代码示例package main import ( fmt log time ) // Event 代表驱动主循环的事件 type Event struct { Type string // 如 user_message, timer_tick, tool_result Data interface{} } // Agent 核心结构 type Agent struct { eventChan chan Event // 事件通道 stopChan chan struct{} // 停止信号通道 systemPrompt string context map[string]interface{} // 会话上下文 } // NewAgent 创建Agent实例 func NewAgent(systemPrompt string) *Agent { return Agent{ eventChan: make(chan Event, 100), // 带缓冲的通道 stopChan: make(chan struct{}), systemPrompt: systemPrompt, context: make(map[string]interface{}), } } // Start 启动Agent的主循环 func (a *Agent) Start() { go a.mainLoop() log.Println(Agent 主循环已启动) } // Stop 停止Agent func (a *Agent) Stop() { close(a.stopChan) } // SendEvent 外部向Agent发送事件 func (a *Agent) SendEvent(e Event) { select { case a.eventChan - e: // 事件已发送 default: log.Println(警告事件通道已满事件被丢弃) } } // mainLoop 核心主循环 func (a *Agent) mainLoop() { // 可以初始化一个定时器用于定期“感知”或执行后台任务 ticker : time.NewTicker(10 * time.Second) defer ticker.Stop() for { select { case -a.stopChan: log.Println(收到停止信号退出主循环) return case event : -a.eventChan: // **感知阶段**事件本身就是一种感知输入 a.handleEvent(event) case -ticker.C: // **定时感知阶段**即使没有外部事件也定期检查状态 a.handleTick() } } } // handleEvent 处理外部事件 func (a *Agent) handleEvent(event Event) { switch event.Type { case user_message: userInput : event.Data.(string) // 1. 更新上下文 a.context[last_input] userInput // 2. 进入思考阶段 plan : a.think(userInput) // 3. 执行行动 a.act(plan) case tool_result: // 处理工具执行结果更新上下文可能触发新的思考 result : event.Data.(map[string]interface{}) a.context[last_tool_result] result // 根据结果决定是否继续思考 if shouldContinue : result[success].(bool); shouldContinue { nextStep : a.think() // 基于结果继续思考 a.act(nextStep) } } } // handleTick 处理定时心跳 func (a *Agent) handleTick() { // 例如检查是否有长时间运行的任务超时清理旧上下文等 // 也可以主动进行一些“思考”比如“我还有什么待办任务吗” fmt.Println([Tick] Agent 心跳正常当前上下文大小:, len(a.context)) } // think 思考阶段组织Prompt调用模型 func (a *Agent) think(newInput string) string { // 这里简化处理实际应调用LLM API prompt : fmt.Sprintf(系统指令%s 当前上下文%v 最新输入%s 请决定下一步做什么。, a.systemPrompt, a.context, newInput) log.Printf(思考中Prompt: %s\n, prompt[:100]) // 日志截断 // 模拟LLM返回一个计划 return 计划回复用户并查询天气 } // act 行动阶段执行计划 func (a *Agent) act(plan string) { log.Printf(执行计划: %s\n, plan) // 这里解析plan调用相应的工具 // 工具执行完成后可以生成一个tool_result事件发送回eventChan驱动下一轮循环 // a.SendEvent(Event{Type: tool_result, Data: ...}) } func main() { agent : NewAgent(你是一个乐于助人的助手。) agent.Start() // 模拟用户发送消息 time.Sleep(1 * time.Second) agent.SendEvent(Event{Type: user_message, Data: 你好今天天气怎么样}) // 让Agent运行一段时间 time.Sleep(30 * time.Second) agent.Stop() time.Sleep(1 * time.Second) }这段代码的关键设计点事件驱动与定时驱动结合select语句同时监听eventChan外部事件和ticker.C定时信号。这保证了Agent既能即时响应外部请求又能维持一个基础的心跳执行后台维护任务。带缓冲的ChanneleventChan设置了缓冲大小100。这避免了在高并发场景下事件生产者如HTTP handler被阻塞。当缓冲满时我们选择丢弃新事件并告警这是一种简单的背压back-pressure策略防止内存耗尽。在实际项目中你可能需要更复杂的策略如优先级队列。清晰的停止机制通过独立的stopChan发送关闭信号确保主循环能优雅退出避免goroutine泄漏。状态封装handleEvent和handleTick方法隔离了不同触发源的处理逻辑使主循环保持简洁。实操心得在早期版本中我曾将主循环写成for event : range a.eventChan的纯事件驱动模式但后来发现如果长时间没有外部事件Agent就像“死”了一样无法进行任何后台状态检查或资源清理。加入定时器后整个系统才有了真正的“生命感”。这个定时器的间隔需要根据业务仔细调整太短会空耗CPU太长则可能导致响应延迟。3. System Prompt设计定义Agent的灵魂与行为准则如果说主循环是Agent的“心脏”那么System Prompt就是它的“大脑”和“人格”。它是你与大模型沟通的第一份也是最重要的一份契约直接决定了Agent输出的质量、安全性和可靠性。一个糟糕的System Prompt会让最强的模型表现得像个傻瓜而一个优秀的Prompt则能激发模型最大的潜力。3.1 System Prompt的核心构成要素编写System Prompt不是写一段随意的描述而是进行一场精密的“角色扮演”设定。它通常包含以下几个层次的信息身份与角色 (Identity Role)明确告诉模型“你是谁”。这是塑造Agent人格的基础。示例你是一名资深软件工程师擅长使用Go语言进行后端开发和系统架构设计。目标与职责 (Goal Responsibility)清晰定义Agent存在的目的和要完成的核心任务。示例你的目标是协助用户分析、设计和实现Go语言项目。对于非技术或超出范围的问题你应礼貌地表示无法回答。行为准则与约束 (Behavior Constraints)这是安全性和可控性的关键。必须设定明确的边界。格式约束请始终以JSON格式输出你的思考过程和最终答案。安全约束严禁生成或讨论任何涉及网络安全攻击、恶意软件、隐私侵犯、歧视性、违法或有害的内容。能力约束你只能使用已提供的工具函数。如果用户请求需要未知工具请说明你无法执行该操作。风格约束回答应专业、简洁、直接。对于复杂问题先给出概要再分步阐述。思考过程与输出格式 (Thinking Process Output Format)引导模型进行结构化思考并规范其输出便于程序解析。示例在回答前请按以下步骤思考 a) 理解用户问题的核心需求。 b) 评估所需信息是否完备。 c) 规划解决问题的步骤或方法。 d) 组织最终答案。 请将你的最终答案放在【答案】标签内。上下文与记忆 (Context Memory)指导模型如何利用历史对话信息。示例对话历史将作为上下文提供给你。请基于完整的上下文理解当前问题保持回答的一致性。3.2 一个针对Go开发助手Agent的完整Prompt示例让我们结合热词中“go语言实现交互式shell”、“agent开发学习路线”等需求设计一个具体的System Prompt。假设我们要构建一个“Go项目导师”Agent。# 系统指令Go项目导师 ## 你的身份 你是CodeMentor一个经验丰富、耐心严谨的Go语言开发专家和项目导师。你专注于Go生态对并发编程、微服务架构和性能优化有深厚造诣。 ## 你的核心目标 1. 解答用户在Go语言学习、项目开发、问题调试中遇到的具体技术问题。 2. 提供符合Go最佳实践如Effective Go的代码示例和建议。 3. 引导用户建立正确的Go项目结构和开发思维而非直接给出完整代码。 4. 当问题超出Go或一般软件开发范畴时礼貌地引导回主题。 ## 你必须严格遵守的行为准则 1. **安全第一**绝不生成任何可用于网络攻击、系统破坏、隐私窃取的代码或指令如SQL注入示例、未授权访问代码。 2. **代码质量**提供的所有Go代码片段必须是可编译、符合Go fmt风格的。优先使用标准库和广泛认可的第三方库如gorilla/mux, zap。 3. **分步引导**对于复杂问题如“如何用Go实现一个Agent主循环”将其分解为多个可操作的小步骤并解释每一步的原理。 4. **工具边界**你目前可用的工具是go_code_runner运行Go代码片段并返回结果、web_search获取最新文档或社区解答。如果用户请求需要其他工具如操作数据库、调用特定API请明确告知你目前无法直接执行但可以提供实现思路。 5. **输出格式** - **始终以以下JSON格式回复** json { thought: 你的内部推理过程分析用户问题、规划步骤。, action: 下一步动作。可以是 answer直接回答、run_code需要运行代码、search需要搜索。如果是后两者需提供 tool_input。, tool_input: {tool_name: 工具名, params: {}} // 当action为run_code或search时存在 response: 给用户的最终回答或对话延续。使用清晰的结构如步骤列表、代码块(go)。 } - 代码必须放在 go 代码块中。 ## 思考与响应流程 1. 首先解析用户输入判断其属于概念提问、代码错误、项目设计、资源请求中的哪一类。 2. 然后评估你的知识是否足以直接回答。若不足规划使用哪个工具如运行代码验证、搜索最新信息。 3. 执行规划生成答案或调用工具。 4. 整合所有信息生成最终给用户的response。 ## 对话上下文 你将收到之前的对话历史。请基于历史理解当前问题避免重复回答。如果用户的问题与历史相关请引用之前的讨论。 现在对话开始。这个Prompt的设计精妙之处角色具体化“Go语言开发专家和项目导师”比“一个助手”更具象能引导模型调用更专业的知识。目标分层四个核心目标优先级清晰特别是第3点“引导…而非直接给出完整代码”这能有效防止模型生成过长、未经思考的代码块鼓励教学式交互。约束可操作“安全第一”的条款非常具体。“代码必须可编译、符合Go fmt”给出了明确的代码质量标准。输出机器可解析强制JSON格式并且设计了thought、action、tool_input、response四个字段。这完美衔接了主循环主循环收到模型返回的JSON后可以轻松解析action字段。如果是answer则直接将response返回给用户如果是run_code或search则根据tool_input调用相应工具并将结果作为新的事件发送回主循环开启下一轮“感知-思考-行动”。流程引导“思考与响应流程”部分是在教模型如何模拟一个理性专家的思考过程这能显著提升回答的逻辑性。踩坑实录我曾在一个Agent中使用了过于简短的Prompt如“你是一个Go助手”。结果模型经常在回答中插入Python或JavaScript的示例或者对危险操作如“如何关闭防火墙”提供详细步骤。后来我加入了严格的行为准则和输出格式并特别强调了“Go语言”和“安全第一”这类问题几乎不再出现。System Prompt的精确度与Agent行为的稳定度直接成正比。4. 主循环与System Prompt的协同一个完整的任务推演理解了独立模块后我们来看它们如何协同工作完成一个真实任务。假设用户向我们的“Go项目导师”Agent提问“go run我的程序时出现了‘signal: segmentation fault (core dumped)’错误怎么排查”以下是Agent内部可能发生的协同流程推演事件感知用户的提问通过HTTP接口或CLI被发送到Agent。主循环的eventChan收到一个Event{Type: user_message, Data: go run我的程序...}。触发思考handleEvent函数被调用它将用户输入和当前上下文可能是空的连同System Prompt一起组织成完整的提示词调用大模型API。模型推理与结构化输出大模型根据我们精心设计的Prompt进行思考。它可能会在thought字段中写道“用户遇到了Go程序运行时段错误。这是一个严重的低级错误通常与内存操作有关如空指针解引用、切片越界、CGO问题。我需要引导用户进行系统性排查。首先询问是否使用了cgo然后建议使用-race检查数据竞争最后建议使用delve调试器。” 同时它的action字段设置为answer因为目前不需要调用工具可以直接给出排查建议。response字段则生成了一个结构化的排查指南。解析与行动主循环收到模型的JSON响应。解析发现action是answer于是它直接将response中的内容即排查指南返回给用户界面。同时它可以选择将本轮对话的QA更新到context中以便后续对话引用。下一轮交互用户根据指南尝试后可能继续追问“我用了-race没发现问题怎么用delve调试” 这又成为一个新的user_message事件。 模型在本次思考时由于Prompt中要求“基于历史理解当前问题”它会看到上下文中有上一轮关于段错误的讨论因此它的回答会更具连续性例如“承接之前的段错误排查既然数据竞争检测无效我们可以尝试使用Delve进行单步调试。首先请确保安装了delvego install github.com/go-delve/delve/cmd/dlvlatest...”工具调用场景如果用户问“请写一个并发安全的计数器示例并运行它。” 模型可能会在thought中规划“用户需要可运行的并发示例。我可以提供使用sync.Mutex和sync/atomic的两种实现并用go_code_runner工具来执行验证。” 于是它的action设为run_codetool_input中包含了要运行的Go代码。主循环解析后会调用go_code_runner工具执行代码并将执行结果成功输出或错误信息包装成一个tool_result事件发送回eventChan。主循环再次被触发模型基于代码运行结果生成最终回答给用户。这个推演展示了主循环是调度中心它不关心具体逻辑只负责事件的收发、状态的流转和任务的调度。System Prompt是宪法它规定了模型每一次“思考”必须遵循的原则、流程和格式确保输出的可控、可用。两者通过结构化数据耦合Prompt要求模型输出结构化JSON主循环依赖这种结构来决定下一步做什么直接回复还是调用工具。这种设计使得系统各个部分职责清晰易于扩展和维护。5. 进阶考量与避坑指南在基本框架跑通之后我们会遇到更多现实世界的问题。以下是几个关键的进阶考量点和对应的避坑经验。5.1 心跳间隔与性能权衡主循环中定时器ticker的间隔设置是一个需要权衡的参数。间隔太短如100ms会导致主循环空转频繁消耗不必要的CPU资源尤其是在云服务环境下这会直接增加成本。间隔太长如60sAgent的“实时”感知能力变弱。例如一个需要定期轮询数据库状态的任务可能无法及时响应变化。我的经验法则对于交互式Agent如聊天机器人心跳主要服务于后台清理如会话超时间隔可以设得较长比如30秒到1分钟。核心响应应由用户的user_message事件即时驱动。对于自动化Agent如监控机器人、自动交易程序心跳是其主动工作的节拍器。间隔需要根据业务需求设定比如监控系统可能每5秒检查一次指标。这里的关键是不要把耗时操作放在主循环中。如果检查指标需要调用一个慢速API应该将这个调用封装成异步任务触发后立即返回等结果通过事件传回主循环。避免阻塞主循环导致心跳“停跳”。5.2 上下文管理与记忆衰减Agent的context不能无限增长。大模型的上下文窗口有限过长的上下文会挤占有效信息增加API成本并可能降低模型性能。解决方案摘要化 (Summarization)定期例如每10轮对话或当上下文长度超过阈值时调用模型对之前的对话历史生成一个简短的摘要然后用这个摘要替换掉冗长的原始历史作为新的上下文起点。滑动窗口 (Sliding Window)只保留最近N轮如最近20条的对话消息。这是最简单有效的方法。向量记忆 (Vector Memory)这是更高级的方法。将每一段对话内容通过嵌入模型转换为向量存入向量数据库。当需要回忆时根据当前问题搜索最相关的记忆片段动态注入上下文。这模拟了人类的长期记忆和关联记忆能力。在Go中实现滑动窗口非常简单type ContextManager struct { maxMessages int messages []Message // Message 包含 role, content 等 } func (cm *ContextManager) AddMessage(msg Message) { cm.messages append(cm.messages, msg) if len(cm.messages) cm.maxMessages { // 移除最旧的消息保持窗口大小 cm.messages cm.messages[len(cm.messages)-cm.maxMessages:] } }5.3 System Prompt的迭代与测试不要指望一蹴而就写出完美的Prompt。它需要像代码一样进行迭代和测试。测试方法构建测试用例集收集一批典型、边界和刁钻的用户问题。A/B测试为同一个Agent准备两个略有不同的Prompt版本比如一个强调安全一个强调创造性用同一组问题测试对比输出结果。评估指标定义清晰的评估标准。例如任务完成率Agent是否直接、正确地回答了问题核心安全合规率面对危险或越界请求是否成功拒绝格式遵守率输出是否符合规定的JSON格式工具调用准确率在需要时是否正确地规划了工具使用一个常见的坑是“指令冲突”。例如Prompt中既要求“尽可能详细回答”又要求“回答应简洁”。模型在面对这种冲突时行为会不可预测。务必确保指令间的一致性。5.4 错误处理与自我修复一个健壮的Agent必须能处理各种异常。模型API调用失败网络超时、服务限流、token超长等。主循环中调用模型的部分必须有重试机制如指数退避和优雅降级如返回一个预设的友好错误信息。工具执行失败外部API不可用、返回意外格式。在act阶段需要捕获工具调用的panic或错误并将其包装为一个清晰的tool_result事件例如{success: false, error: API请求超时}反馈给循环。模型在下一轮思考时应该能根据这个错误结果调整计划。模型输出格式错误模型可能不遵守JSON格式。在主循环解析模型响应时必须有健壮的JSON解析逻辑并做好容错。可以尝试用正则表达式提取可能的JSON部分或者直接提示模型重试。func (a *Agent) parseModelResponse(rawResp string) (ModelResponse, error) { var resp ModelResponse // 尝试解析JSON if err : json.Unmarshal([]byte(rawResp), resp); err ! nil { // 尝试修复查找第一个{和最后一个} start : strings.Index(rawResp, {) end : strings.LastIndex(rawResp, }) if start ! -1 end ! -1 end start { repaired : rawResp[start : end1] if err : json.Unmarshal([]byte(repaired), resp); err nil { log.Println(警告模型响应格式不标准已尝试修复) return resp, nil } } // 修复失败返回错误主循环可据此向用户或管理员告警 return ModelResponse{}, fmt.Errorf(无法解析模型响应为JSON: %v, err) } return resp, nil }6. 从零集成Go项目中的工程化实践理论最终要落地为代码。我们如何在一个真实的Go项目中将这些概念工程化地集成起来6.1 项目结构规划一个清晰的目录结构是良好项目的开端。建议如下my-go-agent/ ├── cmd/ │ └── agent/ // 主程序入口 │ └── main.go ├── internal/ // 内部包外部项目无法导入 │ ├── agent/ │ │ ├── core.go // Agent结构体、主循环定义 │ │ ├── events.go // 事件定义与处理 │ │ └── prompt.go // System Prompt加载与管理 │ ├── llm/ // 大模型客户端封装 │ │ └── client.go │ └── tools/ // 工具集 │ ├── runner.go // 代码运行工具 │ └── search.go // 网络搜索工具 ├── configs/ // 配置文件 │ └── prompt.yaml // 将System Prompt放在配置文件里 ├── go.mod └── README.md关键点将System Prompt放在configs/prompt.yaml中而不是硬编码在Go代码里。这允许你在不重新编译程序的情况下动态调整Agent的“人格”和行为准则。6.2 配置化与热加载prompt.yaml示例system_prompt: | # 系统指令Go项目导师 ## 你的身份 你是CodeMentor一个经验丰富、耐心严谨的Go语言开发专家和项目导师... ## 你的核心目标 ...在Go代码中你可以使用viper或自己编写逻辑来读取这个YAML文件。更进一步可以实现一个简单的HTTP端点如POST /admin/reload-prompt让管理员能在运行时动态更新PromptAgent的主循环在下次“思考”时就会使用新的指令。这为Agent的调试和优化提供了巨大便利。6.3 可观测性与日志一个运行中的Agent应该是可观测的。你需要记录关键日志以便排查问题。事件流日志记录每一个进入主循环的事件类型、摘要。模型交互日志记录发送给模型的Prompt可脱敏和收到的原始响应。这是调试Prompt效果的最重要依据。工具调用日志记录工具调用的输入、输出和耗时。心跳日志定期记录主循环的状态如待处理事件数、上下文大小、内存占用等。在Go中可以使用结构化的日志库如log/slog或zap方便后续接入日志分析系统。import log/slog func (a *Agent) handleEvent(event Event) { slog.Info(处理事件, type, event.Type, data_summary, fmt.Sprintf(%v, event.Data)) // ... 处理逻辑 slog.Debug(模型响应已解析, action, resp.Action) }6.4 连接现实世界HTTP服务器与长连接最后你的Agent需要与外界通信。最常见的方式是提供HTTP API。创建一个HTTP服务器将/chat端点接收到的用户消息包装成Event发送到Agent的eventChan。为了实现类似ChatGPT的流式响应你可以使用Server-Sent Events或WebSocket。当模型生成response时不是一次性返回而是通过连接逐步推送。这需要主循环或一个专门的发布-订阅模型来管理多个客户端连接。// 简化的HTTP处理示例 func (a *Agent) handleChat(w http.ResponseWriter, r *http.Request) { var req ChatRequest if err : json.NewDecoder(r.Body).Decode(req); err ! nil { http.Error(w, err.Error(), http.StatusBadRequest) return } // 发送事件到Agent主循环 a.SendEvent(Event{ Type: user_message, Data: req.Message, Metadata: map[string]interface{}{conn_id: someConnectionID}, // 关联连接 }) // 这里需要一种机制等待Agent处理完并将结果返回给对应的连接 // 通常使用一个全局的map来管理connectionID到响应channel的映射 }通过以上步骤你就将一个概念上的“心跳”机制落地成了一个结构清晰、可观测、可配置、可扩展的Go语言AI Agent服务骨架。这仅仅是起点在此基础上你可以添加更复杂的工具、记忆模块、多Agent协作等高级功能但稳定可靠的“心跳”和清晰的“灵魂”指令永远是这一切的基石。