在同一个 shell 里完成发布
终端智能体真正被用起来的时刻,正是打开聊天应用会打断专注的那些时刻:部署刚结束、故障处理途中,或者一天快结束时你想知道还有什么没关。下面这些运行都假设了这种情境,提示词很短,全靠键盘,而连接器负责那些你原本会一直拖到不再重要为止的部分。每一项都对应几次具名调用,它们会打印在会话日志里,也正因为如此,当你手动看它们跑通之后,可以直接把它们搬进脚本。
了解更多
你的提问
「部署完成了。把版本号和 changelog 链接发到发布频道。」
调用的工具
entergram_list_accountsentergram_list_groupsentergram_send_message
你会得到
公告就从跑部署的那个 shell 里发出去,在成功之后几秒,而不是一小时之后。智能体先确定哪个已连接账号有发布权限,按名称找到频道(于是 ID 永远不用写进你的脚本),然后发送。把它接进部署目标,这一步就不再是可选项。
你的提问
「那条公告里的构建号我写错了,原地改掉。」
调用的工具
entergram_list_messagesentergram_get_messageentergram_edit_message
你会得到
改原文比在下面补一条更正要好。智能体回溯近期历史定位到那条消息,动手之前先确认内容,然后编辑;于是明天滚屏路过的人读到的是正确的数字,而不是一串补丁式的更正。
你的提问
「为这件事开一个故障处理房间,把值班的人拉进来。」
调用的工具
entergram_create_group_chatentergram_list_membersentergram_invite_chat_members
你会得到
三十秒的准备工作,而在系统宕着的时候没人想做它。群被建好,工作区花名册被读取以解析你点名的那些人,邀请随即发出。你回到日志前,协调工作已经安排妥当,而不是只做了一半。
你的提问
「把周五那条维护通知转发给所有还没看到的客户群。」
调用的工具
entergram_list_groupsentergram_list_messagesentergram_forward_messages
你会得到
转发原文能让每个群读到完全一致的措辞,这正是维护窗口通知需要的,也正是重新打一遍会破坏的。智能体在铺开之前会先检查哪些群已经收到过,所以没人会被同一条通知打扰两次。
你的提问
「这位报告者在我们的一些社群里,具体是哪些,我们名单上还有谁也在里面?」
调用的工具
entergram_list_contactsentergram_get_contactentergram_list_contact_shared_groups
你会得到
共同群组查询回答了一个 Telegram 自己不会回答的问题:你和某人的交集到底在哪里。当一份 bug 报告需要判断报告者的影响力时有用;当你在权衡「一个变通方案是在共享社群里发一次就够,还是要手工在十个私聊里重复十遍」时同样有用。
你的提问
「打发布标签之前,标记为这个里程碑的未关闭工单还有多少?」
调用的工具
entergram_list_ticket_custom_columnsentergram_list_ticketsentergram_get_ticket
你会得到
一行命令、零个看板的发布就绪检查。智能体读取你的工单字段结构找到里程碑那一列,按它筛选未关闭工单,并连标题一起报出数量。把它放进发布脚本的第一步,阻塞性工单就会拦住这次打标签,而不是在之后才浮出水面。

