从堆栈跟踪,到发这份报告的人
你的编辑器早就握着代码。它从来没握着的是一个 bug 的另一半,谁踩到了、有多少人踩到、以及支持团队已经答应过他们什么。下面每个问题都会展开成一小串具名的工具调用,在智能体面板里滚过,而你继续读你的文件。
了解更多
你的提问
「有人发来了账单页面的一个 TypeError。找到那条消息,告诉我是谁报的。」
调用的工具
entergram_list_messagesentergram_get_contactentergram_list_chat_tickets
你会得到
智能体在近期历史里扫描这段报错文本,把发送者解析成一条联系人记录,再检查这个会话是否已经产生过工单。你会拿到报告者的姓名、他的原话,以及支持是否已经登记过的明确答案,而这时你连仓库里的一个文件都还没打开。
你的提问
「这个今天值得修吗?统计一下有多少人报过同一件事。」
调用的工具
entergram_list_workspace_chatsentergram_list_messagesentergram_get_chat
你会得到
用数量而不是直觉来定优先级。它扫的是共享的工作区视图而不是单个会话,按你描述的症状匹配,报告有多少个不同会话提到过它,以及第一次是什么时候出现的。一个月两例和两天九例,读起来完全是两回事。
你的提问
「把客户贴的那份日志拉出来,我要在本地复现。」
调用的工具
entergram_list_chatsentergram_list_messagesentergram_get_message
你会得到
智能体定位到会话,回溯到承载那段内容的消息,并取回完整正文而不是被截断的预览。接下来你可以让它把日志变成一个失败用例,直接写进你已经打开的那个文件里,这一步才是真正比在第二块屏幕上读 Telegram 更快的部分。
你的提问
「把这些复现步骤贴到这个 bug 对应的工单上。」
调用的工具
entergram_list_ticketsentergram_get_ticketentergram_create_ticket_comment
你会得到
你的笔记落在支持团队会去找的地方,而且是在上下文还在你脑子里的时候写的。这条评论是挂在工单上而不是发给客户的,所以工程师可以直白地讲清成因,不用先有人把它翻译成一版得体的说法。
你的提问
「提这个问题的人用的是哪个套餐?我们之前跟他说过什么?」
调用的工具
entergram_list_custom_columnsentergram_get_chat_custom_fieldsentergram_list_chat_comments
你会得到
它读取你的字段结构,取出该聊天上设置的值,然后再读同事留在上面的内部备注。答案是一段话:他的档位、你如果有记录的话还有他的续约状态,以及某人上周在电话里做出的、从没有人告诉过你的承诺。
你的提问
「修复已合并。通知这两位报告者,然后把工单关掉。」
调用的工具
entergram_list_accountsentergram_send_messageentergram_update_ticket
你会得到
所有人都会跳过的那一步。它先确定每个会话归属于哪个已连接账号,为每位报告者写一条简短通知交给你确认,等消息发出后再把工单置为已关闭。从发布到告知受影响客户的这段闭环,从一条待办变成一次提问。

