这是一个人造随机生成的描述了自然人与公司之间四种关联关系的数据集，分别是：
<ul>
<li><code>人</code> --<code>作为亲人</code>--&gt;<code>人</code></li>
<li><code>人</code> --<code>作为角色</code>--&gt; <code>公司</code></li>
<li><code>人</code> --<code>持有股份</code>--&gt; <code>公司</code></li>
<li><code>公司</code> --<code>作为子机构</code>--&gt; <code>公司</code></li>
<li><code>公司</code> --<code>持有股份</code>--&gt; <code>公司</code></li>
</ul>
<img src="https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website/images/demo/shared-holding/modeling.png" alt="modeling" />
在 NebulaGraph Playground 之中，可以从比如顶点 ID 为 <code>c_132</code> 的 Chambers LLC 公司开始双向拓展，穿透获得多跳的股权、控制信息。
<img src="https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website/images/demo/shared-holding/studio_explore_0.png" alt="studio_explore_0" />
探索点：
<ul>
<li>Edge Type</li>
<li>Direction</li>
<li>Steps</li>
<li>Query Limit(Optional)</li>
</ul>
<blockquote>
 你可以点击 👁️ 图标 显示不同的图信息,
</blockquote>
<img src="https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website/images/demo/shared-holding/studio_explore_1.png" alt="studio_explore_1" />
拓展之后，你可以看到所有 <code>c_132</code> 点周围的信息 <code>Chambers LLC</code>.
<img src="https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website/images/demo/shared-holding/studio_explore_2.png" alt="studio_explore_2" />
也可以从 Console 执行 nGQL 比如：
<pre><code class="hljs ngql language-ngql">GO 1 TO 3 STEPS FROM &quot;c_132&quot; over * BIDIRECT;
</code></pre>
更多数据集介绍：<a href="https://github.com/wey-gu/nebula-shareholding-example">https://github.com/wey-gu/nebula-shareholding-example</a>
数据集下载：<a href="https://www.kaggle.com/littlewey/nebula-graph-shareolding-dataset">shareholding-dataset</a>

介绍演示如何利用NebulaGraph进行股权穿透分析

股权穿透演示



在与社区的共同成长中，我们深知，最深度的产品需求洞察与用户体验反馈，往往源于一线的碰撞交流。

为此，NebulaGraph 核心团队首次启动 O2O（office to office）计划。

我们希望来到你的 office，深入你的业务场景，以纯粹的技术视角，为你面临的真实挑战提供定制化的深度技术支持与架构指导。

也希望在未来，你的团队来到 NebulaGraph office，与诸多社区用户一起交流 NebulaGraph 的使用经验。

我们期待与正处于图技术应用关键阶段的你，携手探求最优解。

> 星云仔号外：活动免费～只需为我们提供一个会议室，预留充足的交流时间即可。

# **01** 为何推出 O2O计划？

我们的目标简单而专注：

* **为你解忧：** 集中 NebulaGraph 交付专家与产品团队的力量，现场为你诊断架构、分析性能瓶颈，解决棘手的技术难题。

* **收集反馈：** 线下收集你对 NebulaGraph 产品的真实反馈，你的真知灼见将直接助力 NebulaGraph 的产品迭代。

* **共建共赢：** 与社区用户建立长期、可信赖的连接，共同推动 NebulaGraph 生态的繁荣。

# **02** 你将获得什么？

* **个性化系统诊断与优化建议报告：** 活动结束后，你将收到一份由 NebulaGraph 核心团队提供的技术报告，直指核心问题，并提供 actionable 的解决方案。

* **专属技术支持通道：** 拥有专属技术支持微信群，获得来自 NebulaGraph 的线上技术支持。

* **与核心团队面对面深度交流：** 关于 NebulaGraph 的一切问题，都将得到实施交付 leader 和 产品 VP 的解答。

* **社区大礼包：** 获得 n 个星云仔系列周边。

# **03** 期待这样的团队

为确保交流深度，我们将优先考虑符合以下条件的团队：

* 团队有专人或小组负责图技术相关工作的推进。

* 已在生产环境或核心测试环境中部署并使用 NebulaGraph.

* 正在面临性能、扩展性、运维等方面的具体技术挑战，并有强烈的意愿寻求突破。

* 愿意成为社区代言人，包括但不限于：分享用户案例/开发实战，积极参与代码共建与线下交流活动。

# **04** 活动时间

NebulaGraph O2O 计划长期有效，第一批招募时间为即日起至 11 月 17 日。

我们将每天对报名进行审核，审核通过后，根据双方时间，在 2 周内尽快安排专属技术支持。

# **05** 活动流程

1. **报名筛选：** 填写报名问卷，帮助我们初步了解当前的使用情况。

2. **会前沟通：** 3 个工作日内，我们将以电话形式与成功入选的团队沟通，并收集必要的技术资料以供技术团队提前研究。

3. **现场交流：** NebulaGraph 团队来到你的 office，进行技术研讨与技术支持。

4. **会后跟进：** 在活动后交付书面报告，并建立专属支持通道，确保活动价值得以延续。

# **06** 报名方式

名额非常有限～务必认真、全面地填写报名问卷。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/activity-O2O/qrcode-4.png)


扫码报名⬆️

我们相信，最合适的交流能创造最大的价值。

现场见～



集中 NebulaGraph 交付专家与产品团队的力量，现场为你诊断架构、分析性能瓶颈，解决棘手的技术难题

NebulaGraph O2O 招募｜为你提供免费现场技术支持

> 导读：在技术科普「Coding Agent」系列中，由 NebulaGraph GenAI Team @PsiACE 为大家带来多期 Coding Agent 实践经验，并分享 NebulaGraph GenAI 的最新工作。
> 
> 本期，@PsiACE 分享的是如何用 Python 实现一个能自举的 Coding Agent，并给出了避坑指南，希望给大家的 Coding Agent 带来启发。

Bub 的第一个 milestone：自动修类型注解。由 Moonshot K2 驱动。

> Bub: Successfully fixed the first mypy issue by adding the missing return type annotation -> Noneto the \_\_init\_\_method in src/bub/cli/render.py, reducing the error count from 24 to 23.

# **01** 为什么要自己造 Agent？

Coding Agent 现在已经是个红海赛道，市面上有不少优秀的产品，还有许多团队在 PPT 中绘制宏伟蓝图。

然而，Coding Agent 的“token 大力出奇迹”现象也很明显——动辄几十万 token 的消耗，真正有价值的部分却少之又少。

**这让我很好奇：如果自己动手造一个 Coding Agent，能不能找到更高效、更实用的解决方案？**

于是，我开始折腾一个叫 Bub 的 CLI 助手。它的目标很简单：做一个命令行下的实用助手，同时具备有限的自举能力。自举这个概念在编译器、操作系统领域早已不算新鲜，很多 Coding Agent 也喜欢宣传“AI 工程师贡献了多少代码”。

我希望 Bub 能迈出自己的第一步，解决它自身代码中的第一个实际问题。

# 02 最小可用：先跑起来再说

我的经验是，能跑起来的最小闭环最重要，别一上来就追求“完美架构”或者花太多时间做数据小偷。

Bub 的分层很简单：

- **Agent**：主循环，负责 LLM 交互、工具调用、上下文管理。
 
- **Tool**：每个工具一个类，参数用 Pydantic 校验。
 
- **ToolRegistry**：注册所有工具，方便扩展。
 
- **CLI**：Typer + Rich，命令行入口，支持展开中间状态。
 

Agent 的本质其实就是一个 while 循环。每次循环，Agent 会根据当前上下文判断是否需要调用工具，如果需要就调用，然后把工具的返回结果写回上下文。

## 主循环核心代码

```
class Agent:
 def chat(self, message: str) -> str:
 self.conversation_history.append(Message(role="user", content=message))
 while True:
 # Construct context: historical messages + tool list
 ...
 response = litellm.completion(...)
 assistant_message = str(response.choices[0].message.content)
 self.conversation_history.append(Message(role="assistant", content=assistant_message))
 tool_calls = self.tool_executor.extract_tool_calls(assistant_message)
 if tool_calls:
 for tool_call in tool_calls:
 result = self.tool_executor.execute_tool(tool_call.name, **tool_call.parameters)
 observation = f"Observation: {result.format_result()}"
 self.conversation_history.append(Message(role="user", content=observation))
 continue
 else:
 return assistant_message
```

## **踩过的坑**

- 没有捕获，LLM 输出格式一变就死循环
 
- 工具参数没校验，LLM 乱传参数直接崩
 
- Observation 反馈太长或缺乏有效信息，LLM 理解困难
 

# **03** 工具定义：扩展 LLM 的能力

工具是 LLM 和外部世界的桥梁，定义得好，模型才能真正“动手”。我的做法是：

- 工具参数全部用 Pydantic 校验，类型不对直接拒绝。
 
- 命令行工具有黑名单（比如 `rm`、`del`），遇到危险命令直接报错。
 
- 工具执行结果结构化返回，别让 LLM 猜。
 
- 操作命令行工具时，stdout 和 stderr 都很重要，不能只给 exit code.
 
- 工具之间要有明确边界，避免混淆。
 

```
class RunCommandTool(Tool):
 DANGEROUS_COMMANDS = {"rm", "del"}
 def _validate_command(self, base_cmd: str) -> Optional[str]:
 if base_cmd in self.DANGEROUS_COMMANDS:
 return f"Dangerous command blocked: {base_cmd}"
 def execute(self, context: Context) -> ToolResult:
 # Validate command, execute and return results
```

# **04** Prompt：让 LLM 按套路出牌

组织良好的提示词能显著提升 LLM 的输出质量。对于 Coding Agent 来说尤其重要，因为 LLM 的输出格式很容易失控。

我的经验

- Prompt 里要列出所有工具和参数 schema。
 
- 多给几个调用示例，覆盖常见用法。
 
- Observation 反馈要简洁，别堆无用信息。
 

## **Bub 的 ReAct Prompt 结构**

```
You are an AI assistant with access to tools. When you need to use a tool, follow this format:
Thought: ...
Action: run_command
Action Input: {"command": "ls"}
Observation: <output>
...
Final Answer: <your answer>
```

ReAct 的好处是简单直接，容易落地，虽然 token 消耗大，但能快速试错、跨模型迁移。

# **05** Milestone：自动修类型注解

定义好 Agent Loop、工具和 Prompt 后，Bub 的第一个 milestone 就是自动修复了一个 mypy 报错。

比如：

```
- def __init__(self):
- self.console = Console()
- self._show_debug = False
+ def __init__(self) -> None:
+ self.console: Console = Console()
+ self._show_debug: bool = False
```

## 实际的 Agent Loop

- 只让 agent 改类型注解、格式化、重命名，别让它碰复杂逻辑。
 
- 先用命令行工具执行 `mypy`，拿到报错信息。
 
- 让 agent 生成修复建议，再用 file edit 工具应用到代码。
 
- 修完自动再跑一次 mypy，确保没新问题。
 

## **踩过的坑**

- 模型对代码上下文理解有限，经常修错。
 
- 不验证，bug 越修越多。
 

# **06** 进阶玩法与工程自查

随着功能扩展，踩的坑也越来越多。我的一些经验：

- 工具扩展时，建议单一职责，参数 schema 明确。
 
- 长对话要截断或摘要，别让 LLM 超窗。
 
- 生产环境建议沙箱/虚拟机，命令行工具默认禁危险命令。
 
- LLM 输出格式不稳时要有 fallback 兜底。
 

# **07** 总结

Bub 还在早期，但已经能帮我自动修 bug、跑命令、读写文件。我希望这只是一个开始，然后得到更多有意思的反馈。

![](https://nebula-cdn.nebula-graph.com.cn/nebula-website-5.0/share/coding-agent-2/Bub.webp)

Bub it. [Build.it](http://Build.it)

---

### 项目地址

[https://github.com/PsiACE/bub](https://github.com/PsiACE/bub)

### References

- [https://ampcode.com/how-to-build-an-agent](https://ampcode.com/how-to-build-an-agent)
 
- [https://huggingface.co/blog/tiny-agents](https://huggingface.co/blog/tiny-agents)

如何用 Python 实现一个能自举的 Coding Agent，并给出了避坑指南，希望给大家的 Coding Agent 带来启发。

技术科普｜如何用 Python 实现 Coding Agent

NebulaGraph  Graph 服务、Storage 服务和 Meta 服务扩容